couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Randall Leeds (Commented) (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
Date Sun, 27 Nov 2011 21:43:39 GMT


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

I'm starting to think that something like
hostA = [{originX, none}, {originY, basic}]
hostB = [{originZ, including_admin}]

might be a reasonable approach.

If there is also a vhost like
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

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:
>             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,
> 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:
> 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):
> And information on Safari/Webkit (functionality in latest WebKit and Safari 4):
> IE 8 also uses the Access Control spec, but the requests have to go through their XDomainRequest
object (XDR):
> 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:!default.jspa
For more information on JIRA, see:


View raw message