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.
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?
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)?
This result is also reproducible when the JWT-SESSION token is not valid (due to token timeout).
I think the problem is in server/sonar-web/src/main/js/apps/projects/components/DefaultPageSelector.tsx, before the commit bd48df7ad63eb513a8e923ca55b0eb74bcf15b70 - SONAR-14938 Fallback on the Create Project page on brand new instance which is included in all instances after 9.0, but not in LTS versions or prior.
Can you open several tabs, each tab for one of your domains, and check your cookies? I’m imagining you will see cookies for all instances, regardless which tab you’re on, is that correct?
Yes, a JWT-SESSION and a CSRF-TOKEN for each of the instances.
But sorry, I forgot to say that I have reproduced the problem on a single open tab. In fact I have reproduced it on my local machine. The fact that I had three instances and three times the URL encoding led me to think it was related, but it is not.
Our Patch Policy does not include fixing minor bugs like that for the LTS. The LTS only includes major bug fixes, or security fixes.
In your case, a possible workaround is to make sure you clear your cookies when switching domains. Note that this should not affect the latest 9.x series, where we introduced a new cookie policy. This means it will be fixed in the upcoming 9.x LTS (which will be released beginning of 2023).
