1

This is happening for all users and only on production environment.

"Your session has ended. Enter your password to log back in."

Entering your password does not allow you to actually see the admin panel again.

Things we have tried:

  • Deleting the contents of craft/storage/runtime
  • Removing all rows from craft_sessions in db
  • Setting 'overridePhpSessionLocation' => false
  • Setting 'requireMatchingUserAgentForSession' => false
  • Setting 'userSessionDuration' => false
  • Setting craft/app/, craft/storage and craft/config as CHMOD 774
  • Changing craft/ folders to be owned by www-data
  • Setting session.auto_start = 0

    Our environment is PHP 7 with Ubuntu 16.04 running Apache 2.4.18

    Something to consider is we run with an Akamai CDN cache that is set to ignore our entire /admin directory, but my suspicion is that something elsewhere is getting cached. Thoughts about that? Is there another directory we should be ignoring?

    Also as a point of info, our /craft folder is above the docroot so not publicly accessible and therefore unlikely to be cached.

    Finally, what's very strange is if I remove the modal containing the error message from the DOM in Chrome Inspect, I am able to still navigate the panel fine, without having to re-authenticate. Error also happens in both Chrome and Firefox.

  • 12
    • If you go to yoursite.com/admin/utils/phpinfo and search for session save_path, can you verify that path is writable by the user:group that apache is running as? – Brad Bell Oct 13 '16 at 17:46
    • @BradBell thanks for the response. Yes, have verified that /var/lib/php/sessions is writable by www-data and has session files currently being written to it. – Ian O'Brien Oct 13 '16 at 18:51
    • Are you on a load-balanced web server setup, by chance? – Brad Bell Oct 13 '16 at 19:47
    • No load-balancing currently. – Ian O'Brien Oct 13 '16 at 19:57
    • 2
      I would turn off caching completely. It's really the only way to rule out if it's your server or the CDN. If that ends up being the CDN, then you might have to reach out to Akamai for assistance on ignoring specific sessions with cookies, etc. – RitterKnight Oct 14 '16 at 18:40
    3

    Thanks for the troubleshooting help. It appears as though the issue was the cache and how Craft handles sessions.

    For those who use a cache/CDN and are having issues with control panel session timeout:

    Even after ignoring /admin on our cache, the cached pages on the public-facing portion of the site were conflicting somehow with how Craft was handling the sessions in the admin panel.

    Our solution was to create a cookie we called isAuth that was created on login and destroyed on logout. We did this by creating a plugin and using userSession.onLogin and userSession.onLogout.

    Then we set our Akamai cache to no-cache, no-store if isAuth cookie is present. This fixed all timeout issues.

    2
    • Hey Ian, it seems I'm having the same issue. Do you have this plugin available for download somewhere? I'd love to try this out because everything I've tried doesn't seem to stop this logout issue from happening. – nathanielperales Jan 10 '18 at 23:09
    • Hey @nathanielperales we did not release this as a plugin as it doesn't actually clear the cache, it just adds a cookie. You can set a cookie using the Craft 3 Cookies plugin here or if you have Craft 2, it's available here – Ian O'Brien Jan 12 '18 at 14:30

    Your Answer

    By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

    Not the answer you're looking for? Browse other questions tagged or ask your own question.