Proxy reconfiguration to show the Tripal site rather than Galaxy as the landing page

[RichardBruskiewich]

The way the NGINX proxy of this project is configured, the "landing" page of the URL is the Galaxy instance, and the Tripal site is on the path "/tripal". Although the Proxy NGINX default.conf can be superficial reconfigured to show Tripal as the landing page, putting Galaxy at the end of the path "/galaxy" breaks Galaxy and Apollo. It would be good to know how to make this swap work.

Another mildly related issue is how to best secure the /galaxy and /apollo (and possibly other) system paths as accessible only to users with specific designated "roles" such as "administrator" and "curator". This is a more restricted model of access than the system currently supports, I think.

[hexylena]

So this should be changeable:

• you'll need to change it in galaxy
• and apollo will need to become /galaxy/apollo in the nginx conf
• and update galaxy's references to it

[hexylena]

system paths as accessible only to users with specific designated "roles" such as "administrator" and "curator".

Can you elaborate more on this point? I'm not quite sure what you mean re: securing system paths.

[RichardBruskiewich]

Hello again. I'll take a closer look at the mutability of the proxy paths as you have suggested.

On the issue of user roles, I guess what I'm thinking is that our particular deployment is likely to have several distinct classes of users: plant breeders (running breeding specific workflows); the data curators (putting new crop genomic information into the system, with quality control; plant breeders won't likely put such information in themselves); and, perhaps, administrators of the system. I guess I'm not so concerned about the last category of users, in that every component - Galaxy, Apollo(?) and Tripal - have "admin" user modes built in. Rather, the main issue is likely to only allow qualified data curators to prepare genomic data for uploading to the system, mainly for use by plant breeders in their marker or genomic selection based breeding workflows. Anyhow, we can ponder this further over the coming couple of months.

[hexylena]

• plant breeders run workflows
• data curators add datasets to apollo

This should already be more or less supported. The data curators can add the datasets + share with the users using the features already there for that. And by sharing with plant breeders they can run workflows and update the records in apollo. If the breeders should not be permitted to add new tracks to the genome, just make sure you only grant them read access.

[RichardBruskiewich]

thanks. The system has great flexibility so I'm sure we'll sort something out here.

[abretaud]

For redirection, this is how I configure nginx to have tripal at /, galaxy at /galaxy and apollo at /apollo

        location / {
            proxy_redirect   http://tripal/tripal/      http://$http_host/tripal/;
            proxy_pass       http://tripal/tripal/;
        }

        location /galaxy {
            proxy_redirect   http://galaxy       http://$host;
            proxy_pass http://galaxy/;
            proxy_cookie_path ~*^/([^/]*) /galaxy/$1;
            proxy_set_header REMOTE_USER $remote_user;
        }

        location /apollo/ {
            proxy_set_header REMOTE_USER $remote_user@bipaa;

            # WebSocket stuff
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;

            proxy_redirect   /      http://$http_host/apollo/;
            proxy_redirect   http://apollo:8080/      http://$http_host/apollo/;
            proxy_pass       http://apollo:8080/;
            proxy_cookie_path ~*^/([^/]*) /apollo/$1;
        }

Not sure if proxy_cookie_path is needed for you, maybe I added it because the real urls are more like https://bipaa.genouest.org/sp/some_organism/galaxy for us.

And in the docker-compose.yml:

    tripal:
        image: quay.io/galaxy-genome-annotation/tripal
        environment:
            BASE_URL_PATH: /sp/some_organism

    galaxy:
        image: quay.io/galaxy-genome-annotation/docker-galaxy-annotation:gmod
        environment:
            PROXY_PREFIX: /sp/some_organism/galaxy
            GALAXY_CONFIG_COOKIE_PATH: /galaxy
            GALAXY_WEBAPOLLO_EXT_URL: /sp/some_organism/apollo
            GALAXY_CHADO_DBHOST: chado

    apollo:
        image: quay.io/abretaud/apollo:bipaa
        environment:
            APOLLO_PATH_PREFIX: "/sp/some_organism/apollo/"

For the permissions problem, I have nothing to add because my setup is simpler = we only have admins and annotators. We authenticate with an ldap, and restrict access to galaxy to admins (who load organisms into apollo).

[RichardBruskiewich]

Thanks @abretaud I'm going to try to apply the kinds of settings as you note above, to swap Galaxy and Tripal paths.

I notice that the Docker images you are using are not the same ones as in the standard docker-compose.yml file:

   quay.io/galaxy-genome-annotation/docker-galaxy-annotation:gmod

versus

   quay.io/galaxy-genome-annotation/docker-galaxy-annotation:master

and

     quay.io/abretaud/apollo:bipaa 

versus

    quay.io/erasche/apollo:remote_user

What are the differences?

Your comment about the _proxy_cookiepath might actually be kind of useful for the issue we've encountered of getting the Galaxy / Apollo gx-cookie-proxy remote user proxy working for us, since our "real" base URL's will also be something like https://sunflower.divseekcanada.ca, not simply localhost, and those URL's are actually proxied through a second NGINX proxy on another "gateway" server.

I'll probably ask more questions later about your user authentication / authorisation setup, in case it sheds more light on how we should configure out system here.