[ 
https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107316#comment-13107316
 ] 

Randall Leeds commented on COUCHDB-431:
---------------------------------------

I propose the following concrete actions:

1) Make default Access-Control-Allow-Credentials: false, which only allows 
unauthenticated requests. This would allow the cross-origin browser client  to 
do no more than any other client on the web. This seems safe AND useful. I'd 
even be fine with CORS enabled by default if this is the case.

2) Punt on everything but the db-level _security object. No CORS for resources 
like /_session, etc. As an example of why it seems like you need /_session but 
you don't, remember that a couchapp could expose a well known URL for a login 
page popup, which is very much like browserid, facebook connect, etc.

3) Have a separate, default-off toggle for enabling the _admin role on 
authenticated requests. In other words, if the request is a CORS request AND 
Access-Control-Allow-Credentials is on for the origin, couch should by default 
strip the _admin role (if the cookie'd user has it).

4) Does it make sense to configure Access-Control-Allow-Credentials information 
on the user document? In other words, some couch trusts a set of origins for a 
particular set of dbs (apps), but users still need to allow it as well. This 
behavior mirrors things like OAuth: api key : origin enabled :: auth flow : 
allowing credential use

I think this gets us 80% of the use cases and feels pretty safe.
Concrete suggestions/recommendations/criticisms? If you want me to implement 
any of this let me know. I'd be happy to do it. I'd rather see features 
stripped out of this and have a minimal viable CORS in 1.2 than to leave it out 
completely because it's, uh... next level beats for couchapps. :-D.

> Support cross domain XMLHttpRequest (XHR) calls by implementing Access 
> Control spec
> -----------------------------------------------------------------------------------
>
>                 Key: COUCHDB-431
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-431
>             Project: CouchDB
>          Issue Type: New Feature
>          Components: HTTP Interface
>    Affects Versions: 0.9
>            Reporter: James Burke
>            Assignee: Benoit Chesneau
>            Priority: Minor
>             Fix For: 1.2
>
>         Attachments: 0001-cors-support.-should-fix-COUCHDB-431-2.patch, 
> 0001-cors-support.-should-fix-COUCHDB-431.patch, 
> 0001-cors-support.-should-fix-COUCHDB-431.patch, 
> 0001-cors-support.-should-fix-COUCHDB-431.patch, 
> 0001-cors-support.-should-fix-COUCHDB-431.patch, 
> A_0001-Generalize-computing-the-appropriate-headers-for-any.patch, 
> A_0002-Send-server-headers-for-externals-responses.patch, 
> A_0003-Usably-correct-w3c-CORS-headers-for-valid-requests.patch, 
> A_0004-Respond-to-CORS-preflight-checks-HTTP-OPTIONS.patch, cors.html, 
> cors_test.html, test_cors2-1.tgz, test_cors2.tgz
>
>
> Historically, browsers have been restricted to making XMLHttpRequests (XHRs) 
> to the same origin (domain) as the web page making the request. However, the 
> latest browsers now support cross-domain requests by implementing the Access 
> Control spec from the W3C:
> http://dev.w3.org/2006/waf/access-control/
> In order to keep older servers safe that assume browsers only do same-domain 
> requests, the Access Control spec requires the server to opt-in to allow 
> cross domain requests by the use of special HTTP headers and supporting some 
> "pre-flight" HTTP calls.
> Why should CouchDB support this: in larger, high traffic site, it is common 
> to serve the static UI files from a separate, differently scaled server 
> complex than the data access/API server layer. Also, there are some API 
> services that are meant to be centrally hosted, but allow API consumers to 
> use the API from different domains. In these cases, the UI in the browser 
> would need to do cross domain requests to access CouchDB servers that act as 
> the API/data access server layer.
> JSONP is not enough in these cases since it is limited to GET requests, so no 
> POSTing or PUTing of documents.
> Some information from Firefox's perspective (functionality available as of 
> Firefox 3.5):
> https://developer.mozilla.org/en/HTTP_access_control
> And information on Safari/Webkit (functionality in latest WebKit and Safari 
> 4):
> http://developer.apple.com/safari/library/documentation/AppleApplications/Conceptual/SafariJSProgTopics/Articles/XHR.html
> IE 8 also uses the Access Control spec, but the requests have to go through 
> their XDomainRequest object (XDR):
> http://msdn.microsoft.com/en-us/library/cc288060%28VS.85%29.aspx
> and I thought IE8 only allowed GET or POST requests through their XDR.
> But as far as CouchDB is concerned, implementing the Access Control headers 
> should be enough, and hopefully IE 9 will allow normal xdomain requests via 
> XHR.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to