[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-tabpanelfocusedCommentId=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] [Updated] (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:all-tabpanel
]
Jason Smith updated COUCHDB-431:
Attachment: A_0004-Respond-to-CORS-preflight-checks-HTTP-OPTIONS.patch
A_0003-Usably-correct-w3c-CORS-headers-for-valid-requests.patch
A_0002-Send-server-headers-for-externals-responses.patch
A_0001-Generalize-computing-the-appropriate-headers-for-any.patch
Initial idea. This has very heavy couch_config:get/2 calls. Couch now prevents
_show and other functions from handling HTTP OPTIONS, because this
implementation simply checks for OPTIONS early on and return {ok:true}. CORS
uses OPTIONS to request permission but only the response headers matter.
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
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] [Updated] (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:all-tabpanel ] Jason Smith updated COUCHDB-431: Attachment: cors.html A file I was using for testing. 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
Re: Helping out with releases
Just wanted to ask what the status of either release is? Are the two tests failing still failing, or can we move on to make dist? :-) Till On Thu, May 12, 2011 at 5:15 PM, Benoit Chesneau bchesn...@gmail.com wrote: On Thu, May 12, 2011 at 4:31 AM, Randall Leeds randall.le...@gmail.com wrote: On Tue, May 10, 2011 at 06:54, Paul Davis paul.joseph.da...@gmail.com wrote: On Tue, May 10, 2011 at 9:49 AM, Jan Lehnardt j...@apache.org wrote: Putting 140 on an infinite loop (while(true); do ./test/etap/run test/etap/140-attachment-comp.t ; done) eventually gives me http://www.friendpaste.com/2JCA8dvre9orA3UysYYTCe on both SSD Mac OS X 10.6 and Ubuntu 10.04 on disk in a VMWare. That's the error that I was getting. I also got one instance of http://www.friendpaste.com/7EpB1eJGRoRFBvjXvmFG3V on the Ubuntu. Never seen this one which makes things more fun. The first one comes up reliably after half a minute or so and repeats itself, it may well be a socket ulimit or something. The second one I only ever saw once so far. Cheers Jan -- Just distchecked 1.0.x and 1.1.x no problem. Give it a shot, Paul? the same, osx (with without ssd) - benoît
Re: Helping out with releases
1.0.3 is on my list for today On May 15, 2011, at 11:50 AM, till t...@php.net wrote: Just wanted to ask what the status of either release is? Are the two tests failing still failing, or can we move on to make dist? :-) Till On Thu, May 12, 2011 at 5:15 PM, Benoit Chesneau bchesn...@gmail.com wrote: On Thu, May 12, 2011 at 4:31 AM, Randall Leeds randall.le...@gmail.com wrote: On Tue, May 10, 2011 at 06:54, Paul Davis paul.joseph.da...@gmail.com wrote: On Tue, May 10, 2011 at 9:49 AM, Jan Lehnardt j...@apache.org wrote: Putting 140 on an infinite loop (while(true); do ./test/etap/run test/etap/140-attachment-comp.t ; done) eventually gives me http://www.friendpaste.com/2JCA8dvre9orA3UysYYTCe on both SSD Mac OS X 10.6 and Ubuntu 10.04 on disk in a VMWare. That's the error that I was getting. I also got one instance of http://www.friendpaste.com/7EpB1eJGRoRFBvjXvmFG3V on the Ubuntu. Never seen this one which makes things more fun. The first one comes up reliably after half a minute or so and repeats itself, it may well be a socket ulimit or something. The second one I only ever saw once so far. Cheers Jan -- Just distchecked 1.0.x and 1.1.x no problem. Give it a shot, Paul? the same, osx (with without ssd) - benoît
