Support CORS [JIRA: RCS-177]

[reiddraper]

Add support for CORS

S3 CORS docs.

W3C CORS doc

[xiaoliuliu2050]

i just encountered the same problem ,how to solve it?

[shino]

CORS is on the roadmap of Riak CS but not implemented yet and not determined when.

[xiaoliuliu2050]

whether could i use the aws s3 interface named 'putBucketCors ' to add a cors configuration to support
it ?

[shino]

Riak CS does NOT implement the S3 API. I'm afraid you could not.

[xiaoliuliu2050]

http://docs.basho.com/riakcs/latest/references/apis/storage/s3/ this chapter describes that riak cs support some of s3 api, including PUT Object interface , but when i use it ,it just encountered the cors problme

[xiaoliuliu2050]

hello shino ,do you know some other ways to solve this problem? i have used the putobject interface riakcs supported, and the the putbucket interface riakcs not supported. which do not work any more .

[kuenishi]

I still don't understand exact problem. Lacking in CORS support may not interfere correct PUT Object call, but we need more information about WHAT and HOW you are failing in detail, to know whether we can solve your problem or not.

[whw987]

Hi, Mr kuenishi

I and xiaoliuliu2050 work in a same development group, currently we encounter a problem about how to put and get files in browser environment to the riak-cs system, our riak cs is version 1.5.4. The following is our questions:

1. If lacking in CORS support in current riak-cs, can we make operation put and get files in browser environment to the riak-cs system (we adopt Amazon S3 javascript REST API in aws-sdk-2.1.4.min.js)
2. Based on question 1, if we can, then how to or what API we can use?

Thank you in advance.

[kuenishi]

If you've done some experiment, maybe a set of HTTP request and response that your browser JavaScript are making might help diagnose the problem. If that browser doesn't work, I'll recommend making APIs in your HTTP server that handles puts and gets from browser and forwards those request to Riak CS. I'd recommend (riak-users mailing list)[http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com] for a discussion like this.

[sdebnath]

+1 for CORS support. A modern day "cloud storage" solution should support modern day "cloud applications". For our traditional iOS apps, the regular interfaces work great and thank you for that. However, as we venture into Single Page Apps for mobile and browser, the need for CORS support is critical for our business (which relies heavily on Riak and Riak-CS).

A barebones implementation should not be that difficult. I have added CORS "support", albeit rudimentary, myself to webmachine based app for one of our services within a few minutes. Need to support CORS pre-flight (HTTP OPTIONS method) without authentication which return, at the bare minimum, these three headers

• "Access-Control-Allow-Headers"
• "Access-Control-Allow-Methods"
• "Access-Control-Allow-Origin"

One could specify each option through riak-cs.config or do what Amazon S3 does and allow the admins to provide a blurb. Another critical header for the subsequent request following the pre-flight, whether it be GET or PUT, is to return the "Access-Control-Allow-Origin" header.

[kuenishi]

Shawn, thank you for reminding us - I wasn't aware that CORS was critical for SPA. The implementation shouldn't be hard, just adding and API handler, a field in bucket metadata, adding a handler in Stanchion.

For sure CORS is in our backlog of adding more S3 API support, but for now Bucket Lifecycle and Bucket Versioning are in higher priority for API coverage. And to tell the truth, items like operation improvement, metrics, garbage collection, replication are in higher priority than them. I hope you could be patient, or could contact Basho business side... sorry.

[sdebnath]

SPAs involved with angular.js typically will force the CORS path when content type is something other than text plain. And with the latest frameworks, CORS always tends to pre-flight with no option of disabling it. To be honest, I don't get their story either but if you search online, folks are setting up proxy services that understand CORS on the receiving side and then communicate with services that do not support CORS. As one can imagine, not the most efficient nor cost beneficial approach when dealing with potentially large media files.

I have pinged @mjbrender and working with him to see what can be done. Hoping to get a dialogue going with some folks at Basho to see what the right way to do this would be (thx for your info above btw) and perhaps pushing a patch here in the near future with a good likelihood of getting merged.

[sdebnath]

Put together a very high level design doc to make sure the path I am taking makes sense for Basho. Feedback, comments welcome here or via email. I will wait to hear from you before jumping in the code. Cheers.

URL: http://shawndebnath.com/docs/riak_cs_cors.txt

CC @kuenishi @zeeshanlakhani @sargun @mjbrender

[seancribbs]

/unsubscribed/

[kuenishi]

Thanks, @sdebnath . I'll take a look.

[iby]

Wishing for CORS… milestone 2.3.0 :cold_sweat:

[kuenishi]

@sdebnath I've read through the design doc. Thank you for your contribution! Overall it looks good, capturing webmachine correctly. Let me have some questions / comments.

• DELETE /?cors resource is also needed.
• For bucket policies, resource permissions like s3:PutCORSConfiguration should be added to header to handle with bucket policies.
• Original S3 seems to evaluate CORS accessiblity before object existence and regardless of any subresources. Regarding this, for perfect compatibility, I think we have to touch WM resources related buckets and objects. If so, it would be better to add options/2 handler in riak_cs_wm_common, but it's not aware and other APIs will be affected.
• I'm not sure I get the point of open questions No.2; if AllowedOrigin is set as wildcard, then the response from Original S3 looks including the wildcard Access-Control-Allow-Origin: *. I haven't read through the w3c spec, but is this illegal behaviour?

We know that S3 has several weird behaviors, and we have been not spending much time on imitating such behaviors and just be choosing simpler implementation for minor use cases. Our My design decision usually depends on whether a lot of clients and libraries are depending on such behaviour. Others may have different view, though.

I also would like to mention CORS rules data should be updated via Stanchion and it would require a log of hastle, but it's possible by repeating my effort in bucket policies.

[sdebnath]

Thanks for the feedback @kuenishi. Going to try to inline comments here:

1. DELETE /?cors: makes sense, added to doc
2. s3:PutCORSConfiguration header: okay, makes sense. If I have questions, I will ping you.
3. options/2 in riak_cs_wm_common: yep, that was the approach I was planning on taking. riak_cs_wm_common has the shared entry points, which then calls to appropriate resources. I was planning on filtering processing of options and restrict it to bucket/object resources. And yes you are correct, regardless of sub-resource, the options will be evaluated on the bucket and then proceed to regular acl and other checks where sub-resource existence is checked today.
4. Re Allow-Origin header: Per specs, the server can return Origin request header, , or 'null'). What I proposed is not illegal behavior as we would be passing the back origin request header sent by client instead of the riak setting of . I believe we should be good.
5. Regarding keeping it simple and not matching S3: agreed. This feature is simple enough that we can follow the actual guidelines set forth in the CORS spec. It might break S3 compatibility but actually meets the major browser requirements out there today.
6. Regarding updates via stanchion, yep that's the plan as documented in the design doc.

Tidying up some loose ends at work, will jump on this soon.

Thanks!

[kuenishi]

Cool. One thing I forgot to note: s3:PutCORSConfiguration is required until release, but not mandatory for first work. You can focus on CORS without it.

[lokedhs]

How can I see what the current status of this is? I'd really like to be able to use riak-cs, but the lack of CORS is a blocker for us.

[sdebnath]

I am currently working on this on my spare time, this effort is not part of Basho. Unfortunately, there were some higher priority work that took precedence at my startup and this was put on hold, though we are planning on restarting the work soon.

The work to receive and store the CORS settings is complete. Need to ensure it is working correctly, then on to implementing support for checks against the rules.

Having said that, we are currently quite satisfied by putting a media proxy in front of RiakCS/S2 for web requests to CS. Works quite well for majority of the scenarios.

[kuenishi]

:+1:

[rafael81]

:+1:

[c0b]

:+1: