[
https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13041410#comment-13041410
]
Jason Smith commented on COUCHDB-431:
-------------------------------------
Alex, thanks for your thoughts. Some feedback:
I disagree that CORS is not hard security. It is hard security because
same-origin is the primary protector of all data on the web. Without
same-origin restrictions, any site you visit could reach your data on any other
site you visit. It is also hard security in that it is both difficult and
important to get right.
I am hoping for a fail-safe system.
It seems reasonable that the database admin should control the CORS permissions
of that database. For a /_config change, that requires the server admin.
The _config imposes practical problems too. It is not a general system
registry: all the data must go section-key-value. There is no way to have a
per-database config except to use an entire new section as a namespace, with
each DB name inside it. IMO I don't like that at all.
The only place I know of for per-database config is the _security object. Since
CORS is about security, it's logical to place it there (where the db admin can
modify it).
Finally, the original idea that I heard about CORS was to allow people to
specify any header. I don't think that is fail-safe. I have no idea what
headers people use out there. It seems impossible to evaluate the security of
permitting any header for any response.
Finally, CORS headers are generally generated dynamically. The only exception
is the wildcard header which for CouchDB would be a very dangerous setting.
That means any code from any site on any browser can access your couch without
the user knowing but (potentially) with the user's couch credentials.
Therefore, I am hoping for a whitelist to specify, "yes, www.mywebapp.com is my
own website and I trust all its code to access this couch".
> 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: Randall Leeds
> Priority: Minor
> Attachments:
> 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
>
>
> 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
