# Best pratice for using Galaxy External Display Applications (GEDAs) in a reverse proxy Galaxy installation **URL:** \ **Category:** Uncategorized\ **Tags:** devops-administration, galaxy-local\ **Created:** [May 3, 2020, 6:30pm UTC](https://help.galaxyproject.org/t/best-pratice-for-using-galaxy-external-display-applications-gedas-in-a-reverse-proxy-galaxy-installation/3564 "2020-05-03T18:30:20Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![schmitts](https://avatars.discourse-cdn.com/v4/letter/s/ecccb3/32.png) [@schmitts](https://help.galaxyproject.org/u/schmitts)\ **Post date:** [May 3, 2020, 6:30pm UTC](https://help.galaxyproject.org/t/best-pratice-for-using-galaxy-external-display-applications-gedas-in-a-reverse-proxy-galaxy-installation/3564/1 "2020-05-03T18:30:20Z")
Hi all, 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](http://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”: [https://docs.galaxyproject.org/en/latest/admin/apache.html#display-sites](https://docs.galaxyproject.org/en/latest/admin/apache.html#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: \ Satisfy Any Order deny,allow 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: 1. Galaxy is expecting a “REMOTE\_USER” Header in the request: when the user is clicking on “display at [bam.iobio.io](http://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). 2. 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. 3. 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](http://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!