I was wondering if there is a “good” way of how to use Galaxy External Display Applications (GEDAs) in a local Galaxy installation that sits behind a reverse proxy (in my case a Apache, but the fundamental question is also valid for other RP) that uses basic authentication.
The issue is that those GEDAs (I use bam.iobio.io as reference) need to have access to files within Galaxy - but of course cannot as there is a basic auth in place at the Galaxy RP. Whenever the GEDA tries to access those files - it will be asked to log-in - and therefore cannot download the data to display.
In the documentation the issue is covered for a (maybe older?) scenario using “Display Sites”:
Here the author suggests to define a new location in the apache conf that does not require auth (and therefore bypasses the basic auth set for the “/” location:
Deny from all
Allow from …
I used this as a template and set this to “/display_application” for location.
While this sounds like a good idea - it fails because of several issues:
- Galaxy is expecting a “REMOTE_USER” Header in the request: when the user is clicking on “display at bam.iobio.io” the request is blocked because of the missing “REMOTE_USER” header (the link of course has to first go to Galaxy in order to provide the final GEDA link).
- Somewhere on the internet I found the recommendation to just add a “random” REMOTE_USER only for that location. This sounds good and actually allows the GEDA to download the data - but still fails as in the script “lib/galaxy/web/framework\webapp.py” there is a check in place that validates if the user provided via REMOTE_USER is fitting to the Galaxysession User. If not, the session is invalidated. Therefore, whenever the user clicks on “display at” for a GEDA - he can display the data but then gets kicked-out from the session.
- I found an option in the “Galaxy.yml” config file “display_servers” (not sure wether this is for GEDAs or again something older) that looks promising as it can be used to bypass the need for the REMOTE_USER (Problem listed under 1) - but this still does not help as (I) a first click on “display at” does send a request form the current browser of the user (i.e. not from one of the listed servers") which still generates a 403 as no REMOTE_USER is provided and (II) the accessing servers might not be known (bam.iobio.io comes download requests come from AWS) ( this is of course a general problem).
As a work-around now inactivated the check in the “webapp.py”, set a “/display_application” location without login needed in the apache conf and provided a random REMOTE_USER in that location.
This works - but I am not 100% happy with it as (I) it inactivates a useful check (II) it provides a hard-coded user in the apache config and (III) does not give any control on the access to “/display_application”.
Did some of you think about a solution for this issue?
Many thanks in advance for any advice or thoughts on this!