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:
parent
884324c5c6
commit
b79dbecdf5
|
@ -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
|
||||
==============
|
||||
|
|
Loading…
Reference in New Issue