Is this related? -- http://httpd.apache.org/docs/2.4/upgrading.html#run-time

We must have "You already have a token, but seems not the same than the session : click here to start the survey again".

I have it sometimes with apache2.2 and make test.

It seems to be happening every time with Apache 2.4, not just sometimes -- at least I haven't not run into it in Apache 2.4. 1st click on do survey link from token table opens the survey, but the 1st use of next to move to the next group results in the error. The same happens if logged out but follow two different token links without exiting browser in between.

Maybe related to 9914?

Do the following have any bearing on this? (from the "Is this related?" link above) --

• mod_cache: CacheIgnoreURLSessionIdentifiers now does an exact match against the query string instead of a partial match. If your configuration was using partial strings, e.g. using sessionid to match /someapplication/image.gif;jsessionid=123456789, then you will need to change to the full string jsessionid.

• mod_cache: The second parameter to CacheEnable only matches forward proxy content if it begins with the correct protocol. In 2.2 and earlier, a parameter of '/' matched all content.

The php respect module that handles where session data is stored wasn't loading, and addressing that resolved our logout issue. But the issue reported in this ticket is still occurring.

A curl -v to a valid token link on the environment DC leads to:

About to connect() to [domain] port 80

• Trying [ip]... connected
• Connected to [domain] ([ip]) port 80

  GET [path to token link] HTTP/1.1
  User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
  Host: [domain]
  Accept: /

  < HTTP/1.1 302 Found
  < Server: Apache/2.4
  < Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
  < Content-Type: text/html; charset=UTF-8
  < Date: Sat, 26 Sep 2015 06:10:25 GMT
  < Location: https://[token_link]
  < Expires: Thu, 19 Nov 1981 08:52:00 GMT
  < Pragma: no-cache
  < Connection: Keep-Alive
  < Set-Cookie: X-Mapping-nfcoiaoj=836D90EBE8A0978A86DDCAE83F09BF73; path=/
  < Set-Cookie: PHPSESSID=n9sedg30jvntu6uem198kf21l6; path=/; HttpOnly
  < Content-Length: 0

• Connection #0 to host [domain] left intact
• Closing connection #0

Uncommenting table-based sessions lines in config.php resulted in a white screen with nothing loaded at the admin login page. Any suggestions?

Also, adding "Set the cookie via SSL" to config.php from https://manual.limesurvey.org/Optional_settings#Update_LimeSurvey_config resulted in: Internal Server Error
Property "LSYii_Application.session" is read only. Any thoughts on additional Yii settings, or is this barking up the wrong tree?

<q>Internal Server Error
Property "LSYii_Application.session" is read only. Any thoughts on additional Yii settings, or is this barking up the wrong tree? </q>

? Strange if the config is OK. Session start in phpinfo ?

<q 33180> Uncommenting table-based sessions lines in config.php resulted in a white screen with nothing loaded at the admin login page. Any suggestions?</q>

I was so focused on finishing building a replica under Apache 2.2 that I had also uncommented the comment line -- "// Uncomment the following line if you need table-based sessions". Applying that correctly resolved the sessions state issues in the item reported here under Apache 2.4.

<q 33184> ? Strange if the config is OK. Session start in phpinfo ?</q>

The way I had attempted to test this was a straight copy-paste of the "// Set the cookie via SSL lines" from https://manual.limesurvey.org/Optional_settings#Session_settings, pasting them in just above "// Use the following config variable to set modified optional settings copied from config-defaults.php". However, it also with the table-based session section fully commented.

Should I re-try that differently now that session states are working with the table-based session configuration properly applied?

q 33184 : due to "LSYii_Application.session" .... But if your config.php is broken : anything can happen.

the 'session' must be at same place than 'urlManager'

Starting the same survey with different tokens at the same time on the same browser is currently not supported.

Prior to changing to table-based sessions, the problem reported here was occurring when logging in as an administrator and clicking on any "do survey" link in a token table and progressing to a 2nd group, or when re-launching the same token link received via email more than once without closing the browser-in-between.

However, after changing to table-based sessions all is operating normally once again.

(Also prior to changing to table-based sessions, the issue reported here was occurring when used token links from two different surveys received via email without closing the browser in-between. All is well after switching to table-based sessions.)