Community
Participate
Working Groups
Trying to open a change from a Gerrit 2.9 instance, I inconsistently get an error dialog saying "Unable to login to <server>. Please validate credentials via Task Repositories view". But the repository credentials are correct and validate fine. See error log entry at bottom of message. I wonder if the problem is with this bit in GerritClient29: String querysubmit = "/changes/" + Integer.toString(reviewId) + "/revisions/current/test.submit_rule?filters=SKIP"; //$NON-NLS-1$//$NON-NLS-2$ List<SubmitRecord> submitRecord = currentSubmitRecord(querysubmit, monitor); Because the currentSubmitRecord method executes a POST request, perhaps the querysubmit parameter should use the authentication URI (with the "/a/" prefix)? Just guessing. org.eclipse.core.runtime.CoreException: Unable to login to <server>. Please validate credentials via Task Repositories view. at org.eclipse.mylyn.internal.gerrit.core.GerritConnector.toCoreException(GerritConnector.java:408) at org.eclipse.mylyn.internal.gerrit.core.remote.GerritReviewRemoteFactory.pull(GerritReviewRemoteFactory.java:137) at org.eclipse.mylyn.internal.gerrit.core.remote.GerritReviewRemoteFactory.pull(GerritReviewRemoteFactory.java:1) at org.eclipse.mylyn.reviews.core.spi.remote.emf.RemoteEmfConsumer.pull(RemoteEmfConsumer.java:128) at org.eclipse.mylyn.reviews.core.spi.remote.JobRemoteService$1.run(JobRemoteService.java:61) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
I should add that in debug I see that the response body coming back from the post request is: Invalid authentication method. In order to authenticate, prefix the REST endpoint URL with /a/ (e.g. http://example.com/a/projects/).
Thanks for the hint. I wonder when we should be using the /a/ prefix and when we shouldn't.
According to this post[1] it is good idea to prefix all REST calls with '/a/' and always send user credentials. Unless you already have Gerrit's session id and x-gerrit-auth token, then you can drop '/a/' and provide both tokens (session as a cookie and x-gerrit-auth in request header). [1] https://groups.google.com/d/msg/repo-discuss/KsPPUpFIz18/q2huCHazv0oJ
Thanks. It sounds like we should consider using digest authentication and dropping the xsrf stuff.
Some additional information. I've been struggling to debug this since it happens intermittently (and rarely when I'm debugging). I've seen that the problem happens when, in GerritHttpClient, somehow obtainedXsrfKey = true, but xsrfKey = null. Once this happens, the X-Gerrit-Auth header will never be set correctly. It doesn't look like this should ever happen, but maybe a synchronize issue? Also, when the header is not set, all the GETs that happen while getting the change still work fine, prior to the failure on the POST in GerritClient29.currentSubmitRecord. Just throwing this out there in case it inspires anybody who understands all this better than I do!
Could the problem be in GerritHttpClient.updateXsrfKey: String xGerritAuth = processor.getXGerritAuth(); if (xGerritAuth != null) { setXsrfKey(xGerritAuth); } else { setXsrfKey(processor.getXsrfKey()); } Should there be a null check on processor.getXsrfKey() prior to calling setXsrfKey? If null gets passed to setXsrfKey, it will still set obtainedXrfKey to true, and then it will never again try to get a key. This would happen any time the response contains neither hostpagedata.xsrfToken nor hostpagedata.xGerritAuth.
I hope I haven't cried wolf so many times that nobody is listening to me ;-) I think that the problem might have to do with the cached GerritAccount cookie having expired. This will result in GerritHttpClient.updateXsrfKey setting xsrfKey to null. A 403 on a subsequent api call (X-Gerrit-Auth header null) will trigger re-authentication, which will get a new GerritAccount cookie but does not try again to obtain an xsrfKey. It seems this might be fixed in GerritHttpClient: if (code == HttpURLConnection.HTTP_UNAUTHORIZED || code == HttpURLConnection.HTTP_FORBIDDEN) { // login or re-authenticate due to an expired session authenticate(openIdProvider, monitor); updateXsrfKey(monitor); // Add this line! Note that this problem doesn't manifest itself for a lot of GET calls, but once you try to open the change editor with X-Gerrit-Auth:null, you will get an error on this one: POST https://<host>/gerrit/changes/203/revisions/current/test.submit_rule?filters=SKIP (for example) Thanks
Don't worry Steve, your comments were not going unnoticed. A review has been pushed with a fix similar to the code in your last comment. Review https://git.eclipse.org/r/#/c/46008/ Instead of updating the xsrfKey directly, we can set the obtainedXsrfKey boolean to be false. This way, the same effect takes place (we'll update the key) on the next attempt.
Great, thanks!
I've merged the change so we can see if it really solves the problem. We should still consider using digest authentication and/or improving the test coverage of this.
(In reply to Nicholas Folk from comment #8) > Review https://git.eclipse.org/r/#/c/46008/ That worked for me, just updated to 2.6.0.N20150417-2059 and the problem is gone.
The fix also seems to work for me.
Thanks Nick for the fix! I've opened bug 465349 to follow up.
