Community
Participate
Working Groups
In GerritHttpClient, the authenticate method is explicitly coded not to follow redirects: GetMethod method = new GetMethod(WebUtil.getRequestPath(repositoryUrl + LOGIN_URL)); method.setFollowRedirects(false); int code; try { code = WebUtil.execute(httpClient, hostConfiguration, method, monitor); if (needsReauthentication(code, monitor)) { return -1; } if (code == HttpStatus.SC_MOVED_TEMPORARILY) { Header locationHeader = method.getResponseHeader("Location"); if (locationHeader != null) { if (locationHeader.getValue().endsWith("#SignInFailure,SIGN_IN,Session cookie not available.")) { // try different authentication method return HttpStatus.SC_NOT_FOUND; However, this is a specific assumption about how Gerrit is configured. In the case of being behind an enterprise SSO, redirects are frequently used to send the request to a central location instead of the Gerrit instance, such that the authentication request gets handled at an SSO box. The point is if this redirection code is handled, but it's not the magic value that you're looking for, the request redirection is silently dropped and no further change occurs. Instead of doing this sniffing, the authentication should have redirects enabled so that the right sequence of 302/401 etc. is given.
Here's what the path looks like here: Client -> /gerrit/login/mine Server <- 302 redirect Client -> /gerrit/rpc/... Here's what it should look like: Client -> /gerrit/login/mine Server <- 302 redirect Client -> Elsewhere/login Elsewhere Server <- 401 auth required Client -> auth credentials Elsewhere Server <- 302 gerrit:/gerrit + cookies Client -> /gerrit/login/mine + cookies So when it doesn't get the locationHeader, instead of just assuming everything has worked it should do the redirection at that point.
Thanks for the bug report. Support for SSO is tracked on bug 328723 and handling of redirects is tracked on bug 203545. I'll mark this as a subtask to consider this bug once we start working on the parent tasks.
Oh, good grief no. The handling of JIRA redirects is painful at the moment and shouldn't be there. It is absolutely, 100%, not the right thing to do in this case either. The redirection is not saying 'You should use this URL instead' it is saying 'Go here for authentication purposes'. This should not affect whatever the user has configured in the dialog box which is always the right thing to use in future requests.
Consider logging into Blogger. If you have credentials already, then you're taken through to the website. If you haven't got credentials, or they have expired, then you're redirected to the Google Accounts page for verification. You really don't want to prompt the user and say "Do you want to replace http://www.blogger.com with http://www.google.com/accounts", and that's exactly what the JIRA redirection does at the moment. It would also be completely useless for this case, where you're being transparently redirected to an authentication provider for the purposes of accessing the URL that you've already declared. It also really won't help when it redirects you back again with the credentials.
Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn
