Update to CORS specification.

Changes requested in discussion on the original CORS specification, however
deferred in favor of landing that specification. Commentary here:

https://review.openstack.org/#/c/179866/5/specs/cors-support.rst

Change-Id: I9e8be30834e7020320a1cd37c8f18e59da4b360b
This commit is contained in:
Michael Krotscheck 2015-06-09 13:33:46 -07:00
parent 884324c5c6
commit b79dbecdf5
1 changed files with 17 additions and 12 deletions

View File

@ -2,7 +2,7 @@
CORS Support
============
The W3C has released a Technical Recommendation (TR) via which an API may
The W3C has released a Technical Recommendation (TR) by which an API may
permit a user agent - usually a web browser - to selectively break the
`same-origin policy`_. This permits javascript running in the user agent to
access the API from domains, protocols, and ports that do not match the API
@ -54,11 +54,15 @@ Proposed change
All OpenStack API's should implement a common middleware that implements CORS
in a reusable, optional fashion. This middleware must be well documented,
with security concerns highlighted, in order to properly educate the operator
community on their choices.
community on their choices. The middleware must default to inactive, unless
it is activated either explicitly, or implicitly via a provided configuration.
`CORS Middleware`_ is available in oslo_middleware version 0.3.0. Additional
work would be required to add this middleware to the appropriate services,
and to add the necessary documentation to the docs repository.
`CORS Middleware`_ is available in oslo_middleware version 0.3.0. This
particular implementation defaults to inactive, unless appropriate configuration
options are detected in oslo_config, and its documentation already covers key
security concerns. Additional work would be required to add this middleware
to the appropriate services, and to add the necessary documentation to the
docs repository.
Note that improperly implemented CORS_ support is a security concern, and
this should be highlighted in the documentation.
@ -66,14 +70,15 @@ this should be highlighted in the documentation.
Alternatives
------------
One alternative is to provide a proxy, much like horizon's implementation, or
a well configured Apache mod_proxy. It would require additional documentation
One alternative is to provide a proxy, much like horizon's implementation,
or a well configured Apache mod_proxy. It would require additional documentation
that teaches UI development teams on how to implement and build on it. These
options are already available and well documented, however they do not truly
address the problem of services such as Ironic, which represents its resource
links in a strictly RESTful fashion. In that case, the proxy would have to read
every request and response, and replace all link references to Ironic with
references to itself.
options are already available and well documented, however they do not enable
experimentation or deployment of alternative UIs in the same way that CORS can,
since they require the UI to be hosted in the same endpoint. This requires
either close deployment cooperation, or deployment of a proxy-per-UI. CORS can
permit UIs to be deployed using static files, allowing much lower cost-of-entry
overheads.
Implementation
==============