Cannot log into SonarQube 6.3

[Michael Piefel]

Good morning everybody,

I have a weird log-in problem after the upgrade from SonarQube 6.1 to 6.3 – I cannot log in anymore. During initial setup, admin/admin worked fine and I installed all the plugins. Then I restarted with the real database.

Now, when I try to log in, my credentials are checked. When I enter incorrect credentials, I get the appropriate red box on top. When I enter correct credentials, I am redirected to the previous page all right, but the system still shows the log-in link, and I am not logged in.

Don’t know what to do now. Which log can I look into? I tried setting logging to TRACE, but that’s just too much for me to read, so I would need a pointer as what to look after.

Regards,
     Michael

[Julien Lancelot]

Hi Michael,

Are you using an authentication plugin (LDAP, Github Authentication, Google Authentication, etc.) ?

Could you try to login using a private window of your browser ?

Regads,

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/0accba34-bb5d-4afc-a00f-0eb43affa33f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Julien LANCELOT | SonarSource

http://sonarsource.com

[Michael Piefel]

Hi Julien,

Am Donnerstag, 16. März 2017 14:05:36 UTC+1 schrieb Julien Lancelot:

Are you using an authentication plugin (LDAP, Github Authentication, Google Authentication, etc.) ?

Yes, I used the LDAP plugin. The effect was the same for both a local user (as a fallback for an administrator) and with a user from LDAP; ie. authentication itself worked, but then no real log-in happened. However, I have first disabled (in the config) and now uninstalled the LDAP plugin and try it only with my local user.

 

Could you try to login using a private window of your browser ?

OK, I tried that. No change. Also in a different browser, and in then in private mode in that, no change.

The POST to /api/authentication/login returns a 401 on an incorrect password and a 200 on a correct password, the subsequent call that loads the HTML sends both the newly set cookies XRFS-TOKEN and JWT-TOKEN along.

I don’t know about that JWT token. Is it normal that ‘exp’ and ‘iat’ are set in seconds since the epoch, and ‘lastRefreshTime’ is in milliseconds? Also, I notice that exp is actually before the last refresh time (last Tuesday?), and looks a bit suspicious, too. But then again, I don’t know much about JWT.

Regards,

   Michael

[Michael Piefel]

I don’t know about that JWT token. Is it normal that ‘exp’ and ‘iat’ are set in seconds since the epoch, and ‘lastRefreshTime’ is in milliseconds? Also, I notice that exp is actually before the last refresh time (last Tuesday?), and looks a bit suspicious, too. But then again, I don’t know much about JWT.

To follow up on myself: I do not believe this token is valid. Of course any system can interpret the claims in the payload as it wants, but it is suspicious:

• The iat value  is the number of seconds since the epoch for the moment the JWT token is issued.
  
• The exp value, which the standard says is ‘expiration time’ is either a value that says it expires in 47 years, or it is the number of seconds since the epoch of a point in time that is about 9 days in the past.

With an expired token, it’s no surprise all subsequent calls treat me as unauthorized again.

Regards,
     Michael

[Michael Piefel]

OK, I found the culprit. It is sonar.web.sessionTimeoutInMinutes setting in sonar.properties. The comment there says that the value cannot be greater than three months (which would be 129600 or a bit more). This statement is true. However, in reality 35791 is the largest accepted value, which is a bit less than 25 days.

So, I fixed it on my side (although I would prefer a longer timeout), but it seems to be a bug in either the documentation or the code.

Greetings,

   Michael

[Julien Lancelot]

Thanks Michael, I confirm this bug as I'm easily able to reproduce it !

This issue is not from the documentation but is a real bug.

Here's the ticket that will fix it : https://jira.sonarsource.com/browse/SONAR-7731

Regards,

Julien Lancelot

--

You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/5796da45-74ca-4e40-9237-b368a7d48a40%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[pranav...@gmail.com]

I am also facing the same issue, not able to login to 6.3 SQ version. I migrated from 5.6 LTS version to 6.3, i dont see anything in logs. Please let me know if there are any temporary admin credentials to start my initial setup.

Thanks in advance.

[Juven Zhong]

Hi,

I got the same problem on version 6.4 + LADP

the access.log wrote:

10.20.0.88 - - [04/Jul/2017:13:50:56 +0800] "POST /api/authentication/login HTTP/1.1" 401 - "http://10.4.100.213:9000/sessions/new" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36" "AV0MJHUKw9lGbId9AAAb"

the LDAP configuration is just copied from official site(changed accordingly)：

# LDAP configuration

# General Configuration

sonar.security.realm=LDAP

ldap.url=ldap://myserver.mycompany.com

ldap.bindDn=my_bind_dn

ldap.bindPassword=my_bind_password

 

# User Configuration

ldap.user.baseDn=ou=Users,dc=mycompany,dc=com

ldap.user.request=(&(objectClass=inetOrgPerson)(uid={login}))

ldap.user.realNameAttribute=cn

ldap.user.emailAttribute=mail

 

# Group Configuration

ldap.group.baseDn=ou=Groups,dc=sonarsource,dc=com

ldap.group.request=(&(objectClass=posixGroup)(memberUid={uid}))

anyone has idea on this will be appreciate.

在 2017年3月16日星期四 UTC+8下午6:32:27，Michael Piefel写道：