Open Stack

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 <john at johngarbutt.com> wrote:

> On 18 February 2016 at 17:58, Sean Dague <sean at 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 <sean at dague.net
> >> <mailto:sean at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160218/ef2b0d09/attachment.html>