Error with local toolshed and remote user authentication: "HTTPError: HTTP Error 401: Authorization Required"
Hi, I would like to use Apache LDAP to authenticate a local toolshed. Configuring community_wsgi.ini wasn't a problem and I can now login into the local toolshed with my institution active directory credentials. The same way I do for the local Galaxy. I did have to add remote_user_maildomain as it wasn't there and I needed it. Maybe this is something that could be added in the next release. The problem is when I try to install a tool from this toolshed I get: URL: http://galaxy-bfx.brel.local/admin_toolshed/prepare_for_install?tool_shed_url=http://toolshed-bfx.brel.local/&repository_ids=ee9b707789bf4714&changeset_revisions=3cc82d4e406c File '/local/opt/galaxy/galaxy-dist/eggs/WebError-0.8a-py2.6.egg/weberror/evalexception/middleware.py', line 364 in respond app_iter = self.application(environ, detect_start_response) File '/local/opt/galaxy/galaxy-dist/eggs/Paste-1.6-py2.6.egg/paste/debug/prints.py', line 98 in __call__ environ, self.app) File '/local/opt/galaxy/galaxy-dist/eggs/Paste-1.6-py2.6.egg/paste/wsgilib.py', line 539 in intercept_output app_iter = application(environ, replacement_start_response) File '/local/opt/galaxy/galaxy-dist/eggs/Paste-1.6-py2.6.egg/paste/recursive.py', line 80 in __call__ return self.application(environ, start_response) File '/local/opt/galaxy/galaxy-dist/lib/galaxy/web/framework/middleware/remoteuser.py', line 91 in __call__ return self.app( environ, start_response ) File '/local/opt/galaxy/galaxy-dist/eggs/Paste-1.6-py2.6.egg/paste/httpexceptions.py', line 632 in __call__ return self.application(environ, start_response) File '/local/opt/galaxy/galaxy-dist/lib/galaxy/web/framework/base.py', line 160 in __call__ body = method( trans, **kwargs ) File '/local/opt/galaxy/galaxy-dist/lib/galaxy/web/framework/__init__.py', line 208 in decorator return func( self, trans, *args, **kwargs ) File '/local/opt/galaxy/galaxy-dist/lib/galaxy/webapps/galaxy/controllers/admin_toolshed.py', line 1177 in prepare_for_install response = urllib2.urlopen( url ) File '/usr/lib64/python2.6/urllib2.py', line 126 in urlopen return _opener.open(url, data, timeout) File '/usr/lib64/python2.6/urllib2.py', line 397 in open response = meth(req, response) File '/usr/lib64/python2.6/urllib2.py', line 510 in http_response 'http', request, response, code, msg, hdrs) File '/usr/lib64/python2.6/urllib2.py', line 435 in error return self._call_chain(*args) File '/usr/lib64/python2.6/urllib2.py', line 369 in _call_chain result = func(*args) File '/usr/lib64/python2.6/urllib2.py', line 518 in http_error_default raise HTTPError(req.get_full_url(), code, msg, hdrs, fp) HTTPError: HTTP Error 401: Authorization Required Is there any trick I could do with Apache to let this go through? This is my current Apache configuration: <VirtualHost *:80> ServerAdmin carlos.borroto@gmail.com ServerName toolshed-bfx.brel.local:80 <Proxy http://localhost:9009> Order deny,allow Allow from all </Proxy> RewriteEngine on <Location "/"> AuthName "Galaxy Toolshed BFX" AuthType Basic AuthBasicAuthoritative off AuthBasicProvider ldap AuthzLDAPAuthoritative off AuthLDAPURL "ldap://ad.brel.local/OU=BREL,DC=brel,DC=local?sAMAccountName?sub" AuthLDAPBindDN "MASKED" AuthLDAPBindPassword "MASKED" Require valid-user # Set the REMOTE_USER header to the contents of the LDAP query response's "uid" attribute RequestHeader set REMOTE_USER %{AUTHENTICATE_sAMAccountName}e XSendFile on XSendFilePath / </Location> RewriteRule ^/static/style/(.*) /local/opt/galaxy/galaxy-dist/static/june_2007_style/blue/$1 [L] RewriteRule ^/static/scripts/(.*) /local/opt/galaxy/galaxy-dist/static/scripts/packed/$1 [L] RewriteRule ^/static/(.*) /local/opt/galaxy/galaxy-dist/static/$1 [L] RewriteRule ^/favicon.ico /local/opt/galaxy/galaxy-dist/static/favicon.ico [L] RewriteRule ^/robots.txt /local/opt/galaxy/galaxy-dist/static/robots.txt [L] RewriteRule ^(.*) http://localhost:9009$1 [P] ErrorLog logs/toolshed-bfx.brel.local-error_log CustomLog logs/toolshed-bfx.brel.local-access_log common </VirtualHost> As always any help will be highly appreciated, Thanks, Carlos
On Feb 5, 2013, at 4:29 PM, Carlos Borroto wrote:
Hi,
I would like to use Apache LDAP to authenticate a local toolshed. Configuring community_wsgi.ini wasn't a problem and I can now login into the local toolshed with my institution active directory credentials. The same way I do for the local Galaxy. I did have to add remote_user_maildomain as it wasn't there and I needed it. Maybe this is something that could be added in the next release.
The problem is when I try to install a tool from this toolshed I get:
URL: http://galaxy-bfx.brel.local/admin_toolshed/prepare_for_install?tool_shed_url=http://toolshed-bfx.brel.local/&repository_ids=ee9b707789bf4714&changeset_revisions=3cc82d4e406c File '/local/opt/galaxy/galaxy-dist/eggs/WebError-0.8a-py2.6.egg/weberror/evalexception/middleware.py', line 364 in respond app_iter = self.application(environ, detect_start_response) File '/local/opt/galaxy/galaxy-dist/eggs/Paste-1.6-py2.6.egg/paste/debug/prints.py', line 98 in __call__ environ, self.app) File '/local/opt/galaxy/galaxy-dist/eggs/Paste-1.6-py2.6.egg/paste/wsgilib.py', line 539 in intercept_output app_iter = application(environ, replacement_start_response) File '/local/opt/galaxy/galaxy-dist/eggs/Paste-1.6-py2.6.egg/paste/recursive.py', line 80 in __call__ return self.application(environ, start_response) File '/local/opt/galaxy/galaxy-dist/lib/galaxy/web/framework/middleware/remoteuser.py', line 91 in __call__ return self.app( environ, start_response ) File '/local/opt/galaxy/galaxy-dist/eggs/Paste-1.6-py2.6.egg/paste/httpexceptions.py', line 632 in __call__ return self.application(environ, start_response) File '/local/opt/galaxy/galaxy-dist/lib/galaxy/web/framework/base.py', line 160 in __call__ body = method( trans, **kwargs ) File '/local/opt/galaxy/galaxy-dist/lib/galaxy/web/framework/__init__.py', line 208 in decorator return func( self, trans, *args, **kwargs ) File '/local/opt/galaxy/galaxy-dist/lib/galaxy/webapps/galaxy/controllers/admin_toolshed.py', line 1177 in prepare_for_install response = urllib2.urlopen( url ) File '/usr/lib64/python2.6/urllib2.py', line 126 in urlopen return _opener.open(url, data, timeout) File '/usr/lib64/python2.6/urllib2.py', line 397 in open response = meth(req, response) File '/usr/lib64/python2.6/urllib2.py', line 510 in http_response 'http', request, response, code, msg, hdrs) File '/usr/lib64/python2.6/urllib2.py', line 435 in error return self._call_chain(*args) File '/usr/lib64/python2.6/urllib2.py', line 369 in _call_chain result = func(*args) File '/usr/lib64/python2.6/urllib2.py', line 518 in http_error_default raise HTTPError(req.get_full_url(), code, msg, hdrs, fp) HTTPError: HTTP Error 401: Authorization Required
Is there any trick I could do with Apache to let this go through?
This is my current Apache configuration:
<VirtualHost *:80> ServerAdmin carlos.borroto@gmail.com ServerName toolshed-bfx.brel.local:80
<Proxy http://localhost:9009> Order deny,allow Allow from all </Proxy> RewriteEngine on <Location "/"> AuthName "Galaxy Toolshed BFX" AuthType Basic AuthBasicAuthoritative off AuthBasicProvider ldap AuthzLDAPAuthoritative off AuthLDAPURL "ldap://ad.brel.local/OU=BREL,DC=brel,DC=local?sAMAccountName?sub" AuthLDAPBindDN "MASKED" AuthLDAPBindPassword "MASKED"
Hi Carlos, You'll need something here like: Satisfy Any Order deny,allow Deny from all Allow from your.galaxy.server --nate
Require valid-user # Set the REMOTE_USER header to the contents of the LDAP query response's "uid" attribute RequestHeader set REMOTE_USER %{AUTHENTICATE_sAMAccountName}e
XSendFile on XSendFilePath / </Location> RewriteRule ^/static/style/(.*) /local/opt/galaxy/galaxy-dist/static/june_2007_style/blue/$1 [L] RewriteRule ^/static/scripts/(.*) /local/opt/galaxy/galaxy-dist/static/scripts/packed/$1 [L] RewriteRule ^/static/(.*) /local/opt/galaxy/galaxy-dist/static/$1 [L] RewriteRule ^/favicon.ico /local/opt/galaxy/galaxy-dist/static/favicon.ico [L] RewriteRule ^/robots.txt /local/opt/galaxy/galaxy-dist/static/robots.txt [L] RewriteRule ^(.*) http://localhost:9009$1 [P]
ErrorLog logs/toolshed-bfx.brel.local-error_log CustomLog logs/toolshed-bfx.brel.local-access_log common </VirtualHost>
As always any help will be highly appreciated, Thanks, Carlos ___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at:
On Wed, Feb 13, 2013 at 10:38 AM, Nate Coraor <nate@bx.psu.edu> wrote:
You'll need something here like:
Satisfy Any Order deny,allow Deny from all Allow from your.galaxy.server
Thanks Nate!, this worked flawlessly. My work around was to point galaxy to the toolshed paster server at localhost:9009 instead of apache in tool_sheds_conf.xml. This is a much better solution thou. Thanks again, Carlos
On Wed, Feb 13, 2013 at 2:11 PM, Carlos Borroto <carlos.borroto@gmail.com> wrote:
On Wed, Feb 13, 2013 at 10:38 AM, Nate Coraor <nate@bx.psu.edu> wrote:
You'll need something here like:
Satisfy Any Order deny,allow Deny from all Allow from your.galaxy.server
Thanks Nate!, this worked flawlessly. My work around was to point galaxy to the toolshed paster server at localhost:9009 instead of apache in tool_sheds_conf.xml. This is a much better solution thou.
Oops, I spoke to soon. This does solve the access issue from the apache side, but then the toolshed is expecting a remote user and will answer with a message in a red box and a "HTTP/1.1 403". This is the red box message: "Access to this Galaxy tool shed is denied This Galaxy tool shed is configured to authenticate users via an external method (such as HTTP authentication in Apache), but a username was not provided by the upstream (proxy) server. This is generally due to a misconfiguration in the upstream server. Contact your local Galaxy tool shed administrator." It took me a while to realize this was the problem. I though I was doing something wrong with the apache configuration. I confirmed it by manually trying to access the URL I saw in the logs getting a "HTTP/1.1 403" from a host I had in "Allow from ...". BTW the work around I mentioned will fail as well. I though I was using it but in reality I had use_remote_user turned off. Testing too many combinations got me a little confuse on what works and what doesn't. In summary, I'm missing something here or I don't think there is currently a functional way of turning on remote user with the toolshed. Thanks, Carlos
Carlos, Sorry you're having difficulty here. I'm not able to help very much here because I'm not familiar with the Galaxy remote user authentication process and I don't have an environment in which to mess with it. In case it helps, however, the Tool Shed uses the same code for remote user authentication as Galaxy does, so if you have gotten this to work for a Galaxy instance, you should be able to use the same configuration for the Tool Shed. Greg Von Kuster On Feb 13, 2013, at 3:00 PM, Carlos Borroto wrote:
On Wed, Feb 13, 2013 at 2:11 PM, Carlos Borroto <carlos.borroto@gmail.com> wrote:
On Wed, Feb 13, 2013 at 10:38 AM, Nate Coraor <nate@bx.psu.edu> wrote:
You'll need something here like:
Satisfy Any Order deny,allow Deny from all Allow from your.galaxy.server
Thanks Nate!, this worked flawlessly. My work around was to point galaxy to the toolshed paster server at localhost:9009 instead of apache in tool_sheds_conf.xml. This is a much better solution thou.
Oops, I spoke to soon. This does solve the access issue from the apache side, but then the toolshed is expecting a remote user and will answer with a message in a red box and a "HTTP/1.1 403". This is the red box message:
"Access to this Galaxy tool shed is denied
This Galaxy tool shed is configured to authenticate users via an external method (such as HTTP authentication in Apache), but a username was not provided by the upstream (proxy) server. This is generally due to a misconfiguration in the upstream server.
Contact your local Galaxy tool shed administrator."
It took me a while to realize this was the problem. I though I was doing something wrong with the apache configuration. I confirmed it by manually trying to access the URL I saw in the logs getting a "HTTP/1.1 403" from a host I had in "Allow from ...".
BTW the work around I mentioned will fail as well. I though I was using it but in reality I had use_remote_user turned off. Testing too many combinations got me a little confuse on what works and what doesn't.
In summary, I'm missing something here or I don't think there is currently a functional way of turning on remote user with the toolshed.
Thanks, Carlos ___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at:
On Wed, Feb 13, 2013 at 3:10 PM, Greg Von Kuster <greg@bx.psu.edu> wrote:
Carlos,
Sorry you're having difficulty here. I'm not able to help very much here because I'm not familiar with the Galaxy remote user authentication process and I don't have an environment in which to mess with it.
In case it helps, however, the Tool Shed uses the same code for remote user authentication as Galaxy does, so if you have gotten this to work for a Galaxy instance, you should be able to use the same configuration for the Tool Shed.
Hi Greg, Maybe I should explain myself better here and also create a trello card to check progress on this issue. When you activate use_remote_user in the Tool Shed and correctly configure your web server(ex. Apache), everything will work as in Galaxy. You will get presented with an Apache basic authentication box and you will get access Tool Shed as expected. Every single feature in the Tool Shed works perfectly as far as I can tell. Where is the problem them?. Well, it is when you try to install a tool from the Tool Shed in a Galaxy instance. When Galaxy tries to clone the mercurial repository from the Tool Shed it gets a "HTTP/1.1 403". Even so if you made sure Apache will allow unrestricted access from the Galaxy host. You still get "HTTP/1.1 403" from the Tool Shed, as the Tools Shed is expecting a remote user header the Galaxy instance is not providing. I'm not so sure what is the best way to approach this issue. I see two possibilities thou. Galaxy will have to provide a remote user header, maybe assume the Galaxy user is the same as the Tool Shed, a good guess I think, or the Tool Shed would have to allow access to "/repositories/" even if there is no a remote user in the header. Again, I don't know if either of these options are technically possible or safe to use. Thanks for looking into this, Carlos
Thanks Carlos, I've added the following Trello card for this: https://trello.com/card/toolshed-problems-installing-a-repository-from-the-t... Greg Von Kuster On Feb 13, 2013, at 3:25 PM, Carlos Borroto wrote:
On Wed, Feb 13, 2013 at 3:10 PM, Greg Von Kuster <greg@bx.psu.edu> wrote:
Carlos,
Sorry you're having difficulty here. I'm not able to help very much here because I'm not familiar with the Galaxy remote user authentication process and I don't have an environment in which to mess with it.
In case it helps, however, the Tool Shed uses the same code for remote user authentication as Galaxy does, so if you have gotten this to work for a Galaxy instance, you should be able to use the same configuration for the Tool Shed.
Hi Greg,
Maybe I should explain myself better here and also create a trello card to check progress on this issue.
When you activate use_remote_user in the Tool Shed and correctly configure your web server(ex. Apache), everything will work as in Galaxy. You will get presented with an Apache basic authentication box and you will get access Tool Shed as expected. Every single feature in the Tool Shed works perfectly as far as I can tell.
Where is the problem them?. Well, it is when you try to install a tool from the Tool Shed in a Galaxy instance. When Galaxy tries to clone the mercurial repository from the Tool Shed it gets a "HTTP/1.1 403". Even so if you made sure Apache will allow unrestricted access from the Galaxy host. You still get "HTTP/1.1 403" from the Tool Shed, as the Tools Shed is expecting a remote user header the Galaxy instance is not providing.
I'm not so sure what is the best way to approach this issue. I see two possibilities thou. Galaxy will have to provide a remote user header, maybe assume the Galaxy user is the same as the Tool Shed, a good guess I think, or the Tool Shed would have to allow access to "/repositories/" even if there is no a remote user in the header. Again, I don't know if either of these options are technically possible or safe to use.
Thanks for looking into this, Carlos
On Feb 13, 2013, at 3:25 PM, Carlos Borroto wrote:
On Wed, Feb 13, 2013 at 3:10 PM, Greg Von Kuster <greg@bx.psu.edu> wrote:
Carlos,
Sorry you're having difficulty here. I'm not able to help very much here because I'm not familiar with the Galaxy remote user authentication process and I don't have an environment in which to mess with it.
In case it helps, however, the Tool Shed uses the same code for remote user authentication as Galaxy does, so if you have gotten this to work for a Galaxy instance, you should be able to use the same configuration for the Tool Shed.
Hi Greg,
Maybe I should explain myself better here and also create a trello card to check progress on this issue.
When you activate use_remote_user in the Tool Shed and correctly configure your web server(ex. Apache), everything will work as in Galaxy. You will get presented with an Apache basic authentication box and you will get access Tool Shed as expected. Every single feature in the Tool Shed works perfectly as far as I can tell.
Where is the problem them?. Well, it is when you try to install a tool from the Tool Shed in a Galaxy instance. When Galaxy tries to clone the mercurial repository from the Tool Shed it gets a "HTTP/1.1 403". Even so if you made sure Apache will allow unrestricted access from the Galaxy host. You still get "HTTP/1.1 403" from the Tool Shed, as the Tools Shed is expecting a remote user header the Galaxy instance is not providing.
I'm not so sure what is the best way to approach this issue. I see two possibilities thou. Galaxy will have to provide a remote user header, maybe assume the Galaxy user is the same as the Tool Shed, a good guess I think, or the Tool Shed would have to allow access to "/repositories/" even if there is no a remote user in the header. Again, I don't know if either of these options are technically possible or safe to use.
Hi Carlos, You may be able to get this to work by setting 'display_servers = <galaxy_server_hostname>' in your community_wsgi.ini file. This instructs Galaxy's remote user middleware to allow connections from this host even if a remote user has not been provided. It looks like all the pieces are there in the Tool Shed to make it work. --nate
Thanks for looking into this, Carlos
On Thu, Feb 14, 2013 at 10:30 AM, Nate Coraor <nate@bx.psu.edu> wrote:
You may be able to get this to work by setting 'display_servers = <galaxy_server_hostname>' in your community_wsgi.ini file. This instructs Galaxy's remote user middleware to allow connections from this host even if a remote user has not been provided. It looks like all the pieces are there in the Tool Shed to make it work.
Yes, this did it!. Thanks.
participants (3)
-
Carlos Borroto -
Greg Von Kuster -
Nate Coraor