[OPEN-ILS-DEV] ***SPAM*** OpenSRF Gateway/Translator Cross Origin Support

[Dan Scott]

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
   gitadmin at 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!