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