[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13433105#comment-13433105 ] Robert Newson commented on COUCHDB-431: --- I'm still re-learning about CORS. This really has taken far too long. I want it in 1.3 but it needs to be right (and safe). I'd love to see complete CORS support though it doesn't all have to land in 1.3. That said, I say we go for broke and try to get it all in, we can split it later if that proves too tough. As an aside, I generally dislike approaches that use the process dictionary. There's often a good case for exceptions in the case of http requests as there's a process per request, but it still feels icky to me. Webmachine, as you well know, wends a State object through the http request pipeline, much as a gen_server does, and that seems a much saner model (and ick-free). Complete aside, I think, until we can move to webmachine, cowboy, webcowboy or cowboymachine. B. > 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: Blocker > Fix For: 1.3 > > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13432978#comment-13432978 ] Dave Cottlehuber commented on COUCHDB-431: -- @benoitc +1, sounds very interesting, especially being able to extend CouchDB through various middleware. I think we should have full credential support. > 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: Blocker > Fix For: 1.3 > > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13432940#comment-13432940 ] Benoit Chesneau commented on COUCHDB-431: - Thanks for the wakeup @rnewson. We restarted this work during the last couchack and @daleharvey have some new code around but last time I heard about it it wasn't finish. Also it depends how far we want to go in CORS support. ie on read only? for public dbs only ? Or do we also want to support credentials. I am hoping we are going for 3. Anyway I wanrt to start some work today mixing all the ideas around and trying the following design: Having a middleware that works like the vhost handler : NewReq = handle_cors(Req) This handler is handling the preglight phase and check the origin. This handler would also remove the need to stoire in the process dict all the info we need and everything will be stored in the req object.. Then this handler can check the policy by matching a set of rules depending on the current path qnd tell if an origin is accepted or not and oif credentials can be used. Thoughts? > 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: Blocker > Fix For: 1.3 > > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[
https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13186932#comment-13186932
]
Jason Smith commented on COUCHDB-431:
-
I have a partial implementation of Benoit's updated spec at
http://friendpaste.com/4q1zeNUEtPFS7XbioPYYzM
https://github.com/jhs/couchdb/commits/newcors/
This includes two etap files, with 44 tests so far. There is no HTTP code yet.
I plan to use Benoit's http code and tests from his patches on this ticket,
which have been reviewed by several people. For now I am focusing on getting
good tests about CORS policy.
My code so-far is a new module, couch_cors_policy.erl. It has almost no
connection or dependency with Couch. It does not require initialization. It is
not necessary to start any couch_* servers. Its primary function is check/3
Given parameters (1) a global configuration, i.e. couch_config stuff, (2) a
local configuration (a _security object), and an #httpd{} request, it will
return a list of the correct CORS headers, or 'false' if the response should
not support CORS.
When couch_config is running, you can omit the first parameter, and it will
derive it from the config. See test/etap/251-cors-config.t.
In any case, test/etap/250-cors-policy.t exercises the policy decisions and
whether they are correct. It is in-progress, but the tests cover a few aspects:
* The interaction between _security and the _config (in general, _security
takes precedence)
* Correct headers according to the spec
* Defaults, and their interaction with user settings
Feedback is appreciated. Thanks.
> 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.3
>
> 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/ContactA
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13179342#comment-13179342 ] Benoit Chesneau commented on COUCHDB-431: - Curious way to bump a ticket. There is a thread about what we will do on the dev@ ml, I will sync with randall, to see how far he has gone. > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13179205#comment-13179205 ] Joan Touzet commented on COUCHDB-431: - Bump. Where is this w.r.t. 1.2.0? The last thing I see is disagreement on defaults (everyone vs. benoitc, I think) and agreement on the specific code. > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158270#comment-13158270 ] Benoit Chesneau commented on COUCHDB-431: - preflights requests are done on path. (answring to previous comment) > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158261#comment-13158261 ] Benoit Chesneau commented on COUCHDB-431: - "11. It should be possible to configure distinct cross-origin authorization policies for different target resources that reside within the same origin." - (http://www.w3.org/TR/cors/#requirements) " We should test if the browser sending a preflight request on each patch. I thought it did but maybe not (hence my patch). If it's not the case we should just handle cors against hosts then. > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158259#comment-13158259 ] Benoit Chesneau commented on COUCHDB-431: - i agree that when you start to set origins you shouldn't accept any other origins. except maybe if '*' is set in the conf. The flow may be: is origins list not empty in ini no -> is admin set ? yes -> stop no -> return "*" , credentials false (with a good caching policy) yes -> is origin in .ini ? yes -> use cors rules for it no -> are we on a db resource ? yes -> are origins in db sec obj yes -> is origin in list ? no -> stop yes -> ... > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158246#comment-13158246 ] Benoit Chesneau commented on COUCHDB-431: - why CORS is scary on it ? That's matter of a real discussion. It allows pretty interesting things on the contrary. For example in elasticsearch world it allows people to build admin & stats applications . Useful for dev and admin other nodes. People that want to protect against malicious site should protect themselves. I'm starting to be really annoyed by this way of seeing the security anyway.People that are not able to not protect their local network or shouldn't go on the net. The spec doesn't allows it. yes. But i'm speaking about usability. Ex, i want all my local net with different tld .fr.lan, .us.lan ... to access to it with credentials. There should be a way to say *. I didn't say "say * to credentials". My patch is returning the origin for that not *, but you can set * in db origins. aboyt config syntax, hosts should be separated by a , in ini. "_" is too much matter to problems. For the rest apart the problem of readability of ini with a long list i don't see. > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158243#comment-13158243 ] Randall Leeds commented on COUCHDB-431: --- I noticed that the Requirements appendix, item 11 states that cors policies for resources on the same origin may differ. "11. It should be possible to configure distinct cross-origin authorization policies for different target resources that reside within the same origin." - (http://www.w3.org/TR/cors/#requirements) This contradicts my past assumption. It invalidates my Max-Age suggestions. Also, it improves the use case for _security level config. I'll try to update the unit tests with my last comment and we can keep iterating. Jason and I also discussed some possibilities for configuration at host level which sounded reasonable. However, maybe we should consider another possibility. I will take it to the mailing list. > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158238#comment-13158238 ] Randall Leeds commented on COUCHDB-431: --- CORS by default is too scary with local DBs. I think it breaks common assumptions about the web. I don't want to have to create admin accounts on my local, 127.0.0.1 couch in order to prevent a malicious site from stealing my personal data. As for credentials for all origins, I'm saying that the spec asks browsers not to allow it, therefore whatever config system we have need not allow that to be configured. For example, Jason suggested something like: [cors] hostA = http://originX https://originY hostB = * Where default would be to allow credentials for originX and originY, but not for any other. Without specifying credentials in the ini file, the default is to do what the spec says are the use cases. I still think we can do better for configuration, though. > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158230#comment-13158230 ] Benoit Chesneau commented on COUCHDB-431: - @tilgovi on 1 : i think the default on the contrary should be cors is * (credentials false) until an adminor the 'only authenticated' setting are set. This respect more our defaults. With eventually a switch. - ok. - on 3 : detail of implementation. The question is more how can you allows credentials for all origins without putting them manually. Should we support that? How? > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158221#comment-13158221 ] Randall Leeds commented on COUCHDB-431: --- Jason and I talked at (great) length today (thanks again, Jason). Here are the important conclusions. - Default CORS policy MUST be to deny requests. In particular, this is to prevent breaking the assumption that a local couch is secure by virtue of not facing the public Internet. Since an attacker can cause a CORS request to 127.0.0.1, it is dangerous to enable CORS by default (even if the methods are restricted and credentials are stripped). - Default should be Access-Control-Allow-Credentials: false. Even when CORS is turned on, credentials should be disabled unless specifically enabled. - The specification instructs (6.2#2 - 6.2#3) clients to abort requests when Access-Control-Allow-Origin is "*" and Access-Control-Allow-Credentials is not "false". Therefore, our implementation should not allow an administrator to configure this combination of settings. > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ 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 CouchD
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[
https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158120#comment-13158120
]
Jason Smith commented on COUCHDB-431:
-
@randall
"Sometimes CouchDB is deployed without vhosts."
May we call it "host-based" configuration, not "vhost-based" configuration? It
is not virtual, and unrelated to the CouchDB vhost feature. With this
terminology, do you see an error in your second paragraph? "Sometimes CouchDB
is deployed without vhosts." Sure, but it is *always* deployed as a *host*,
even if that is "http://127.0.0.1:5984.";
"The security object is more flexible and unifies access control in one place."
It is more flexible but I disagree that it unifies control in one place.
Real-world couch apps are split across multiple databases, and also require
special paths like /_session and /_utils. Are you concerned we are outsourcing
the hard work to the app developers?
1. They must synchronize _security across all their databases.
2. They must synchronize with /_users/_security too but they may not be an admin
3. They must synchronize with a global security to handle /_uuids, /_session.
I went 100% host-based to achieve a simple first milestone. Maybe we could do
_security configs later. If you disagree, that's fine though.
Quick question question. Imagine _rewrite/root points back to the root path
(i.e. you get {"couchdb":"Welcome", "version":"..."}). For:
/db_A/_design/foo/_rewrite/root/db_B/_design/foo/_rewrite/root/db_C/_design/foo/_rewrite/root/db_D
What would be the final CORS policy to apply? The union? The intersection?
> 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/j
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[
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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157917#comment-13157917 ] Benoit Chesneau commented on COUCHDB-431: - @randall what do you mean by vhost. I think it would be more accurate to speak about an host configuration, ie anything in Host header. Trying to summarize in term of feature, so what we want is : - Origins can be set per hosts or all hosts (*) globally in config and per dbs in security object (like admins) - An admin could force config to be only global (set in config) - Origin is first tested with the list in config then in db (note that * will overrule ) About method filtering, I'm not so fan about that. For the reason that depending on the resource (_all_docs, _view, ..) POST may be perfectly legit so forbidding it by just accepting GET in an attempt to have read only db is awkward and shouldn't be supported imo. We could introduce that in another path ticket. Let's try the easy schema for now. About cache. I think it's OK to support it, however I think we shouldn't insist much on this . Origins are about host. Then having different possibility per dbs or path isn't really supported by the spec. More I think an app should be limited to an app and we really shouldn't encourage the switch to insecure_db_rewrite. This to keep the security schema pretty simple. Rather we should maybe introduce the notion of global apps or something like but this isn't the subject of this issue. Also for remote apps based on CORS it shouldn't be an issue if hosts are set globally. Other than that i'm ok. Let me know when you need review or more. > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157897#comment-13157897 ] Randall Leeds commented on COUCHDB-431: --- After talking more about this today, it seems Benoit have sorted this out a bit more. - We MUST not allow the preflight request cache to accidentally circumvent CORS settings for any path - We SHOULD should both vhost-based configuration and db-level configuration It's important to support both configurations. I reason that some dbs may want to allow any combination of read-only/read-write (don't forget to filter X-Request-Method!), anonymous/authenticated, and any set of headers; sometimes CouchDB is deployed without vhosts; server administrators MAY want to force CORS settings for a vhost despite any db settings. I don't see a clean way to fully support the options in the spec from a vhost/config-only approach. The security object is more flexible and unifies access control in one place. After some consideration, I hope I have correctly determined that Jason's main fear with configuration via the _security object is that the invariant I listed first could be violated by a server which specifies, via _security objects on two or more databases, different access controls for two paths on the same origin. I would like to suggest that forcing the "Access-Control-Max-Age" header to "0" is sufficient to ensure good behaviour with _security objects specifying access control. Therefore, I'm working on a merge with unifies both patches and delegates to the db when nothing is set on the config level with these considerations in mind. Finally, I think I want to do another couple of things as well before this is merged: - For db-level configuration, it should be possible to customise Credentials, Method, and Headers. - Default should be to deny all origins, both on the preflight and the final request. This applies to vhost-level configs, too. How does this sit with both of you? Give me your thoughts and I'll try to finish synthesising a merge when I wake up. > 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 (XD
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157695#comment-13157695 ] Benoit Chesneau commented on COUCHDB-431: - @tilgovi thanks to bump the again. I tarted long time ago to change patched based on the actions we defined [1] but I've been distracted. To be honest btw i would prefer to technically follow the way introduced by my patch. It touch less places in the code and is more isolated btw. @jason I disagree. The patch was following the one spec, so it's hard to say it's useless for web devs. If the spec allows credential passing that's for a reason ... I need to pass credentials for ex. Anyway I would prefer we first start to settle on a list of features we want based on the spec.The things we want to disable *optionnaly* and gradually etc. I thought we had a consensus but apparently not. What is needed to be changed against [1]? About some security issues: Cookies should be based on an auth domain . I'm still waiting for a proper test but if we have an issue let's fix it. [1] https://issues.apache.org/jira/browse/COUCHDB-431?focusedCommentId=13107316&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13107316 > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157649#comment-13157649 ] Jason Smith commented on COUCHDB-431: - Rebased my patch set to Randall's new branch: https://github.com/jhs/couchdb/compare/COUCHDB-431...COUCHDB-431_jhs Branch is https://github.com/jhs/couchdb/tree/COUCHDB-431_jhs > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157643#comment-13157643 ] Jason Smith commented on COUCHDB-431: - The patch remains a significant security vulnerability and not useful to web developers. > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157634#comment-13157634 ] Randall Leeds commented on COUCHDB-431: --- I wanted to bump this discussion again so we can get this patch landed. I created the COUCHDB-431 branch on the project git repo and broke the tests out. The tests are committed now, which hopefully gives us a good target and stable base for applying alternative implementing patches. Jason and Benoit: If there is consensus on an implementation, please tell me and I will commit it there. If not, please say so and I'll go back and review this again since they're not fresh in my mind. > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[
https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107450#comment-13107450
]
Jason Smith commented on COUCHDB-431:
-
Hi, Benoit.
WRT #4: Randall explained his idea in IRC. The idea happens if and only if
couch is handling a cross-origin query with credentials.
1. Browser provides credentials in the HTTP query, e.g. #httpd{}=Req
2. During authentication, Couch fetches the _user doc
2. In the _user doc, check for "_cors_auth":true or maybe "_never_cors":true --
it could be opt-in or opt-out
3. If _never_cors == true, then Req2 = Req#httpd{user_ctx =
#user_ctx{name=null, roles=[]}}
4. Process Req2
Thoughts:
1. This is not non-standard but perhaps non-expected. w3c has no opinion about
whether Couch should honor good X-O creds
2. One problem: developers set _never_cors=true and then assume their users are
safe over open WiFi. In fact valid credentials are sent over the wire.
So the question is, what is the net change to the security? My feeling is, the
risk of TCP sniffing at a cafe is small, whereas the risk of XSRF attacks is
greater. Also, to what degree is it nonstandard?
> 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107347#comment-13107347 ] Benoit Chesneau commented on COUCHDB-431: - @tilgovi thnks to summarize this 1) + 1, I would still propose an option to completely disable it if some want though 2) It could be done like in the vhost module when you expose global module you want to be available in the vhost maybe? 3) +1 4) That's not how CORS is intended to work. But thinking of it maybe we could have an option in the rewriter to disable/enable cors on a "from" path ? I can do such patch and have it mostly done (modulo the global thing). > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107344#comment-13107344 ] James Burke commented on COUCHDB-431: - I apologize, but I cannot follow the full thread. I just want to put in my suggestion for the behavior of this feature: * Default server setup: no CORS enabled, no cross origin requests allowed. * Developer should have to opt in to enable any type of CORS, and should need to explicitly set an origin or set of origins. It should not default to "*", but the developer should have the option to enter "*" manually. This is the safest default setup, and is in line with current server expectations, that by default browsers cannot make cross origin calls to servers to receive data. Again, I apologize if my comments are already part of the implementation plan. I opened this ticket, and even though I like CORS, I want to make sure couch users do not get any cross origin surprises/unintended CSRF requests in the default configuration. > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107317#comment-13107317 ] Randall Leeds commented on COUCHDB-431: --- If my points (3) and (4) make sense they should be rolled together, with users deciding which of the origins the host shares with should be allowed to use their credentials, and which should be allowed to use their admin credentials. Maybe it makes sense for the user doc to have a mapping of origins to roles. If this mapping is non-empty then A-C-A-C: true and requests get the intersection of the users roles and the origin roles. In this way, I can have many roles on a server but only share some of them with certain origins. Of course, the db-level configuration is still required to enable the origin to access anything at all, but I'd submit that with the credentials defaulted off that the default allowed origins should be */* when CORS is enabled, though I'm willing to go either way on this. > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107316#comment-13107316 ] Randall Leeds commented on COUCHDB-431: --- I propose the following concrete actions: 1) Make default Access-Control-Allow-Credentials: false, which only allows unauthenticated requests. This would allow the cross-origin browser client to do no more than any other client on the web. This seems safe AND useful. I'd even be fine with CORS enabled by default if this is the case. 2) Punt on everything but the db-level _security object. No CORS for resources like /_session, etc. As an example of why it seems like you need /_session but you don't, remember that a couchapp could expose a well known URL for a login page popup, which is very much like browserid, facebook connect, etc. 3) Have a separate, default-off toggle for enabling the _admin role on authenticated requests. In other words, if the request is a CORS request AND Access-Control-Allow-Credentials is on for the origin, couch should by default strip the _admin role (if the cookie'd user has it). 4) Does it make sense to configure Access-Control-Allow-Credentials information on the user document? In other words, some couch trusts a set of origins for a particular set of dbs (apps), but users still need to allow it as well. This behavior mirrors things like OAuth: api key : origin enabled :: auth flow : allowing credential use I think this gets us 80% of the use cases and feels pretty safe. Concrete suggestions/recommendations/criticisms? If you want me to implement any of this let me know. I'd be happy to do it. I'd rather see features stripped out of this and have a minimal viable CORS in 1.2 than to leave it out completely because it's, uh... next level beats for couchapps. :-D. > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107275#comment-13107275 ] Benoit Chesneau commented on COUCHDB-431: - oh sorry you take it fir you. wasn't rhe case. on the contrary i was saying ithdt this was'bt a response to you. everything is fine and your quote is right. fixing it. On Saturday, September 17, 2011, Robert Newson (JIRA) https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107254#comment-13107254] based eventually of mine you are referring to? My last comment asked a specific question about a quoted part of your patch, I thought it was quite polite. I'm baffled by the determination to find hostility in comments that appear to contain none. I certainly intend none, I just want to understand the security implications of this change before it is included in an official release. Control spec --- 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 (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: 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. 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. so no POSTing or PUTing of documents. of Firefox 3.5): Safari 4): http://developer.apple.com/safari/library/documentation/AppleApplications/Conceptual/SafariJSProgTopics/Articles/XHR.html through their XDomainRequest object (XDR): headers should be enough, and hopefully IE 9 will allow normal xdomain requests via XHR. > 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 eno
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107254#comment-13107254 ] Robert Newson commented on COUCHDB-431: --- "not to @rnewson : i would appreciate that rather than putting comments based on philosophy or business we talk about code and lines to fix or eventually change. thanks." I'm unsure as to what you are referring to here, could you quote the words of mine you are referring to? My last comment asked a specific question about a quoted part of your patch, I thought it was quite polite. I'm baffled by the determination to find hostility in comments that appear to contain none. I certainly intend none, I just want to understand the security implications of this change before it is included in an official release. > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107231#comment-13107231 ] Benoit Chesneau commented on COUCHDB-431: - bah i already said a few times this will be take in consideration :/ @rnewson most of services are doing ghat but i will propose an option to not do that . not to @rnewson : i would appreciate that rather than putting comments based on philosophy or business we talk about code and lines to fix or eventually change. thanks. On Saturday, September 17, 2011, Robert Newson (JIRA) https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107222#comment-13107222] However, I'll drop it. asks it to (just include Origin: foo), that can't be right, can it? My meager understanding of CORS is that the server should make this determination. focus when I hit return or use the shift key. Perhaps there's JS on the page that doesn't work with Chrome 14 but it's making everything really painful. I'm going to refrain from further comments until I've thoroughly read the CORS draft, and others should chip in too. I particularly would like Benoit to correct my understanding of the above function. Control spec --- 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 (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: 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. 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. so no POSTing or PUTing of documents. of Firefox 3.5): Safari 4): http://developer.apple.com/safari/library/documentation/AppleApplications/Conceptual/SafariJSProgTopics/Articles/XHR.html through their XDomainRequest object (XDR): headers should be enough, and hopefully IE 9 will allow normal xdomain requests via XHR. > 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 ar
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107224#comment-13107224 ] Benoit Chesneau commented on COUCHDB-431: - mmm @jason don give me words I didn't say. Please reread the patch and what my comment means. I never meant security shouldn't be take in consideration. anyway can we calm down a little.I will provide another itteration on monday. Then we could fdiscuss about it. > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[
https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107222#comment-13107222
]
Robert Newson commented on COUCHDB-431:
---
Agreed, though I don't see any of those items in the thread so far. However,
I'll drop it.
I'm reading this part of the latest patch;
+set_default_headers(MochiReq) ->
+case MochiReq:get_header_value("Origin") of
+undefined ->
+erlang:put(cors_headers, []);
+Origin ->
+DefaultHeaders = [{"Access-Control-Allow-Origin", Origin},
+ {"Access-Control-Allow-Credentials", "true"}],
+erlang:put(cors_headers, DefaultHeaders)
+end.
+
This does appear to grant access control to any sites that the request asks it
to (just include Origin: foo), that can't be right, can it? My meager
understanding of CORS is that the server should make this determination.
I'm *really* struggling with JIRA right now, it's constantly removing focus
when I hit return or use the shift key. Perhaps there's JS on the page that
doesn't work with Chrome 14 but it's making everything really painful. I'm
going to refrain from further comments until I've thoroughly read the CORS
draft, and others should chip in too. I particularly would like Benoit to
correct my understanding of the above function.
> 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107216#comment-13107216 ] Noah Slater commented on COUCHDB-431: - For the record, my remark was addressed to everyone involved. I know people are feeling frustrated, but let's stay objective and focus on technical criticism without making things personal, falling back on logical fallacies, or resorting to hyperbole. > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107212#comment-13107212 ] Robert Newson commented on COUCHDB-431: --- This need not get heated (though I don't read Jason's prose are inflammatory, I think he's just trying to make his view that there are serious security problems in the current patch in as direct a manner possible). If this is intended for 1.2, as this ticket claims and Jan confirms, then it's important to verify and remedy any security problems this patch can introduce soon. I suggested 1.3 in order to give us more time to evaluate. (in addition to feeling that 1.2 has enough new goodies in it). I don't think anyone is arguing against supporting CORS, clearly there's value in it. To Jason, Benoit is adding black- and white-listing, does this fully address your concerns or not? > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107183#comment-13107183 ] Noah Slater commented on COUCHDB-431: - Guys, can we tone it down a bit please? > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107177#comment-13107177 ] Jason Smith commented on COUCHDB-431: - Stop talking about CORS being disabled by default. What an ignorant thing to say! When disabled, Benoit's patch leaves Couch unchanged. When enabled, every site on the Web can query your couch with your users' credentials. Why in God's name would anybody ever enable CORS then? Here stands an exploit clearly demonstrating this fact. I invite anybody interested to apply the patch and play with my exploit. To say it "implements the spec" is to miss the point. > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[
https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107168#comment-13107168
]
Jason Smith commented on COUCHDB-431:
-
CORS bugs allow cross-site request forgery (XSRF) attacks--the most dangerous
threat on the Web.
IMHO, to say "CORS is not about security" is to disqualify one from making an
implementation.
CORS is a three-body problem:
1. Client = browser
2. Server = couch
3. Origin = site the browser is on, a tuple {protocol, hostname, port}, e.g.
http://www.naked-ladies.com:80
The word "sharing" sounds nice and friendly. It reminds me of kindergarten.
That word is misleading.
Attention Couch developers and administrators: naked-ladies.com and every other
site on the Web is, even now, attacking your couch, fetching and storing data,
and they have ALL OF YOUR USERS' session cookies.
naked-ladies.com does this by attracting visitors to their site, and sending
Javascript to the browsers to perform their attacks for them. Your ONLY
protection is that browsers will not (generally) query to a different domain.
With CORS, browsers will query, but only if the couch tells them it is okay. We
are seriously playing with fire here.
Databases are not characters in this story. Per-database CORS settings
make as much sense as per-database user accounts. Practically, syncing
_security objects between multiple databases will be a complete nightmare. And,
it presents a race condition where cross-origin policies are incorrect between
DB create and _security updates.) But what about /_session? How come
www.origin.com can access /origins_db/ but once your session times out, it
can't reconnect? How come it can't fetch some /_uuids?
> 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 informat
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107164#comment-13107164 ] Alex Chaffee commented on COUCHDB-431: -- "CORS isn't about security. It means Cross-Origin Resource Sharing . We shouldn't forget that." True! As I said back in May[1]. Admittedly this is a nuanced distinction, but if you think it's about security, then you misunderstand either what CORS is or what security means. [1] "it's not hard security, just a message from the server that tells the client "here's the data, and here's a hint about how I think you should use it" (which hint is ignored by everybody except web browsers)." - comment 13041182 I haven't looked at the patch code yet but if you do a whitelist please make sure it is disableable, or at least that it supports all variations of localhost (127.0.0.1, 0.0.0.0, file:///...) since I'd like to use CouchDB as a store for a Chrome browser plugin (with couch and browser running on the same machine). > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107163#comment-13107163 ] Alex Chaffee commented on COUCHDB-431: -- "CORS isn't about security. It means Cross-Origin Resource Sharing . We shouldn't forget that." True! As I said back in May[1]. Admittedly this is a nuanced distinction, but if you think it's about security, then you misunderstand either what CORS is or what security means. [1] "it's not hard security, just a message from the server that tells the client "here's the data, and here's a hint about how I think you should use it" (which hint is ignored by everybody except web browsers)." - comment 13041182 I haven't looked at the patch code yet but if you do a whitelist please make sure it is disableable, or at least that it supports all variations of localhost (127.0.0.1, 0.0.0.0, file:///...) since I'd like to use CouchDB as a store for a Chrome browser plugin (with couch and browser running on the same machine). > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107157#comment-13107157 ] Benoit Chesneau commented on COUCHDB-431: - To be clear next version of this patch will handle black or white listing, be disabled by default and will allows to disallows any admins actions via cors if the settings is set. So it should address any concerns here I think. WIll push that on monday. > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107080#comment-13107080 ] Jan Lehnardt commented on COUCHDB-431: -- @Robert, Benoit raised this to be proposed for 1.2.x before the branching. No saying it should wait because we branched is not fair :) Pending that we solve any issues with this. The "whether there are security implications" sounds superfluous to me, vhosts e.g. is not about security, but it does have security implications when used wrongly. If CORS has any of this, we a) need to make sure it is properly documented and b) probably prefer to ship off by default which I think is happening here. (PS. sometimes happens when I accidentally the trackpad while typing) > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107076#comment-13107076 ] Benoit Chesneau commented on COUCHDB-431: - Having security implications and considering it as a security thing is different... Maybe my french failed here. What the spec describe is a way to allows or forbid cross origin requests on resources. Security is another topic. What the spec says about security is is already implemented in current diff anyway: http://www.w3.org/TR/cors/#resource-security And like I said, it strongly encourages to use ssl. > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107071#comment-13107071 ] Robert Newson commented on COUCHDB-431: --- I can't comment on the patch right now but I do want to dispute " really don't want to considers CORS as a security thing". Clearly CORS has security implications, it's about access control. Further, the spec has much to say on security considerations. That said, it's a replacement for JSONP which also has security implications. I think this should land in 1.3 rather than 1.2 as we've already branched. (P.S anyone else having issues typing in JIRA comment windows? Something keeps removing focus from the edit box when I'm typing) > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ 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 XMLHttpR
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13094246#comment-13094246 ] Jason Smith commented on COUCHDB-431: - CORS is about cross-site security. Which *origins* should CouchDB trus? Which third-party sites may query Couch through their users' browser and with their users' credentials? The answer is clear: none of them, except by explicit permission. Setting DB _security is not sufficient. CouchDB should be secure by default. But the latest patch permits (forces!) authenticated queries from every origin. Even with _security, foreign sites might access /_config, /_status, /_restart, and /_log. Any site on the web might guess your Couch URL (localhost:5984 and well-known cloud couches perhaps) and query it as you. If you logged in as admin (naughty!) then they can edit /_config. If you logged in as a user, they can at least check /_all_dbs and probe for an unprotected DB (one with the default config). None of this should be possible, and that is why my 3-month-old patch takes the following precautions: 1. Disabled by default 2. Simple configuration model: which origins do you trust? Put them on the whitelist. 3. Subsequent versions (whoops, not attached) disallow all cross-origin admin queries. verify_is_server_admin/1 always fails if an "Origin" header is present. > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13093939#comment-13093939 ] Benoit Chesneau commented on COUCHDB-431: - This is just expected behavior when you reuest credentials. You can block this "exploit" by setting the origins you want to accept in the db security object. I'm not sure this is really an issue here. web is based on trust by nature. Anyway we can add the following features : - 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 I will proposea patch that does that in coming hours. Would it solve your expectations? > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13093940#comment-13093940 ] Benoit Chesneau commented on COUCHDB-431: - This is just expected behavior when you reuest credentials. You can block this "exploit" by setting the origins you want to accept in the db security object. I'm not sure this is really an issue here. web is based on trust by nature. Anyway we can make however is : - 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 I will proposea patch that does that in coming hours. Would it solve your expectations? > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13093219#comment-13093219 ] Adam Kocoloski commented on COUCHDB-431: Hi Benoit, thanks for the clarification. That Simple header list doesn't quite seem to correspond to the lists from the W3C spec, but ok. I agree that a method for customizing allowable headers would be good. I wonder if we should future-proof this a bit by using cors.origins or xhr.origins instead of a top-level origins key in the security object? > 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, > 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, > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13093103#comment-13093103 ] Benoit Chesneau commented on COUCHDB-431: - Hi Adam, thanks for the review, You're correct, the process is : 1) set default cors headers 2) on OPTION check asked capabilities and eventually return preflight headers. At this steps CORS headers can be []Â (capability not handled or the list preflight headers like the spec require. 3) on db , we check origin header in a list of origin. Eventually we reset cors headers to null if the origin isn't supported I will remove my custom headers, sorry for that. Maybe at some point we could allow people to add their own header via the settings. About Simple and Couch that's mostly to distinct them, simple headers are defined by the spec. But I could join them. I don't know what's the best for that. I will push the patch later tonight with above fixes and doc. - benoit > 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, > 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, > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092979#comment-13092979 ] Adam Kocoloski commented on COUCHDB-431: I'm trying to digest this patch and finding it a bit difficult. I understand the motivation behind the use of the process dictionary, but I think the function names don't make it obvious which ones are mutating the cors_headers. Reading the patch I think that list is: couch_httpd_cors:set_default_headers/1 couch_httpd_cors:preflight_headers/2 couch_httpd_cors:db_check_origin/2 and the basic gist is, 1) reset cors_headers at the start of request processing, 2) if the request method is OPTIONS, advertise the capabilities using the preflight_headers functions, 3) else, check the Origin against the list of allowed Origins specified in the _security object. If I'm reading this correctly, the cors_headers that db_check_origin/2 sets on a successful match are already set by set_default_headers/1 in the beginning of the request processing. I guess it doesn't hurt to be explicit. What's the rationale for splitting the headers into SimpleHeaders and CouchHeaders in the preflight_headers function? It seems to be purely cosmetic. I don't know what criteria were used for including headers in that list, but I'm guessing X-Upondata-Api-Key was included inadvertently :) I don't recognize X-Couch-Auth-Key either. I think this is one patch where we need a pretty thorough commit message describing the feature. > 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, > 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, > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092711#comment-13092711 ] Benoit Chesneau commented on COUCHDB-431: - Jason, Randall did you manage to get further? I don't see any real issue right now (not more than we could have with any http client). Except you really find something I think it's safe to put it in trunk to let people to test it. thoughts? > 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, > 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, > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13091990#comment-13091990 ] Randall Leeds commented on COUCHDB-431: --- I haven't checked the test suite but the patch looks great now. Thanks, Benoit! I like that putting that in a separate module and it's all much easier to read now. If you don't mind holding off a little bit longer, I'd just like to digest Jason's concerns since I was mostly reviewing style and performance rather than security and proper specification. I'll follow up with him on IRC. > 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, > 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, > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13091659#comment-13091659 ] Benoit Chesneau commented on COUCHDB-431: - Thanks for the review. Answers follow 1. session is working even if the db is protected by readers. like any preflight request. I wrote the patch like that 2. Actually the patch works with a db protected against readers. If you are authenticated, a CORS request will works,. Allows-credentials is always True in couch, we always test credentials and cookies internally anyway. You can test it with test_cors2 /../cors2.html 3. Security: The patch actually means that we accept from any connections on a db except you filter origins in a db. If you filter origin a db will only be accessed by this origin. It won't increase risks, since then an ajax client is just considered like any HTTP client. If you already have some exploits then they are already feasible with any http client that doesn't care about cross domain which is only a browser things. I don't see any other way to bypass our small security. If you want a better protections, some modules can be added to couch, couch_throttle, filtering users depending on the referrer or hosts, etc...I have some if you are interested ;) 4. Applications and multiples db. That's not how the system was designed until now (and you will have other problem to handle before to go on origin sync). I can see that happen however, but I don't see the real problem of keeping dbs origins synchronized. Also what if your db is dispatched on multiple hosts. This isn't really a problem I think. I would like to keep db origin filtering, it actually works well with the current couchdb design. If we want more granularity we can discuss it and add it later imo. There are a lot to do on that part, but that's another debate and ticket imo > 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, > 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, > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13091575#comment-13091575 ] Jason Smith commented on COUCHDB-431: - Benoit, love the patch. I originally developed _security object support but now I think it has several problems. CORS is fundamentally about which *origin* may query cross-site, and whether the query must be anonymous, or may be authenticated. The best model is to specify which domains (origins) Couch trusts, and to what degree (anonymous vs. authenticated). A couch app lives within CouchDB but not completely within a database. Global handlers are generally needed for couch apps (/, /_replicate, /_utils, _session, _uuids). For cross-domain Couch to be useful, the global handlers must have a compatible CORS policy as the database. _session is particularly important because if your session on couch has expired, the page on www.example.com needs a way to log you back in transparently. Applications can use multiple databases. Once CORS ships, I envision a Cambrian explosion of couch services and Javascript APIs to add couch features to any web page. Many apps will provide one database per user. Keeping _security synchronized will be one extra hurdle for developers to clear. Finally, CORS is security-sensitive. I would hate to ship an XSS security vulnerability. In your patch, set_default_cors_headers seems to set Access-Control-Allow-Origin: $your_origin; Access-Control-Allow-Credentials: true. Those headers mean that any site on the Internet can force any user to perform any query on the Couch, with their session cookie. That is probably undesired. I have not audited your patch completely so perhaps I am wrong. At this point, I wonder if you agree with me that DB _security settings could be omitted for this time, and perhaps added later? > 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, > 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, > 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 JI
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13091363#comment-13091363 ] Benoit Chesneau commented on COUCHDB-431: - right it doesn't really matter. will merge then. > 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, > 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, > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13091360#comment-13091360 ] Randall Leeds commented on COUCHDB-431: --- 3) The problem is that someone could have put "*" anywhere in teh list. We want to test it first. Why does that matter? If we come across an explicit match before * isn't that fine, too? 8) mmm i like the separation in 2 funs here, easier to read, at least for me. But will see Sounds good. Whichever way you want. No strong preference. > 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, > 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, > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[
https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13091354#comment-13091354
]
Benoit Chesneau commented on COUCHDB-431:
-
Thanks a lot for the review. I will update the patch later this morning
(12:07am here) . Comments follow.
1) In check_origin/2, when * is in the AcceptOrigins would it be better to
return * so that we send * in the "Access-Control-Allow-Origin" header?
Since we return Access-Allow-Credentials header the spec says we should
retutn the origin. WIthout it anyway authentication won't work.
2) could you pre-split Origin in check_origin/2 before passing it to
check_origin1/2 so that we don't call mochiweb_util:urlsplit/1 repeatedly?
ok
3) Makes sense to me to join check_origin/2 and check_origin1/2 into a single
function. Use function guards to convert the accepted origins as you need them
and to find the "*" case, avoids looping through the accepted origins twice
(once for couch_util:to_list and once for lists:member).
The problem is that someone could have put "*" anywhere in teh list. We
want to test it first.
4) Typo in set_prefilight_headers/4, clause 2, capitalization in
Access-Control-ALlow-Headers
thanks will fix it
The rest are mostly aesthetics:
5) set_prefilight_headers -> set_preflight_headers typo (extra i)
will change that
6) You catch the case where erlang:get/1 in cors_headers/0 returns undefined,
but that's impossible because you call set_default_cors_headers/0. It makes
more sense to me to take out set_default_cors_headers/0 and just set the
defaults in the undefined erlang:get/1 case. That means cors_headers/0 becomes
cors_headers/1 and takes a mochiweb request record.
7) Move cors_headers/0 up near default_origin_headers/1
ok
8) I would get rid of set_preflight_headers/4 entirely. In
preflight_cors_headers create PreflightHeaders0 after you get Origin1. Add
{"Access-Control-ALlow-Headers", FinalReqHeaders} to PreflightHeaders0 in the
last clause of the case and let PreflightHeaders be the result of the case.
just call erlang:set/2 from there.
mmm i like the separation in 2 funs here, easier to read, at least for
me. But will see
9) whitespace change at couch_httpd_db (-212, +247)
didn't notice, thanks
> 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,
> 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,
> 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 requ
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[
https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13091349#comment-13091349
]
Randall Leeds commented on COUCHDB-431:
---
Comments:
1) In check_origin/2, when * is in the AcceptOrigins would it be better to
return * so that we send * in the "Access-Control-Allow-Origin" header?
2) could you pre-split Origin in check_origin/2 before passing it to
check_origin1/2 so that we don't call mochiweb_util:urlsplit/1 repeatedly?
3) Makes sense to me to join check_origin/2 and check_origin1/2 into a single
function. Use function guards to convert the accepted origins as you need them
and to find the "*" case, avoids looping through the accepted origins twice
(once for couch_util:to_list and once for lists:member).
4) Typo in set_prefilight_headers/4, clause 2, capitalization in
Access-Control-ALlow-Headers
The rest are mostly aesthetics:
5) set_prefilight_headers -> set_preflight_headers typo (extra i)
6) You catch the case where erlang:get/1 in cors_headers/0 returns undefined,
but that's impossible because you call set_default_cors_headers/0. It makes
more sense to me to take out set_default_cors_headers/0 and just set the
defaults in the undefined erlang:get/1 case.
7) Move cors_headers/0 up near default_origin_headers/1
8) I would get rid of set_preflight_headers/4 entirely. In
preflight_cors_headers create PreflightHeaders0 after you get Origin1. Add
{"Access-Control-ALlow-Headers", FinalReqHeaders} to PreflightHeaders0 in the
last clause of the case and let PreflightHeaders be the result of the case.
just call erlang:set/2 from there.
9) whitespace change at couch_httpd_db (-212, +247)
Obviously some of that is style, but some is substance. Take what you want.
Nice work! Thanks for doing this.
> 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,
> 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,
> 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.co
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13090391#comment-13090391 ] Robert Newson commented on COUCHDB-431: --- Don't get me wrong, the lines in this module are far too long anyway, but reindenting makes it harder to see the substantive change you're making. The first one where you added "OPTIONS" was the one I was referring to, but I had failed to notice that the before/after were different. Given the alternative is to make these overlong lines even longer, I guess there's no need to change it, but I'd refactor this into two commits, one which simply wraps these long lines better and a second that then adds the extra bits. Not a deal breaker for me if you don't do it. > 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.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, > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13090384#comment-13090384 ] Benoit Chesneau commented on COUCHDB-431: - mmm by indentation change do you mean the new lines added with new options ? I can probably put them back on one line if it's better. Or did I miss other things (which is totally possible I'm a little blind tonight)? New patch remove this spurious log is coming. > 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.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, > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13090381#comment-13090381 ] Robert Newson commented on COUCHDB-431: --- The new patch combines indentation changes with code changes, can that be separated? > 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.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, > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[
https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13090382#comment-13090382
]
Robert Newson commented on COUCHDB-431:
---
also '?LOG_INFO("la", [])' probably shouldn't be in here, right? :)
> 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.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,
> 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048972#comment-13048972 ] Benjamin Eidelman commented on COUCHDB-431: --- I'm writing a small js lib that loads from REST services, I wanted to run it against my couchdb hosted on a VM, or even if it's local the test (QUnit) page can run locally (file://), just to be able to run the tests I made a a (lame) workaround, created a small js and html page that I load in CouchDB, then from my test page I load this CouchDB-hosted page in a hidden iframe, and proxy all ajax calls thru that iframe (using window.postMessage). ust for testing purposes, it anyone is interested: https://github.com/benjamine/FrameProxy But I'll love to see CORS implemented in CouchDB and throw that script+page away! > 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: Randall Leeds >Priority: Minor > Fix For: 1.2 > > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048969#comment-13048969 ] Jason Smith commented on COUCHDB-431: - I agree, Jacques. CORS will be the microwave oven, or the television. Once it is out and available, people will wonder how they lived without it. The patches apply against 1.1.0 (and applied against trunk when I made them). Apply them all in numeric order. I am planning to make a new patch set called B_0001, B_0002, etc. but for now there is just the As. > 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: Randall Leeds >Priority: Minor > Fix For: 1.2 > > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045442#comment-13045442 ] Jacques Desmarais commented on COUCHDB-431: --- I would really like to see CORS support in Couch. I see a big need for using cloud hosted web apps but keeping one's data on one's intranet. Jason, thanks for the patches. Any tips on applying them? Does one apply just one or all of them at once? Against what version of couch can they be applied? For testing purposes of course... > 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: Randall Leeds >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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13042512#comment-13042512 ] Alex Chaffee commented on COUCHDB-431: -- Sorry for using unclear language -- you're absolutely right, I'm talking about adding headers per *service* (i.e. host-and-port), not per *database* in Couchese. You're also quite right about the danger of '*' -- I used it as shorthand but it would be more sensible to use the real domain name of your host -- which would actually take care of the attack vector you mentioned. I'm confused about your "dynamically generated header" paragraph. The CORS header must match the domain name(s) of the valid web site(s), which seems pretty static to me. Or are you just saying again that you'd like the header to vary per database? Note that a single Access-Control-Allow-Origin header can contain multiple hostnames (if I read the spec at http://www.w3.org/TR/cors correctly) so you could serve two sites from the same service with "Access-Control-Allow-Origin: site1.com site2.com". (Assuming the browsers implement the spec correctly, of course! :-)) Here's my use case: I want to write an app that goes directly from JavaScript in a web browser to a CouchDB service running on localhost (and eventually, on an optional public server). It seems like a perfect fit and it's frustrating that it doesn't work, especially since it's just for lack of a single HTTP header. I'm currently building a simple Ruby HTTP server to sit between the browser and Couch, but there's really no reason for that third tier. Got any ideas on how to smuggle in a response header without your ACL patch? > 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: Randall Leeds >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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13041415#comment-13041415 ] Jason Smith commented on COUCHDB-431: - I am open to the idea of a global (or per-vhost) CORS setting, on the basis that it is simple: easy for users, and easy to reason about. The only problem with this is so much security is already database-oriented. Access and admin permission is per-db. And httpd/secure_rewrites provides isolation inside the DB. Is it going against the grain to do some HTTP security in the server config? With a global config, you could not have /db_A to service webappA.com *only*, and /db_B to service webappB.com *only*. To have two unrelated sites use two unrelated databases, you must run two couches. But still, the simplicity is interesting. > 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: Randall Leeds >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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13041410#comment-13041410 ] Jason Smith commented on COUCHDB-431: - Alex, thanks for your thoughts. Some feedback: I disagree that CORS is not hard security. It is hard security because same-origin is the primary protector of all data on the web. Without same-origin restrictions, any site you visit could reach your data on any other site you visit. It is also hard security in that it is both difficult and important to get right. I am hoping for a fail-safe system. It seems reasonable that the database admin should control the CORS permissions of that database. For a /_config change, that requires the server admin. The _config imposes practical problems too. It is not a general system registry: all the data must go section-key-value. There is no way to have a per-database config except to use an entire new section as a namespace, with each DB name inside it. IMO I don't like that at all. The only place I know of for per-database config is the _security object. Since CORS is about security, it's logical to place it there (where the db admin can modify it). Finally, the original idea that I heard about CORS was to allow people to specify any header. I don't think that is fail-safe. I have no idea what headers people use out there. It seems impossible to evaluate the security of permitting any header for any response. Finally, CORS headers are generally generated dynamically. The only exception is the wildcard header which for CouchDB would be a very dangerous setting. That means any code from any site on any browser can access your couch without the user knowing but (potentially) with the user's couch credentials. Therefore, I am hoping for a whitelist to specify, "yes, www.mywebapp.com is my own website and I trust all its code to access this couch". > 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: Randall Leeds >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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[
https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13041182#comment-13041182
]
Alex Chaffee commented on COUCHDB-431:
--
I just encountered this issue myself, and I haven't thought through all the
implications, but isn't there an easier way to crack this nut? If we add a
"response_headers" config setting to the normal database httpd config, and the
server adds those headers to every HTTP response, then that's it. Admins can
then implement a coarse form of CORS on a per-database level with a simple
"{response_headers: {'Access-Control-Allow-Origin': '*'}}".
If more fine-grained control is needed (e.g. allow CORS for some client IP#s
but not others) then a patch like Jason's would be needed. But ACL systems are
notoriously difficult to design and implement. My solution leaves access
control up to the local admin, and also makes it clear just how simple CORS
actually is -- it's not hard security, just a message from the server that
tells the client "here's the data, and here's a hint about how I think you
should use it" (which hint is ignored by everybody except web browsers).
(cf. Mozilla: "The Cross-Origin Resource Sharing standard works by adding new
HTTP headers that allow servers to describe the set of origins that are
permitted to read that information using a web browser. Firefox supports these
headers and enforces the restrictions they establish."
https://developer.mozilla.org/en/http_access_control )
Thoughts?
> 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: Randall Leeds
>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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[
https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034526#comment-13034526
]
Jason Smith commented on COUCHDB-431:
-
Whoops, Access-Control-Request-Method and Access-Control-Request-Headers.
Anyway, the _security object would have some benefits. I already had to add
another patch to disable _admin stuff with CORS because it's just too scary. If
better-futon.com ever got hacked, or if somebody got untrusted javascript code
hosted there, that code would have ADMIN access to your couch.
So my new patch has _config/httpd/cors_admin = true/false (default false) so
that no CORS request can ever run with server _admin permissions.
With a _security object, there's some flexibility.
1. Indicate whether to allow CORS for the db _admin too (default would be
false).
2. See the CORS policy from validate_doc_update() because it will be in secObj.
So you might have a _security:
{ "admins": { "roles": [ "my_app_admins" ] },
"readers": {},
"cors": { "http://a-cool-couchapp.com": true // Implied anonymous access only
"https://another-couchapp.com": { "timeout": 86400 }, // Also
anonymous-only
"https://another-couchapp.com": { "timeout": 86400,
"allow_credentials": true }, // Authenticated access
"https://another-couchapp.com": { "timeout": 86400,
"allow_credentials": true, "allow_admin":true }, // Authenticated access,
including db admin
}
}
However I am stopping here to get some discussion going before writing more
code. I am super excited about Couch CORS however
> 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ 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 >
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034246#comment-13034246 ] Randall Leeds commented on COUCHDB-431: --- Jason: Do you know what resource/path the requesting browser/client uses when asking permission? In other words, how does this interact with vhosts? Would it be better to place this information at the db-level? I know we talked about that last week about possibly putting it on the security object. > 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
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13033669#comment-13033669 ] Jason Smith commented on COUCHDB-431: - I made a patchset to enable Cross-Origin Resource Sharing from CouchDB. I will attach them to JIRA. The point of CORS is, instead of the classic same-origin security policy, browsers will ask the "foreign" server's permission first. The foreign server can indicate whether the browser's origin is trusted and what if any HTTP stuff is allowed. With permission granted, XHR requests to the foreign resource work just like normal. My implementation uses the couch config. To enable CORS, set /_config/httpd/cors = "true". Then the "cors" section is just like the "vhosts" section. To have couch.com:5984 trust code from cool.app.com and also lame.app.com, you would set /_config/cors/couch.com:5984 = "http://cool.app.com http://lame.app.com"; (mnemonic: same format as the w3c Origin header). The upshot is you can $.couch all day long, from any web page to any number of couches. But the couches have to whitelist you first. Also, a validate_doc_update() function can check req.headers.Origin to act on local vs. cross-origin queries. > 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 > > 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
[jira] Commented: (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[
https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999196#comment-12999196
]
Benjamin Eidelman commented on COUCHDB-431:
---
if it helps, an ajax cross-domain request with jQuery:
var uspwd64 = base64.encode('username:password');
jQuery.ajax({
url: url,
beforeSend: function(req){
req.setRequestHeader("Origin", document.location.protocol +
"//" + document.location.host);
req.setRequestHeader("Authorization", "Basic " + usrpwd64);
},
type: 'POST',
data: mydata,
> 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
>
> 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
[jira] Commented: (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12991259#comment-12991259 ] Marc Diethelm commented on COUCHDB-431: --- For cross domain requests other than GET or POST Firefox will first attempt an OPTIONS request (a "preflighted" request). If this doesn't succeed the operation is aborted. My project's use case is as follows: The website's HTML, CSS, JS is served from Apache, all the data (eg: userdata, images and their metadata) is stored in CouchDB. I need to create an attachment on a not yet existing document. Therefore I'm PUTting the attachment to CouchDB as described in http://wiki.apache.org/couchdb/HTTP_Document_API#Standalone_Attachments. Firefox sends this request: OPTIONS /dbname/document/attachment HTTP/1.1 Host: hostname:5984 [...] Origin: http://hostname Access-Control-Request-Method: PUT CouchDB of course doesn't know about OPTIONS and responds with: HTTP/1.1 405 Method Not Allowed Server: CouchDB/1.0.1 (Erlang OTP/R13B) [...] Allow: DELETE,GET,HEAD,PUT > 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 > > 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
[jira] Commented: (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12734753#action_12734753 ] Adam Kocoloski commented on COUCHDB-431: cool stuff! This is the first I've heard of it. > 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 > > 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. - You can reply to this email to add a comment to the issue online.
