On 02/18/2016 02:00 PM, Morgan Fainberg wrote:
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.
OK, so Catalog is a vestige of the old discussion. Look instead at what
we do with Federations Trusted Dashboard.
http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/config.py#n532
That is really what I was getting at:
Its not a question of the remote application rejecting the token. It is
Keystone refusing to tell the browser that the remote application is
allowed to read the token.
If the deployer does and all-in-one, and all services are on port 443,
CORS is not an issue.
If Each Service has its own port or hostname, then each service needs to
know the list of approved dashboards. Since we do this in Keystone
already, recommend we have the CORS middleware use the same property.
CONF.federation.trusted_dashboard
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
<mailto:j...@johngarbutt.com>> wrote:
On 18 February 2016 at 17:58, Sean Dague <s...@dague.net
<mailto: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>
>> <mailto: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://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
__________________________________________________________________________
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
