Adam, CORS shouldn't need catalog integration ever. CORS is a layer above anything in the service catalog and doesn't provide extra security except signalling to the javascript vm it can access resources outside of it's current domain; something that can be worked around in many ways including using a non-javascript http client. The underlying application can still reject the request.
I don't see service catalog integration as a blocker for CORS. On Thu, Feb 18, 2016 at 10:29 AM, John Garbutt <j...@johngarbutt.com> wrote: > On 18 February 2016 at 17:58, Sean Dague <s...@dague.net> wrote: > > On 02/18/2016 12:17 PM, Michael Krotscheck wrote: > >> Clarifying: > >> > >> On Thu, Feb 18, 2016 at 2:32 AM Sean Dague <s...@dague.net > >> <mailto:s...@dague.net>> wrote: > >> > >> Ok, to make sure we all ended up on the same page at the end of this > >> discussion, this is what I think I heard. > >> > >> 1) oslo.config is about to release with a feature that will make > adding > >> config to paste.ini not needed (i.e. > >> https://review.openstack.org/#/c/265415/ is no longer needed). > >> > >> > >> I will need help to do this. More below. > >> > >> > >> 2) ideally the cors middleware will have sane defaults for that set > of > >> headers in oslo.config. > >> > >> > >> I'd like to make sure we agree on what "Sane defaults" means here. By > >> design, the CORS middleware is generic, and only explicitly includes the > >> headers prescribed in the w3c spec. It should not include any > >> additional headers, for reasons of downstream non-openstack consumers. > >> > >> > >> 3) projects should be able to apply new defaults for these options > in > >> their codebase through a default override process (that is now > nicely > >> documented somewhere... url?) > >> > >> > >> New sample defaults for the generated configuration files, they should > >> not live anywhere else. The CORS middleware should, if we go this path, > >> be little more than a true-to-spec implementation, with config files > >> that extend it for the appropriate API. > >> > >> The big question I now have is: What do we do with respect to the mitaka > >> freeze? > >> > >> Option 1: Implement as is, keep things consistent, fix them in Newton. > > > > The problem with Option 1 is that it's not fixable in Newton. It > > requires fixing for the next 3 releases as you have to deprecate out > > bits in paste.ini, make middleware warn for removal first soft, then > > hard, explain the config migration. Once this lands in the wild the > > unwind is very long and involved. > > > > Which is why I -1ed the patch. Because the fix in newton isn't a revert. > > +1 on the upgrade impact being a blocker. > Certainly for all folks meeting these: > > https://governance.openstack.org/reference/tags/assert_supports-upgrade.html#requirements > > This will require lots of folks to pitch in a help, and bend the > process a touch. > But that seems way more reasonable than dragging our users through > that headache. > > Thanks, > John > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
