Feature Request P2
Status Update
Comments
jo...@google.com <jo...@google.com>
se...@gmail.com <se...@gmail.com> #2
I'd like to add that this applies to the Blobstore service on all App Engine platforms, including Java and Go, not just Python.
And in addition to allow setting the "Access-Control-Allow-Origin" and "Access-Control-Allow-Methods" headers, the Blobstore service should also respond to OPTIONS requests to support preflighted cross-domain requests.
I think since the Blobstore requires retrieving upload urls which are only valid for a certain session, there is no security drawback in allowing to set cross-domain access headers, it might be even OK to set the origin value to "*" and allow the required HTTP methods (OPTIONS, POST) by default.
So in summary, replying to OPTIONS request (in addition to POST for the actual uploads) and setting the following headers by default would allow cross-domain uploads to the blobstore, without having to change any API methods, while still having the security provided by the required upload urls:
Access-Control-Allow-Methods:OPTIONS, POST
Access-Control-Allow-Origin:*
And in addition to allow setting the "Access-Control-Allow-Origin" and "Access-Control-Allow-Methods" headers, the Blobstore service should also respond to OPTIONS requests to support preflighted cross-domain requests.
I think since the Blobstore requires retrieving upload urls which are only valid for a certain session, there is no security drawback in allowing to set cross-domain access headers, it might be even OK to set the origin value to "*" and allow the required HTTP methods (OPTIONS, POST) by default.
So in summary, replying to OPTIONS request (in addition to POST for the actual uploads) and setting the following headers by default would allow cross-domain uploads to the blobstore, without having to change any API methods, while still having the security provided by the required upload urls:
Access-Control-Allow-Methods:OPTIONS, POST
Access-Control-Allow-Origin:*
se...@gmail.com <se...@gmail.com> #3
Actually, it is required to be able to set custom headers as credentialed requests (needed for cross-domain cookies support) require an explicit Access-Control-Allow-Origin header:
"when responding to a credentialed request, server must specify a domain, and cannot use wild carding."
https://developer.mozilla.org/En/HTTP_access_control
"when responding to a credentialed request, server must specify a domain, and cannot use wild carding."
[Deleted User] <[Deleted User]> #4
Any idea if this was implemented ??
ad...@gmail.com <ad...@gmail.com> #5
This feature would be extremely useful for my project and I would love to see this implemented.
ta...@taylor-hughes.com <ta...@taylor-hughes.com> #6
Any progress on this issue? My workaround involves urlfetch-POSTing the uploaded file to the blobstore upload endpoint, which is a tremendous waste of resources and prevents my users from uploading very large files.
[Deleted User] <[Deleted User]> #7
Any progress in this? Very useful for my project too!
ul...@gmail.com <ul...@gmail.com> #8
obviously S3 bucket support this feature, that's why google is losing the market from amazon.
ke...@gmail.com <ke...@gmail.com> #9
This seems to be working fine now. Make sure you add the CORS headers to response in your servlet that is called once the upload is completed.
sh...@storee.us <sh...@storee.us> #10
Tried #12 advice, doesn't work.
Any official update?
Any official update?
re...@gmail.com <re...@gmail.com> #11
Is there any progress?
mv...@gmail.com <mv...@gmail.com> #12
any update?
[Deleted User] <[Deleted User]> #13
[Comment deleted]
ja...@gmail.com <ja...@gmail.com> #14
Any progress? I saw one user saying it's working but It doesn't work for me.
ja...@gmail.com <ja...@gmail.com> #15
Is this ever going to get resolved?
za...@gmail.com <za...@gmail.com> #16
For what it's worth, evidently #12 works. I say "evidently" because I didn't see the error first hand: it was reported to me by someone developing a webapp against my GAE API. He posted the error he was seeing, I implemented the fix per #12, and the developer said no more errors.
ja...@gmail.com <ja...@gmail.com> #17
[Comment deleted]
ja...@gmail.com <ja...@gmail.com> #18
#12 does not resolve the problem for me...
[Deleted User] <[Deleted User]> #19
#12 didn't work for me
ga...@gmail.com <ga...@gmail.com> #20
Here is a proof of concept that cors doesn't work ! Try with an nginx reverse proxy on it and you will see ! This is non-sens to not be able to configure the generated upload url ! And your capacity to fix and aswer to your customers is awesome ! More than 4 years !
mk...@gmail.com <mk...@gmail.com> #22
FWIW #12 seems to actually fix the problem but only in production - not in devserver. I was unable to get a working demo on devserver. But once I deployed to production CORS request worked with CORS headers set to the target URLs!
Description
self.response.headers.add_header("Access-Control-Allow-Origin","*")
It's not possible to do when using the createUploadUrl(...). A possibility to set additional header fields on UploadUrl would be useful or am I missing any feature?