[
https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13494987#comment-13494987
]
Jan Lehnardt commented on COUCHDB-431:
--------------------------------------
http://www.w3.org/TR/cors/#security
> Care must always be taken by applications when making cross-origin requests
> with user credentials, and servers processing such requests must take care in
> the use of credentials, including the Origin header.
> When requests have significance other than retrieval, and when relying on the
> Origin header as a credential, servers must be careful to distinguish between
> authorizing a request and authorizing access to the representation of that
> resource in the response.
> Authorization for a request should be performed using only the intersection
> of the authority of the user and the requesting origin(s). In the case of
> redirects, more than one value for Origin may be present and all must be
> authorized.
> Servers using the Origin header to authorize requests are encouraged to also
> verify that the Host header matches its expected value to prevent forwarding
> attacks. Consider two sites, corp.example and corp.invalid. A web application
> at corp.example makes a cross-origin request to corp.invalid, and the user
> agent sends the Origin header corp.example. If corp.invalid or the network is
> malicious, it may cause the request to be delivered to corp.example, with the
> result that corp.example would receive a requst that appears to originate
> from itself. Verifying the Host header would reveal that the user agent
> intended the request for corp.invalid and it can be discarded. Even better
> would be to exclusively use secure connections for cross-origin requests to
> enable user agents to detect such misdirections.
> It is often appropriate for servers to require an authorization ceremony
> asking a user to consent that cross-origin requests with credentials be
> honored from a given origin. In such cases, passing security tokens
> explicitly as part of the cross-origin request can remove any ambiguity as to
> the scope of authorization. OAuth is an example of this pattern. [OAUTH]
Maybe this doesn’t apply to us, I just want to make sure.
* * *
> - if one forgot the http header then the origin won't be matched. The Origin
> *must* follow the uri spec which contains the scheme
That’s good. I’m thinking about users here though, we might want to log
warnings when they forget to configure the scheme and then stuff doesn’t work.
I just see myself trying to set this up next year :)
> - imo OPTIONS works everywhere and the xhr clienst won't be able to override
> if most of the time
Agreed, Nevermind.
> - I will add some doc. Though which versions of erlang are we supposed to
> support for specs and co?
I would say that just regular comments will suffice for now. We can always turn
them into whatever is available in later erlang versions for auto-doc
generation. If we already require a sufficient minor version, then go with
whatever is there :)
> cors - aka Cross-Origin Resource Sharing support
> -------------------------------------------------
>
> 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,
> check_method_cors.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
For more information on JIRA, see: http://www.atlassian.com/software/jira
