Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTTP Authentication no longer works after enabling oauth #88

Closed
jameshartig opened this issue Apr 17, 2017 · 12 comments
Closed

HTTP Authentication no longer works after enabling oauth #88

jameshartig opened this issue Apr 17, 2017 · 12 comments

Comments

@jameshartig
Copy link

We we're trying out 2.14.x and after setting auth=OAUTH we now get the following error when users try to HTTP authenticate with their git clients:

java.lang.UnsupportedOperationException: git over oauth is not implemented by gerrit-oauth-provider plugin
at com.googlesource.gerrit.plugins.oauth.DisabledOAuthLoginProvider.login(DisabledOAuthLoginProvider.java:36)
at com.google.gerrit.server.auth.oauth.OAuthRealm.authenticate(OAuthRealm.java:91)
at com.google.gerrit.server.account.AccountManager.authenticate(AccountManager.java:111)
at com.google.gerrit.httpd.ProjectOAuthFilter.verify(ProjectOAuthFilter.java:171)
at com.google.gerrit.httpd.ProjectOAuthFilter.doFilter(ProjectOAuthFilter.java:114)
at com.google.gerrit.httpd.RequestMetricsFilter.doFilter(RequestMetricsFilter.java:57)
at com.google.gerrit.httpd.AllRequestFilter$FilterProxy$1.doFilter(AllRequestFilter.java:133)
at com.google.gerrit.httpd.AllRequestFilter$FilterProxy.doFilter(AllRequestFilter.java:135)
at com.google.gerrit.httpd.RequestContextFilter.doFilter(RequestContextFilter.java:72)
at com.google.inject.servlet.ManagedFilterPipeline.dispatch(ManagedFilterPipeline.java:120)
at com.google.inject.servlet.GuiceFilter.doFilter(GuiceFilter.java:135)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at org.eclipse.jetty.server.Server.handle(Server.java:534)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)
at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
at java.lang.Thread.run(Thread.java:745)
@davido
Copy link
Owner

davido commented Apr 19, 2017

/CC @lucamilanesio

@lucamilanesio
Copy link
Contributor

Yeah, that is something specific to Ver. 2.14: HTTP Digest Auth isn't there anymore and all authentications are specific to the provider. I recall, however, we introduced a policy to still allow standard HTTP passwords, isn't it?

@davido
Copy link
Owner

davido commented Apr 19, 2017

What was that policy exactly? Or should the provider now implement itself OAuth-token based authentication, like cfoauth plugin is doing?

@lucamilanesio
Copy link
Contributor

There you go: https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#auth.gitBasicAuthPolicy
If you set auth.gitBasicAuthPolicy = HTTP ... it should work again :-)

@davido
Copy link
Owner

davido commented Apr 19, 2017

Thanks, I think I understand now what happened. To rectify #84, i added DisabledOAuthLoginProvider in: [1]. Later, you have added OAUTH to the auth.gitBasicAuthPolicy policy in: [2].

So the solution is as easy as: adding this option to the gerrit.config should fix it:

  auth.gitBasicAuthPolicy = HTTP

We should add this to the plugin documentation and FAQ. Will do it later, and let this issue open for a while.

@jameshartig
Copy link
Author

Thanks @davido and @lucamilanesio for the quick turnaround. I can confirm that adding that option fixed the issue for me.

@lucamilanesio
Copy link
Contributor

@fastest963 we shouldn't discuss Gerrit issues on GitHub though: typically all the issues are discussed on the Gerrit issue tracker or the mailing list.
See:

@jameshartig
Copy link
Author

@lucamilanesio I had thought that this plugin was the issue, I didn't realize the followup comments that it was a gerrit issue. The error made it seem like this plugin didn't support HTTP authentication for git requests and I saw that there was a change in #84 specifically that added that error message that I was seeing.

@lucamilanesio
Copy link
Contributor

lucamilanesio commented Apr 19, 2017

@fastest963 this plugin is on Gerrit Code Review as well (https://gerrit.googlesource.com/plugins/oauth) :-) This is simply the original repo where it was developed and is not the master "source of truth anymore"

@jameshartig
Copy link
Author

@lucamilanesio oops! Didn't see that. I just found the plugin by searching google. Thanks for the info.

@lucamilanesio
Copy link
Contributor

Btw ... I've created an issue on Gerrit => https://bugs.chromium.org/p/gerrit/issues/detail?id=6034

lucamilanesio added a commit to GerritCodeReview/gerrit that referenced this issue Apr 21, 2017
When migrating to Gerrit 2.14, users on LDAP and OAuth want to be
aware that a decision needs to be made on whether the Gerrit HTTP
password should be used or not during Git/HTTP authentication.

Not making any choice during upgrade, would have the effect of
just using the default value, which may not be compatible with the
user's needs and expectations, leading to failures after upgrade.

This is what happened to early adopter of Gerrit 2.14 + OAuth:
davido/gerrit-oauth-provider#88

Bug: Issue 6034
Change-Id: Iaa6677e95cc1a3e88e9987fc226abefe26603587
@jameshartig
Copy link
Author

The issue listed above was merged and so this should be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants