Maintenance. Planio will be undergoing a scheduled maintenance this weekend. Between Saturday, July 24 at 9:00 UTC and Sunday, July 25, 22:00 UTC your account might observe occasional downtimes which may last up to several minutes in some cases.
auth token used in registry requests are not validated properly when behind an SSL proxy
When the content app is running over HTTP deployed behind a reverse proxy running on HTTPS, the content app does not properly detect the url that the request is coming in as and fails to validate the provided auth token.
As an example, my CONTENT_ORIGIN is set to "https://hostname.example.com", a fetch to the api, would generate an auth token based on this URL:
however, when the request is redirected to that URL, and proxied back to the content app, the content app tries to get the URL that is coming in and gets a url that looks like:
It seems to think that the request is coming in over 'http' since the content app is running over http. In addition, it seems to be ignoring the port #, so if CONTENT_ORIGIN was configured to a non-standard port, comparison would also fail (although this is not a concern for us at this time).
I think it makes sense to just create and validate the token based off the request path, and ignore hostname, protocol, and port
Some relevant links showing why/where this is a problem: https://docs.aiohttp.org/en/stable/web_advanced.html#deploying-behind-a-proxy https://github.com/aio-libs/aiohttp/blob/72b5344af59ccdefc1e9a9e489c222a2b2592c7d/aiohttp/web_request.py#L384-L386 https://github.com/pulp/pulp_container/blob/789979a8706c527e4c9e8d04d084b262ea78208f/pulp_container/app/models.py#L442
A common way with reverse proxy setups is https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Proto. Looks like Django has docs on this and https://docs.djangoproject.com/en/2.2/ref/settings/#secure-proxy-ssl-header suggests to use this setting:
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
[...] I think it makes sense to just create and validate the token based off the request path, and ignore hostname, protocol, and port [...]
I agree. This would be compatible with whatever strange url rewrite rules a user might apply on his reverse proxy (well almost, but we need to assume something for the hash).
Please register to edit this issue