This specification details how CORS is implemented and supported across OpenStack’s services.
The default ports for most openstack services (excluding horizon) are not the ports commonly used by user agents to access websites (80, 443). As such, even if the services were hosted on the same domain and protocol, it would be impossible for any user agent’s application to access these services directly, as any request would violate the above policy.
This specification does not presume to require an additional configuration step for operators for a ‘default’ install of OpenStack and its user interface. Horizon currently maintains, and shall continue to maintain, its own installation requirements.
This specification does not presume to set front-end application design standards- rather it exists to expand the options that front-end teams have, and allow them to make whatever choice makes the most sense for them.
This specification does provide a method by which teams, whether upstream or downstream, can choose to implement additional user interfaces of their own. An example use case may be Ironic, which may wish to ship an interface that can live independently of horizon, for such users who do not want to install additional components.
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. 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. 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.
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 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.
This work is licensed under a Creative Commons Attribution 3.0 Unported License. http://creativecommons.org/licenses/by/3.0/legalcode