Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Date: Mon, 28 Nov 2011 06:34:41 +0000 (UTC)
From: "Benoit Chesneau (Commented) (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Message-ID: 
 <126513958.16441.1322462081687.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (COUCHDB-431) Support cross domain
 XMLHttpRequest (XHR) calls by implementing Access Control spec
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

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

@tilgovi on "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." I'm not sure it could happen ... once the preflight request is done it's cached. Even if an app is trying to access to 2 dbs (which should be prohibited imo) the preflight request will be done using the global settings (ini) or db settings an will only happen one time. Did I miss something?

About introducing params in origin settings, could be a good idea. The only problem I see is the need of put all these things on one line. That will be rapidly difficult to read. 

On security totally agree.

@jason  lot of couchapps aren't implemented on multiples dbs on the contrary. And it shouldn't  be supported. It breaks the replication and the security design. People that are doing that should know that, since they have to switch the insecure_rewrite settings.  Anyway i don't see how having security handled in _security is a problem. The scenario you push " /db_A/_design/foo/_rewrite/root/db_B/_design/foo/_rewrite/root/db_C/_design/foo/_rewrite/root/db_D " is a no problem since the preflight request will be handled by 'db_a' . also in this case db_A, db_B and db_C should  have the same host/origin policy.

Handling origin in db security object is good when you speak about vhosting couchapps if you follow the supported security schema. So we should handle it imo. 

The fact that _security can't be replicated without personal script is another problem that could be solved after. It's needed as well for admins and readers if someone want for any reason replicate a security policy. But it's another ticket/issue not related to this one.


> 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