Bug 1390412

Summary:	creating a group fails with "HTTP request aborted" (CORS denial) when Beaker is behind an SSL-terminating reverse proxy
Product:	[Retired] Beaker	Reporter:	Dan Callaghan <dcallagh>
Component:	general	Assignee:	Dan Callaghan <dcallagh>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Dan Callaghan <dcallagh>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	23	CC:	dcallagh, mjia, rjoost
Target Milestone:	23.3	Keywords:	Patch
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-11-07 06:44:37 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Dan Callaghan 2016-11-01 02:22:42 UTC

Version-Release number of selected component (if applicable):
23.2

How reproducible:
not easily unless your Beaker is behind an SSL-terminating reverse proxy (such as beaker.qa.fedora.project.org)

Steps to Reproduce:
1. Go to the groups grid (/groups/)
2. Try to create a new group
(Note: do not try these steps on beaker.qa.fedoraproject.org because if it succeeds, it will leave a mess and nobody wants that)

Actual results:
UI shows an error "HTTP request aborted".
Browser console shows the real error (note http scheme but it should be https):
Blocked loading mixed active content "http://beaker.qa.fedoraproject.org/groups/"

Expected results:
AJAX request should be sent to https://beaker.qa.fedoraproject.org/groups/ and then succeed without errors.

Additional info:
The /groups/ page is using flask.request.base_url to make Flask compute the requested URL, but Flask isn't aware that it's actually being accessed over https:// due to the SSL-terminating proxy.

In very recent versions of mod_wsgi there is an option to make it trust the X-Forwarded-Proto header (and others):

https://modwsgi.readthedocs.io/en/develop/release-notes/version-4.4.9.html#new-features

which would presumably result in Flask being able to determine the real requested URL correctly. But RHEL7 is still on mod_wsgi 3.4.

Regardless, we have already defined configuration settings tg.url_domain and tg.url_scheme for building absolute URLs so we need to just obey those in all cases.

The groups grid is not the only piece of code which has this problem, we will need to audit for any usages of flask.request that rely on Flask to produce an absolute URL and ensure that we remove those in favour of either using relative URLs whenever possible, or else using bkr.server.util.absolute_url() which obeys the configuration directives we have for this.

Comment 1 Dan Callaghan 2016-11-01 02:30:14 UTC

As a workaround, it is possible to manually correct the URL on the Backbone collection prior to making any AJAX requests, so that they will go to the right place and not trigger CORS denials.

In the case of the groups grid on Fedora Beaker, use the browser dev console to run:

    collection.url = 'https://beaker.qa.fedoraproject.org/groups/'

Similarly for other pages (adjust the URL as needed).

Comment 2 Dan Callaghan 2016-11-02 07:47:07 UTC

So there are only two situations I can see where we are using any of the Flask request attributes which produce an absolute URL, namely request.base_url, request.url, or request.url_root:

http://flask.pocoo.org/docs/0.11/api/#flask.Request.path

It's used in json_collection() for the "forced pagination" redirect functionality. In that case we can build the redirect URL using request.path and then pass it to our absolute_url() utility function.

The other case is in all the Backgrid pages where it's passed down to the template to set the collection URL (that includes the groups grid which is the original page this bug report was about). In those cases we can just use a relative URL instead.

http://gerrit.beaker-project.org/5393

Unfortunately I don't think we can cover this specific situation (SSL-terminating reverse proxy) in our automated tests, but we can at least be confident that this doesn't break anything for the simpler case we have (with no reverse proxies).

Comment 5 Dan Callaghan 2016-11-07 06:44:37 UTC

Beaker 23.3 has been released.