fine-uploader
fine-uploader copied to clipboard
FineUploader
Allow custom params to be sent with signature request
This is particularly important for apps that need to pass a CSRF token with every request. One way to pass this token is via an X header, but this will not work in IE8/9 in a cross-origin environment, since headers cannot be specified.
Not going to be part of 3.9. This would complicate the current convention for non-chunked signature requests. We would need to move the policy document sent in the request body into a "policy" property, to allow for custom params to be specified alongside the policy document.
Since this is a breaking change, let's wait until we receive specific requests from customers.
i'm interested in the ability to send a csrf token for S3 signature requests.
The only way to accomplish this without a breaking change would be to allow headers to be specified explicitly for the signature request.
@rnicholus are you saying that some params sent to the signature url (like the token) would have to be ignored when generating the signature? Which would be a server-side consideration?
i was presuming it might be something like this:
signature: {
endpoint: "<signature-url>",
params: {csrftoken: "<token>"}
},
Any changes to the body of the request will be breaking changes, so that can't happen until the next major version release. Currently, the payload of the signature request for non-chunked uploads contains, in its entirety, the policy document.
Most likely, I will opt to add an API method to specify headers for the signature request, and then you can send the token in a header. I really don't want to commit any breaking changes that requires users to update their server code, ever.
Understandably. Would any changes be required if the token could be send in the header instead? That would be just as acceptable to me.
Changes to Fine Uploader internal code yes, but I don't see these being breaking changes. A new API method would have to be added to allow users to specify headers for signature requests. That would be a non-breaking change.