| Issue 1743: | Including authentication scheme in authorization header breaks reverse proxy with HTTP Basic Auth | |
| 8 people starred this issue and may be notified of changes. | Back to list |
Affected Version: GIT master What steps will reproduce the problem? 1. Set up Gerrit behind a reverse proxy which authenticates users using HTTP Basic Auth (in gerrit config, [auth] section: "type = HTTP") 2. Try to access Gerrit What is the expected output? What do you see instead? Authentication succeeds for accessing the main HTML document and some static GWT files, but subsequent REST API requests against accounts/self/capabilities/ and changes/ fail because HTTP Basic Authentication client header gets overridden by a "Authorization: Bearer TOKEN_DATA". Please provide any additional information below. It seems that the change has been introduced with these commits: commit 074c7e5817a17bf53bc0aba1b5acd88f10d1513a Author: Shawn O. Pearce <sop@google.com> Date: Thu Nov 15 23:24:41 2012 -0800 Allow WebSession to check XSRF token I broke the way gerrit-review verifies the user's XSRF token on the older-style JSON-RPC invocations. Allow the WebSession implementation to check the token by passing in the entire token string, rather than looking to see if it is equal. Change-Id: Ib3cc7d08ae44e8ef79a2ae8f669897d252acc586 commit aada97b178003b55ed65fb4b631b68bae5e8ce11 Author: Shawn O. Pearce <sop@google.com> Date: Wed Nov 14 01:11:22 2012 -0800 Include authentication scheme in authorization header This allows the session provider to decide what authorization scheme the browser should present when it makes JSON REST API calls to the server. By default we call it Bearer to match an OAuth2 style of authentication that browsers won't do natively, but this can be changed by modifying what the session tracking implementation returns from getAuthorization(). Change-Id: If0bf3d57f5564bd06811b6c1c509b0ad5e525495
Jan 3, 2013
BTW, the POC patch is also not a good idea because it removes XSRF protection from the REST API, which is needed even with HTTP Basic Auth being in use. IMO the correct solution would be to use a HTTP Header Name that doesn't collide with HTTP Authentication in order to pass the anti-XSRF token.
Jan 15, 2013
I think this bug may be affecting HTTP_LDAP also. I was trying to work with a build from a414852, and discovered I can't log in to Gerrit anymore. I didn't change my Apache reverse proxy settings or any Gerrit settings. When I go to the Gerrit URL in a browser, I'm prompted to log in, Gerrit starts to load the dashboard, and I can see my name in the top right corner, but then I'm presented with endless login windows and can't use Gerrit. I see the following in my Apache logs: [Tue Jan 15 18:43:58 2013] [error] [client 10.50.8.24] client used wrong authentication scheme: /code-review/accounts/self/capabilities, referer: https://10.30.41.221/code-review/ [Tue Jan 15 18:43:59 2013] [error] [client 10.50.8.24] client used wrong authentication scheme: /code-review/changes/, referer: https://10.30.41.221/code-review/ I did this on two very different test systems, so its not just one instance acting weird. LDAP authentication alone is ok, but HTTP_LDAP is not.
Jan 15, 2013
Yes, definitely, HTTP_LDAP would also be affected because it employs the same mechanism in the HTTP layer - HTTP Basic Auth. You can try adding the comparison against HTTP_LDAP auth type in my patch line 51. Please report if it solves your problems.
Jan 16, 2013
I changed references to AuthType.HTTP to AuthType.HTTP_LDAP in your patch and authentication worked again.
Jan 30, 2013
Can you upload your patch for review on gerrit-review.googlesource.com?
Feb 12, 2013
I'm surprised more people haven't run into this. Aleksander, if you don't want to push this change for review, I can push the commit based on your patch that I'm using to make HTTP_LDAP work.
Feb 12, 2013
Hello David, Nick. I'm a bit preoccupied now so don't have time for polishing and pushing the patch. If you have time for this, feel free to do anything you want with it.
Feb 12, 2013
OK. I rebased on master and built a new WAR. I'll test it pretty soon and if everything works as I expect I'll push the change for review.
Feb 13, 2013
Retested master and confirmed the issue still exists. Rebased the fix on master and confirmed that it fixes the authentication problem. Gotta get my CLA figured out, then I'll push it.
Mar 1, 2013
We are hitting this now, and need a workaround. In particular we need to be able to use git over http. Was this working in any released version? If so, can someone point me to it? Thanks,
Mar 11, 2013
Here's a starting point based on Aleksander's patch: https://gerrit-review.googlesource.com/#/c/43310/ Someone who is more familiar with the code will need to streamline this into a real fix though.
Mar 11, 2013
(No comment was entered for this change.)
Status:
Submitted
Labels: FixedIn-2.6 |
|
| ► Sign in to add a comment |
2.8 KB View Download