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

[nivardus]

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!

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)
* 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?

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/

Thanks, ya'll
Bennett Goble // Nivardus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20120512/c3548ed6/attachment.htm>