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
