[
https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034521#comment-13034521
]
Jason Smith commented on COUCHDB-431:
-------------------------------------
Thanks for getting the discussion started! This is why I don't think the patch
is ready. Still, the security object idea was mine but I later abandoned it.
CORS Overview
============
There is a "simple" query and a non-simple query. Simple queries use a simple
method, and only simple headers.
Simple methods are GET, HEAD, POST.
Simple headers are Accept, Accept-Language, Content-Language, Last-Event-ID,
and Content-Type (which must be application/x-www-form-urlencoded,
multipart/form-data, or text/plain).
For a *simple* cross-origin XHR query, the browser just runs it immediately,
with an "Origin" header. If the response header Access-Control-Allow-Origin
matches the request header "Origin", then the browser passes the response back
into Javascript.
For a non-simple cross-origin XHR query, the browser queries the URL with an
OPTIONS method. It sets an "Origin" header, plus Access-Control-Request-Method
and Access-Control-Request-Methods. If the server responds affirmatively, the
browser runs the real query and then passes the response back into Javascript.
(The server can also indicate whether the resource allows logged-in users
(basic auth, cookie headers, etc.), or whether all queries must be anonymized
by the browser.)
So the CORS policy is per *resource* (URL), but resources can only whitelist
entire domains. (Well, actually "origins" which is http or https, the DNS
domain, and the port.)
Couch Discussion
=============
About vhosting and rewriting, Couch just needs to return the right policy for
the final resource it processes.
My first attempt was to do direct domain-to-domain whitelisting.
Firstly, you need universal CORS to respond to misc. queries: / (to ping
couch), /_all_dbs, /_session, /_log, /_config, and also PUT /db.
A good use case is a Futon fork. You whitelist https://better-futon.com and
then when you go to that site, it can control every aspect of your couch just
like old busted Futon.
The same technique would enable http://my-awesome-couchapp.com, something like:
1. You go to http://my-awesome-couchapp.com
2. You put your couch URL in a form field
3. The page pings your couch to check for CORS.
4. If no CORS, it pops up an iframe or target=_blank link to your couch Futon
configurator. You add the app to the whitelist.
5. The app keeps pinging your couch until it gets a pong (it was added to the
whitelist)
6. With CORS, and with your admin session, the app can install itself on your
couch (replicate, set up vhosts and rewrites, etc.).
So you just installed a couchapp by following a link on Twitter, and all you
had to do was input one URL into your whitelist. (better-futon.com of course
has a superior UI for this).
That use case (and simplicity) is why I started with domain-to-domain
permission. To open up just one db, you can vhost db.mycouch:5984 ->
mycouch:5984/db/ and make sure httpd.secure_rewrites is true.
> 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
> 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
