Attempting to bypass external authentication for API results in Exception: HTTP_REMOTE_USER not provided

[lparsons]

We use Apache and mod_auth_cas for external authentication. When setting up the API bypass we experience exceptions in the main interface when requesting histories.

File '/galaxy/galaxy-app/lib/galaxy/web/framework/webapp.py', line 432 in _ensure_valid_session
  "use_remote_user is set but %s header was not provided" % self.app.config.remote_user_header
AssertionError: use_remote_user is set but HTTP_REMOTE_USER header was not provided

Gist of full stack trace

[lparsons]

@dannon, I know you worked on something related to this in the past. Am I missing something?

[lparsons]

Possibly related: #972

[hexylena]

@lparsons I use mod_auth_cas too!

Which version of galaxy are you on? Might also be affected by #1003

[lparsons]

@erasche I'm using release_16.07 right now, though I'm considering moving to bleeding edge release_16.10 due to conda issues.

Do you have a way to use the API at the moment (i.e. setting up a bypass)?

[hexylena]

Huh, odd. I'm on release_16.07 as well. My apache conf looks like:

    <Location "/galaxy/api/">
        Satisfy Any 
        Allow from all
    </Location>

    <Location "/galaxy">
        AuthName "CAS"
        AuthType CAS
        Require valid-user
        RequestHeader set X-URL-SCHEME https
        XSendFile on
        XSendFilePath /
        RequestHeader set CAS-User "%{REMOTE_USER}s@tamu.edu"
    </Location>
    ProxyPass /galaxy uwsgi://127.0.0.1:4001/

[lparsons]

From IRC discussion with @dannon:

This issue comes up only when there is no API and the remote_user_header is not set at all during an API request. If the remote_user_header is set, but blank, everything works, since Galaxy falls back to the users existing web session.

The assertion at line 431 of webapp.py causes the problem. This assertion does not appear to be necessary and should very likely be removed (or at least changed to a log.debug message).

[dannon]

@lparsons Thanks for documenting this! I started refactoring that, and there's a bit more we need to handle beyond removing it, but hopefully I'll be able to get something in soon.

[dannon]

@lparsons Forgot to update this issue, but can you verify this is resolved with the refactoring from #3976?

[lparsons]

@dannon Sorry, I don't have a way to really test this beyond my production system, where I've already implemented the workaround of making sure the remote_user_header is set, but blank.

[dannon]

Ok, no worries. I'm pretty sure this resolves the issue you were seeing, feel free to reopen this if you do see it again.