- Posts: 3
- Thank you received: 0
- English support forums
- Installation & update issues
- We are sorry but your session has expired
We are sorry but your session has expired
We are getting a lot of complaints from users that when they try to complete a survey, the get the following error: We are sorry but your session has expired
Some of the users said they are getting this issue even when submitting the survey immediately after opening it, so it is definitely not a session timeout issue.
I've found a couple of other threads about the same topic, but none of them has a definitive answer.
Below is my server's phpinfo. I don't have permission to modify ini.php
Any assistance would be appreciated.
I can't seem to find the Session lifetime (seconds): option in Global Settings. I am running LimeSurvey Version 3.7.2+180508
Is there another way to set the session lifetime?
Just to clarify, the users get an issue even when they immediately complete the survey (e.g. 3 seconds from opening the survey to submitting it).
Other users are able to take a few minutes to complete the survey without issues.
"Session lifetime (seconds) (only available with database sessions): Defines the time in seconds after which a survey session expires (provided there is no action from the participant). When using regular, file-based sessions, it is up to the system administrator to define the right values for 'session.gc_maxlifetime', 'session.save_path', etc., in the PHP configuration. Not only the web server settings but also the other similar settings of other applications may overwrite the setting for file-based sessions when editing it locally via the application. The maximum value that can be introduced is 65000 (seconds). It is recommendable to use a reasonable value. Bear in mind that, when using database sessions, check whether the MySQL setting called max_allowed_packet is set to a large value because some surveys generate over 2 MB of session data"
In addition, even though I have token-based response persistence active, they are reporting that when they reload the survey it does not bring up their prior responses and they need to begin again from the beginning.
Any help with this would be welcome!
I'm currently using version 3.17.1, and had the same "session expired" problem, plus other strange symptoms such as a login impossibility, and I finally solved it.
It turned out to be a cookie problem. By default, limesurvey uses the classical "PHPSESSID" cookie name to store the session info. Someone else in my non-profit organization, working on another website located in the same higher-level domain name (let's call it "example.org") had a "brilliant" idea: he decided to share the session state among several websites (let's say " www.example.org ", "forums.example.org", etc.), and decided to use the PHPSESSID cookie name, but associated with the "umbrella" domain "example.org"...
So, someone who has previously visited one of those websites, and who then comes to the limesurvey site (whose name could be "limesurvey.example.org") gets 2 "PHPSESSID" cookies in their browser: one associated with the "example.org" domain, and one associated with the "limesurvey.example.org" domain.
RFC6265 ( tools.ietf.org/html/rfc6265 ) states, in §4.2.2:
Although cookies are serialized linearly in the Cookie header,
servers SHOULD NOT rely upon the serialization order. In particular,
if the Cookie header contains two cookies with the same name (e.g.,
that were set with different Path or Domain attributes), servers
SHOULD NOT rely upon the order in which these cookies appear in the
It looks like Limesurvey depends on this order, and in that way, is not compliant with RFC6265.
The workaround I used consists in changing the name of the session cookie in Limesurvey. This can easily be done in "config.php" by adding this code snippet:
'session' => array ( 'sessionName' => "MyOwnPrivateCookieName", ),
That way, everything runs fine again, but I think Limesurvey should address that problem. Unfortunately, my competencies in PHP are such that I cannot propose a patch for that, sorry.
- Posts: 8195
- Karma: 620
- Thank you received: 2486
Thanks, and please give a link here so we can follow the bug.
...it was my intention to file a bug report...
Solutions, code and workarounds presented in these forums are given without any warranty, implied or otherwise.
Official LimeSurvey Partner - partnersurveys.com
That's why it makes no longer sense to post here first. First open a bugticket and than a forum post Saves time and indicated issues around GUI/understanding if the bugticket was just a misunderstanding.
holch wrote: The developers do not check every post in the forum.
The issue around the default sessionname is known for years. It was seen as the job of the webmaster to setup names. Many php applications are generating session names to prevent issues around multi-installations / shared webhosting. It's one more bulletpoint on the checklist to use LimeSurvey productive (like deactivate AJAXmode etc.)
It might will be changed in this effort: bugs.limesurvey.org/view.php?id=14621#c51047
The meaning of the word "stable" for users
- Posts: 11389
- Karma: 412
- Thank you received: 2058