Login failed when using sonar.web.sessionTimeoutInMinutes

Using SonarQube 7.9.3 with apache as HTTPS offload/reverse proxy on RH7.

We are required to specify a session timeout so we added the sonar.web.sessionTimeoutInMinutes=30 in sonar.properties.

But as a side-effect, most users are complaining that the first time they try to log-in, despite their credentials are OK, they’re redirected to login screen and asked for their credentials a second time. After loggin in for the second time, everything seems to be working.
EDIT: sorry, this effect is happening only after a session timeout.

Not sure if this change in Sonar requires some tweaking at the apache layer, or it’s some kind of bug in sonar itself.

This is happening in our sonar stagging instance. The real instance (which has not the timeout property) is working with no issues.

Any thoughts about this?

Hi @Alex_Perez,

I’m not sure I understand. Do you mean, they are asked to log in after remaining inactive for 30mins? Or they are asked to login again after 30mins, regardless of the fact if they’re active or not on SonarQube?

QA dept asked us to do something to auto-logout users after 30mins idle. This is accomplished by adding the property (ok)
But, we noticed that users after being logged-out due to inactivity, when they try to log again the first attempt is a failure (despite their credentials are OK).
Trying to log in for a second time works fine … but the first login attemp after a session timeout is failing.

I tried on 7.9.3, 7.9.5, and 8.6, but couldn’t reproduce. Can you reproduce the error if accessing SonarQube directly, bypassing the Apache proxy?

Update: Are there other SonarQube instances running on the same domain (e.g. a staging instance)? Furthermore, does the issue also happen when using a different browser, or when in incognito mode?

There are 2 sonar instances (TEST, PROD) but isolated in different VLANs. They don’t see each other.
Looks like the browser doesn’t affect to this problem (chrome, IE, edge … incognito)

I cannot reproduce it when accessing directly to sonar server (http://host:9000). But the problem is happening often if accessing through apache (https://easy-url/). This sounds like the apache layer need some fine tweak …

I know that this is out of sonar scope but i think that it will be useful for the community to have a “canonical” apache configuration.

We’re running sonar in a RHEL7 with a pretty standard SSL-offload / reverse proxy. Maybe we should set some apache timeout to match sonar session timeout?

Listen 443 https

SSLPassPhraseDialog exec:/usr/libexec/httpd-ssl-pass-dialog

SSLSessionCache shmcb:/run/httpd/sslcache(512000)
SSLSessionCacheTimeout 300

SSLRandomSeed startup file:/dev/urandom 256
SSLRandomSeed connect builtin
SSLCryptoDevice builtin

ProxyRequests Off ProxyPreserveHost On

RequestHeader set X-Forwarded-Proto https

ServerName sonar-test.mycompany.com
ServerAdmin me@mycompany.com
ProxyPass / http://localhost:9000/
ProxyPassReverse / https://sonar-test.mycompany.com/
ErrorLog logs/sonar_error.log
CustomLog logs/sonar_access.log common

TransferLog logs/ssl_access_log
LogLevel warn

SSLEngine on
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite HIGH:3DES:!aNULL:!MD5:!SEED:!IDEA
SSLCertificateFile /etc/pki/tls/certs/sonar-test.pem
SSLCertificateKeyFile /etc/pki/tls/private/sonar-test.key

<Files ~ “.(cgi|shtml|phtml|php3?)$”>
SSLOptions +StdEnvVars

<Directory “/var/www/cgi-bin”>
SSLOptions +StdEnvVars

BrowserMatch “MSIE [2-5]”
nokeepalive ssl-unclean-shutdown
downgrade-1.0 force-response-1.0

CustomLog logs/ssl_request_log
“%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x “%r” %b”

Thank you.

1 Like

That might indeed be useful.

Do you have some other cache settings? I see you use SSLSessionCache, but I’m not sure that would have an impact in this case. Do you have some other directives set? Perhaps in some other file (like httpd.conf)?