Hi Davide, Sorry I haven't kept up with this thread. I'll try to add any information I can to help. Davide Cittaro wrote:
:-) Yes, it is (Besides, shoud I set to False any other field, such as allow_users_creation?)
These options won't really have an effect anyway, since user options are hidden when you enable use_remote_user.
I'm right now testing your suggestion (and the ones on galaxy wiki). I've seen that this rule
RequestHeader set REMOTE_USER %{RU}e
doesn't set actually the REMOTE_USER variable but the HTTP_REMOTE_USER, I've made this test:
RequestHeader set REMOTE_USER "foo"
and I have these two values:
HTTP_REMOTE_USER = "foo" REMOTE_USER = davide.cittaro@ifom-ieo-campus.it <mailto:davide.cittaro@ifom-ieo-campus.it>
I wonder if galaxy is somehow reading from HTTP_REMOTE_USER which is set to (null) if no RequestHeader is specified... I'm now going to test this
This is what it does - because Galaxy is a proxied application and does not run in Apache's environment, the only way to pass REMOTE_USER upstream is as a header. In detail: RewriteCond %{LA-U:REMOTE_USER} (.+) - Match the REMOTE_USER server variable and store it in a regex backref. RewriteRule . - [E=RU:%1] - Store the previously matched backref in the RU env variable. RequestHeader set REMOTE_USER %{RU}e - Set the REMOTE_USER header in the proxied request to the value of RU. The application sees it as HTTP_REMOTE_USER since all of the HTTP headers are stored in the wsgi environment with HTTP_ prepended. --nate