On Wed, Sep 23 2015, Sean Dague wrote: > Ok, how exactly does that work? Because it seems like > oslo_middleware.ssl is only changing the protocol if the proxy sets it. > > But the host in the urls will still be the individual host, which isn't > the proxy hostname/ip. Sorry if I'm being daft here, just want to > understand how that flow ends up working.
No problem, you're no supposed to know everything. :)
As ZZelle said too, we can set the correct host and port expected by
honoring X-Forwarded-Host and X-Forwarded-Port, which are set by HTTP
proxies when they act as reverse-proxies and forward requests.
That will make the WSGI application unaware of the fact that there is a
request proxy in front of them. Magic!
We could do that in the SSL middleware (and maybe rename it?) or in
another middleware, and enable them by default. So we'd have that
working by default, which would be great IMHO.
> Will that cover the case of webob's request.application_uri? If so I
> think that covers the REST documents in at least Nova (one good data
> point, and one that I know has been copied around). At least as far as
> the protocol is concerned, it's still got a potential url issue.
That should work with any WSGI request, so I'd say yes.
>> The {public,admin}_endpoint are only useful in the case where you map
>> http://myproxy/identity -> http://mykeystone/ using a proxy
>>
>> Because the prefix is not passed to Keystone. If you map 1:1 the path
>> part, we could also leverage X-Forwarded-Host and X-Forwarded-Port to
>> avoid having {public,admin}_endpoint options.
>
> It also looks like there are new standards for Forwarded headers, so the
> middleware should probably support those as well.
> http://tools.ietf.org/html/rfc7239.
Good point, we should update the middleware as needed.
Though they still not cover that use case where you have a base URL that
is different between the proxy and the application. I don't think it's a
widely used case, but still, there are at 2 least two way to support it:
1. Having config option (like Keystone currently has)
2. Having a special e.g. X-Forwarded-BaseURL header set by the proxy
that we would catch in our middleware and would prepend to
environment['SCRIPT_NAME'].
The 2 options are even compatible, though I'd say 2. is probably simpler
in the long run and more… "unified".
I'm willing to clear that out and come with specs and patches if that
can help. :)
--
Julien Danjou
# Free Software hacker
# http://julien.danjou.info
signature.asc
Description: PGP signature
__________________________________________________________________________ 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
