CODEWITHSUNDEEP
ruby-on-railsamazon-s3paperclip
Michael
Michael

Reputation: 683

Rails set up a proxy for Paperclip images on S3?

I have a Rails 3 app with images hosted on AWS S3 and managed by the Paperclip gem.

I'm trying to set it up so that a user can edit those image in-browser using a js library (right now I'm using Pixastic, but I'm open to trying Caman) but run into a problem where the js image manipulation libraries fail because of CSRF protections from the browser that reject the S3 image as being from a different domain.

Is there some way to proxy the images so that they appear to be coming from the same domain, or otherwise work around this problem?

Upvotes: 2

Views: 753

Answers (1)

jeffreymatthias
jeffreymatthias

Reputation: 674

I just spent a day with a partner working through this with CamanJS.

Without knowing how you're constructing your view (and not knowing Pixastic at all) I'll do my best to answer.

Assuming you're linking to the original image in your html, add crossorigin='anonymous' into the image tag:

<img class='image' crossorigin='anonymous' data-camanheight='450' src=<%= @photo.url%>>

This will set up the browser's expectation that the image will not come from your site's url.

We found this to work for the initial image, but when CamanJS' revert() function reconstructs the image (before converting it back to a canvas element), it leaves out the header information that lets the browser know that it's ok that it is cross-origin data. So every time we reverted an image, we hit a CORS issue again. I looked through Pixastic's docs briefly, but can not advise you on whether or not you'll have a similar issue.

NOTE: A super fluid experience was our priority, and we didn't want to set up a proxy, so our work-around was to keep a clone of the image tag on hand in a Javascript variable and write our own method to revert the canvas, re-cloning the the image tag, pushing one of the cloned tags into the DOM and then converting it to a new canvas element and getting rid of the old one. It ran into some CamanJS specific behaviors that made it a little 'hacky.'

My partner on the project has submitted a pull request to CamanJS that retains the header info, so this may be resolved soon, making CamanJS a better solution for cross origin resource sharing.

Hope this helps.

Upvotes: 4

Related Questions