2009/1/9 Nate Coraor <nate@bx.psu.edu>:
James Casbon wrote:
Not sure I understand - you mean that the base url is technically correct but the proxy introduces the error? What we need is the ability to set the base url for this kind of situation.
The URL scheme between Apache and Galaxy is http. Between Apache and the end user it can be anything (in your case, https). Galaxy only knows which scheme it's using with its immediate upstream.
I'll go ahead and commit my fix so that Galaxy generates the URL correctly. This should solve any future problems or integration with other external sources. But it won't fix UCSC, which I'll explain in a moment.
To generate proper 'https' URLs, inside the SSL VirtualHost in which you proxy Galaxy you'd need to add this:
RequestHeader set X-URL-SCHEME https
Galaxy will then check the X-URL-SCHEME header and override the previously defined scheme (http) accordingly.
I tried out this fix and it works - which is great for the UCSC table browser integration.
However, UCSC cannot read data over https[1], so fixing the URL will not actually help. However, you can serve UCSC data over http via a hackish workaround:
1. Don't set X-URL-SCHEME as described above. Galaxy will continue to generate (incorrect) 'http' links. 2. In the non-SSL VirtualHost for galaxy.example.com, set up a proxy similar to how you did in the SSL VirtualHost, but only for /root/display_as. You'll want to deny connections from everywhere but UCSC:
<VirtualHost *:80> ... standard stuff ... Order deny,allow Deny from all Allow from hgw1.cse.ucsc.edu Allow from hgw2.cse.ucsc.edu Allow from hgw3.cse.ucsc.edu Allow from hgw4.cse.ucsc.edu Allow from hgw5.cse.ucsc.edu Allow from hgw6.cse.ucsc.edu Allow from hgw7.cse.ucsc.edu Allow from hgw8.cse.ucsc.edu RewriteEngine on RewriteRule ^(/root/display_as.*) http://localhost:8192$1 [P,L] RewriteRule ^(.*) - [F] </VirtualHost>
Authentication configuration is not necessary since you are only allowing through UCSC, unauthenticated. Everything else in that VirtualHost will return 403 Forbidden.
[1] http://www.soe.ucsc.edu/pipermail/genome/2008-April/015997.html
I also tried this, which is also good. I can display custom tracks on the genome browser. I would like a way to have both the table and the custom track integration. I suppose the best way is to use https, and if it is a UCSC client redirect it to http. That is if the UCSC client will honor redirects? cheers, James