couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benoit Chesneau (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
Date Sat, 17 Sep 2011 04:54:09 GMT

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

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

That's not what the patch does. What's the patch does is accepting by default to send credentials.
Which is basically what the couch api does with any client. You keep considering ajax as different
as an http client is. It isn't. https is here to solve most of what you actually worries.

Second, is that you can disabled auth per db. Just again how our api works. You can set roles
after etc. _restart and _config are already handled by couch auth (who really want to expos
that in production anyway, that's really a bad idea if you want to make things really secure
...). 

I agree we could eventuall disable_admins but that should be an option. CORS is not only used
to allows someone to put some data on the web. CORS can be used to externalized admin applications.
Just like you can do with elasticsearch and I want to be abble to run my own futon or logging
tool outside of couch. Again you can already disable admins paer dbs too.

New feature coming in the patch

- making cors optionnal via a setting
- block by default credentials on /db/* except if origins on a db is
set. Have a setting that would allows people to bypass this setting 

and now I'm adding this admin stuff.

CORS can have different uses than you expect in iriscouch or whatever is your business. 

Third. CORS isn't about security. It means Cross-Origin Resource Sharing . We shouldn't forget
that. 

Finally , just some word about the spec. CORS request processing is following:

1. check if Origin header is present
2. Split the value of the Origin header on the U+0020 SPACE character and if any of the resulting
tokens is not a case-sensitive match for any of the values in *list of origins* do not set
any additional headers and terminate this set of steps.
3. **If the resource supports credentials** add a single Access-Control-Allow-Origin header,
with the value of the Origin header as value, and add a single Access-Control-Allow-Credentials
header with the literal string "true" as value.
4. If the resource wants to expose more than just simple response headers to the API of the
CORS API specification add one or more Access-Control-Expose-Headers headers, with as values
the filed names of the additional headers to expose. 


http://www.w3.org/TR/cors/

That what the patch does. Nohing much. The same for preflight request.

Now the tricky part is that you have to accept credentials if you want that at some point
your preflight request goes in your db authentication checking. That's why it's accepted for
Option . If the origin isn't accepted however credentions aren't accepted (this is again what
the spec says).

Now what I propose and the patch is quite ready. I'm just in a busy we with no devs on this
machine but it is coming on monday when i'm back with descent network:

1. disallow any credentials request 
2. optional setting allowing the credential check working differently. The patch considers
anyone can auth but let you black list origins (which what the spec recommend). Patch still
allows you to do that but also allows you to disable credentials except if you set a lits
of origis per dbs, ie do whitelisting.
3. making cors optionnal.

The idea is to have cors working per db, having settings in a config fle doesn't really works
when you work in a distributed world.

Hope it helps to clarify intention of the patch and how I wish we implement CORS. I really
don't want to considers CORS as a security thing, but as a cross origin resource *sharing*
technology.

> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message