Closed duncanbeevers closed 11 years ago
Well done, fine sir! Thank you for your contribution!
Hmm, this code breaks uploads to Amazon S3 because it adds a 'hidden' parameter X-Requested-With
that wasn't encoded with the rest of the policy document. Is this middleware only used when your rails app is handling the upload? Should I still make an iframe_response
action to redirect to after S3 has successfully received the upload or would the middleware be able to handle that by itself?
The middleware, and the piece of client-side code that adds the X-Uploaded-With parameter are distinct, though they work together.
I'm not sure how you're generating your policy documents, but I think it makes sense to at least allow a way to suppress generation of this additional input element.
The policy is generated and digitally signed with the S3 secret_access_key
and then applied as form parameters on the upload link on page load (It very closely follows the functionality of a Railscast by Ryan Bates with some tweaks).
The problem is that on page load it needs to know the exact parameters that will be sent to S3... and if S3 sees any additional ones it gives an Access Denied
error. I'm not sure if it's possible to specify optional parameters in the policy - I previously couldn't find a way.
It looks like that parameter is added to iframetransport as a static value, a work-around for me would be to set my own "x-uploaded-with" value for all uploads, and add it to the S3 policy. This way both iframe transport and non-transport would work correctly. (If you specify a parameter in the policy and that parameter isn't received by amazon, it also fails the policy document check and gives you Access Denied
).
This middleware is lifted directly from rack-iframe-transport.
A small change was made to the vendored version of
jquery-fileupload-rails
to and theX-Requested-With
parameter to the submitted form, as is done in @cmlenz` jquery-iframe-transport.