LP#1002028: Cross Origin Resource Sharing for OpenSRF

LP#1002028: Cross Origin Resource Sharing for OpenSRF

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. CORS makes it simple to use
OpenSRF's HTTP translator and gateway APIs on websites using separate
domains.

Example Scenarios
-----------------
1) A library would like an AJAX-driven "quicksearch" box on their main
site, which is hosted on a different domain than their catalog.
2) A developer wants to create new web applications and services that
tie into Evergreen, but does not wish to install EG locally or
configure a proxy.

Implementation
--------------
The function crossOriginHeaders() has been added to apachetools.c.
Incoming requests are checked to see if they have an Origin header. The
value of the Origin header is checked against a whitelist defined in
opensrf_core.xml config (XPath: /config/gateway/cross_origin/origin).
The function returns 1 if CORS headers have been added to the response.

Notes
-----
* The OpenSRF Javascript client library (opensrf.js) defaults to the root
of the current web host "/osrf-http-translator." In addition, synchronous
requests are presumed in some situations: resulting in the oncomplete
method never returning (Blocking requests are not possible with cross-
domain XHR.)
* It is also possible to enable CORS with the Apache "set header"
configuration directive. However, this means that the necessary headers
would be appended to every response.

Links
-----
Specification - http://www.w3.org/TR/cors/
Wikipedia Article - http://en.wikipedia.org/wiki/Cross-origin_resource_sharing

Signed-off-by: Bennett Goble <nivardus@gmail.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>