As requested: Basically, the gist is that you accept the upload via a local JS file that acts as a conduit. You then turn the dropped / selected file object into a blob object and transfer that blob JS file that lives on S3 (using postMessage and a hidden iframe). That JS file on S3 is what actually performs the upload and tracks the upload progress. On progress events, I send back postMessage payloads to the local JS file to show updates to the user.
Convoluted, but it works. :)
And a jQuery plugin here:
After weighing the pros and cons of proxying versus this, I settled on the postMessage strategy -- but still no fun at all, and I'm so glad that CORS is finally an option.
If any others have interest (reply to this comment if you do), I can turn it into a library and put it on Github.
If you were to open source your code I'd love to learn from it.
I've pled for this feature in the AWS forum, over their commercial support (which I bought just to bug them about this), and to werner vogels directly.
At least now I won't launch something only to have Amazon eat my lunch when they finally came around to providing this much-needed feature.
Could somebody explain CORS to me? How is making the server you're contacting specify it wants to receive requests, in the response header, secure? The request has already been made!
Using CORS allows you to specify which servers you can accept requests from unless of course you are using ;
More info ;
Also, strictly speaking, this class of attack is Cross-Site Request Forgery (CSRF), not Cross-Site Scripting (XSS).
Edit: My above comment is slightly incorrect. If the request is "simple" it will be made and then you'll be blocked if it doesn't fit the CORS policy. If the request is not deemed "simple" (according to some rules you can look up in the spec) then the OPTIONS flow occurs.
Thanks in advance