On Sat, May 12, 2012 at 10:38:32PM -0400, nivardus wrote: > Summary: > I've written a small function that appends the correct headers and used it > to enable CORS on the OSRF-HTTP-Translator. This could be useful if a > library wants to put web applications and functionality that interacts with > Evergreen on a separate domain. I'd appreciate any suggestions/feedback!
This sounds good. I'd love to see a simple but realistic scenario outlined in the commit message, if at all possible; it will help people understand why they want this even more. > Cross-Site Background: > Browsers' same-origin policy currently restricts requests to the current > website's domain to prevent various nefarious scenarios. However, because > APIs and other web resources need to remain open to cross-site use Cross > Origin Resource Sharing (CORS) was created to allow services to formally > authorize cross-origin requests. > > Questions: > * Configuration: Is the current allowed origin location appropriate? > (opensrf_core.xml, xpath: /config/gateway/cross_origin) Location seems okay, but I wonder whether the example opensrf_core.xml.example should contain '*' as a default. Maybe include that as a commented-out option with a comment? > * Gateway support: CORS is only implemented on the http-translator, given > that the translator is The Future is there any reason to implement it on > the gateway? It seems that the gateway will continue to have a long life, so perhaps. > Other Notes: > * OpenSRF X-Headers are available as defines in osrf_http_gateway.c, in > order to avoid a circular import I had to define a long string of all the > headers in apachetools.h for use when setting Access-Control-Allow-Headers > * Access-Control-Max-Age is currently set to 6 hours, but I see no reason > why it couldn't be much longer. > * Were it desirable the allowed-origin matching (currently just equality) > could be fleshed out into something with pattern matching. > * OpenSRF's Javascript client library currently defaults to the root of the > current web host. > * Using the wildcard "*" in the config whitelists all origins. > > Github diff: > https://github.com/nivardus/OpenSRF/commit/3df3807e9cf69c60e5282717e97cadf429a39555 > CORS Spec: http://www.w3.org/TR/cors/ Two or three things here, but only #1 is necessary: 1) Per the code section of "Contributing" (http://evergreen-ils.org/dokuwiki/doku.php?id=contributing), we absolutely want to have a sign-off from you indicating that you have read and are asserting a Developer's Certificate of Origin. 2) For a pull request, something like "Please pull from git://github.com/nivardus/OpenSRF.git master" (to give the git repo location and branch) would make our lives a little easier, although not necessary. (Aside: you might not want to commit your own changes to the master branch of your repo; generally you want to keep your changes in separate branches. I've learned this the hard way!) 3) We would welcome you to submit your SSH pubkey to gitad...@evergreen-ils.org so that you can commit directly to the Evergreen "working" repo, which most of the current developers keep under our fingertips (slowly, we will indoctrinate you in our ways and pull you into our circle!). See http://evergreen-ils.org/dokuwiki/doku.php?id=dev:git for more info on our workflows, etc. Thanks so much for this!