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

Benoit Chesneau commented on COUCHDB-431:
-----------------------------------------

Thanks for the review. Answers follow

1. session is working even if the db is protected by readers. like any 
preflight request. I wrote the patch like that

2. Actually the patch works with a db protected against readers. If you are 
authenticated,  a CORS request will works,. Allows-credentials is always True 
in couch, we always test credentials and cookies internally anyway. You can 
test it with test_cors2 /../cors2.html

3. Security: The patch actually means that we accept from any connections on a 
db except you filter origins in a db. If you filter origin a db will only be 
accessed by this origin. It won't increase risks, since then an ajax client is 
just considered like any HTTP client. If you already have some exploits then 
they are already feasible with any http client that doesn't care about cross 
domain which is only a browser things. I don't see any other way to bypass our 
small security. 

If you want a better protections, some modules can be added to couch, 
couch_throttle, filtering users depending on the referrer or hosts, etc...I 
have some if you are interested ;)

4. Applications and multiples db. That's not how the system was designed until 
now (and you will have other problem to handle before to go on origin sync). I 
can see that happen however, but I don't see the real problem of keeping dbs 
origins synchronized. Also what if your db is dispatched on multiple hosts. 
This isn't really a problem I think.

I would like to keep db origin filtering, it actually works well with the 
current couchdb design. If we want more granularity we can discuss it and add 
it later imo. There are a lot to do on that part, but that's another debate and 
ticket imo

> 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, 
> 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, 
> 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