[
https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158035#comment-13158035
]
Randall Leeds commented on COUCHDB-431:
---------------------------------------
@benoitc since the CouchDB is a single server, every host configured is a
virtual host, or vhost. Sorry if that was confusing.
My issue with _security level config is that we cannot guarantee, in general,
that all resources on a single host will have the same cors headers. This is
broken as per the spec ("only cross-origin security is provided and that
therefore using a distinct origin rather than distinct path is vital for secure
client-side Web applications."). I find the spec confusing, because I'm not
sure what the implication is for client-side Web-application authors. It seems
to me like this applies more to servers than clients.
What I said about the cache didn't make sense, especially since simple requests
can bypass the cache. Supporting a configurable max-age is extra and does not
affect critical behaviours.
I don't think secure_rewrites make any difference. If we could limit _security
cors settings to only apply when a host rule maps to a path under a database
"A" we can ensure all paths under that host are subjected to the cors headers
from the _security object of "A" even if some path (even "/") points to an
insecure rewrite by applying the rules from the _security object of "A" no
matter what db the rewritten path points to. I would feel good about this
solution.
I'm starting to think that something like
[cors]
hostA = [{originX, none}, {originY, basic}]
hostB = [{originZ, including_admin}]
might be a reasonable approach.
If there is also a vhost like
[vhosts]
hostA = /dbA
then originX cannot make a CORS request to hostA even if dbA has a security
object which allows it. However, originY is subject to whatever rules are in
the security object of dbA with admin disabled.
On security and credentials:
I believe it is the responsibility of the CouchDB administrator to enable cors
with credentials only for TLS-only hosts or the Web user to access a foreign
Web application over a secure soceket (https->http CORS is disallowed by the
spec) to ensure that cookies are not sent to CouchDB in the clear.
Any closer?
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
