Answers.Body: <p>Thanks for the troubleshooting help. It appears as though the issue was the cache and how Craft handles sessions.</p>
  
  <p><strong>For those who use a cache/CDN and are having issues with control panel session timeout:</strong></p>
  
  <p>Even after ignoring <code>/admin</code> 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.</p>
  
  <p>Our solution was to create a cookie we called <code>isAuth</code> that was created on login and destroyed on logout. We did this by creating a plugin and using <code>userSession.onLogin</code> and <code>userSession.onLogout</code>.</p>
  
  <p>Then we set our Akamai cache to <code>no-cache, no-store</code> if isAuth cookie is present. This fixed all timeout issues.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-10T23:09:20.990Z
Answers.Text: 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.
Answers.UserDisplayName: nathanielperales
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-12T14:30:40.800Z
Answers.Text: 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](https://github.com/nystudio107/craft3-cookies) or if you have Craft 2, it's available [here](https://github.com/nystudio107/cookies)
Answers.UserDisplayName: Ian O'Brien
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-10-18T22:16:56.227Z
Answers.LastActivityDate: 2016-10-18T22:16:56.227Z
Answers.UserDisplayName: Ian O'Brien
Body: <p>This is happening for all users and only on production environment. </p>
  
  <p>"Your session has ended. Enter your password to log back in."</p>
  
  <p>Entering your password does not allow you to actually see the admin panel again.</p>
  
  <p>Things we have tried:</p>
  
  <p><li>Deleting the contents of <code>craft/storage/runtime</code>
  <li>Removing all rows from <code>craft_sessions</code> in db
  <li>Setting <code>'overridePhpSessionLocation' =&gt; false</code>
  <li>Setting <code>'requireMatchingUserAgentForSession' =&gt; false</code>
  <li>Setting <code>'userSessionDuration' =&gt; false</code>
  <li>Setting <code>craft/app/</code>, <code>craft/storage</code> and <code>craft/config</code> as <code>CHMOD 774</code>
  <li>Changing <code>craft/</code> folders to be owned by <code>www-data</code>
  <li>Setting <code>session.auto_start = 0</code></p>
  
  <p>Our environment is PHP 7 with Ubuntu 16.04 running Apache 2.4.18</p>
  
  <p>Something to consider is we run with an Akamai CDN cache that is set to ignore our entire <code>/admin</code> directory, but my suspicion is that something elsewhere is getting cached. Thoughts about that? Is there another directory we should be ignoring?</p>
  
  <p>Also as a point of info, our <code>/craft</code> folder is above the <code>docroot</code> so not publicly accessible and therefore unlikely to be cached.</p>
  
  <p>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.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-10-13T17:46:01.000Z
Comments.Text: 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?
Comments.UserDisplayName: Brad Bell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-10-13T18:51:43.547Z
Comments.Text: @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.
Comments.UserDisplayName: Ian O'Brien
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-10-13T19:47:32.847Z
Comments.Text: Are you on a load-balanced web server setup, by chance?
Comments.UserDisplayName: Brad Bell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-10-13T19:57:57.270Z
Comments.Text: No load-balancing currently.
Comments.UserDisplayName: Ian O'Brien
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-10-13T20:28:15.583Z
Comments.Text: If you make sure you're not logged in, you should have a CraftSessionId cookie in your browser. If you reload the page, does its value change?
Comments.UserDisplayName: Brad Bell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-10-13T20:38:55.280Z
Comments.Text: Not logged in, refresh page and `CraftSessionId` does not change. On login, `CraftSessionId` changes. Page refresh while logged in,  `CraftSessionId` doesn't change.
Comments.UserDisplayName: Ian O'Brien
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-10-13T20:50:24.230Z
Comments.Text: When you log in, you get an "identity" cookie with a really long random string for its name.  If you refresh when logged in, does that cookie's value change?
Comments.UserDisplayName: Brad Bell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-10-14T13:32:13.973Z
Comments.Text: The cookie name and value don't change on refresh, going to another page, or logging out and logging back in.
Comments.UserDisplayName: Ian O'Brien
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-10-14T16:26:18.673Z
Comments.Text: ``we run with an Akamai CDN cache that is set to ignore our entire /admin directory`` Did your setup ever work properly? This is where I'd start. Is Akamai doing any kind of page caching for you?  My guess is your CDN is stripping cookie values—or hanging onto them— on the front end somehow which is causing Craft to try and reauth your session after a period of time. It would be nice if Craft didn't use CraftSessionId as well for auth so if a page author was logged in, you can check that separate "author" cookie and ignore any caching while on the site.
Comments.UserDisplayName: RitterKnight
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-10-14T17:47:30.083Z
Comments.Text: @RitterKnight if we've already ignored the `/admin` directory, any ideas what else we should ignore? As I understand it, the other system files aren't being cached at all. Is there another directory we should be ignoring?
Comments.UserDisplayName: Ian O'Brien
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-10-14T18:40:33.410Z
Comments.Text: 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.
Comments.UserDisplayName: RitterKnight
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-10-14T20:51:04.460Z
Comments.Text: Curious, if the `/admin` is not cached but the main website **is** cached, would that cause conflicts with how Craft handles sessions?
Comments.UserDisplayName: Ian O'Brien
Tags: <control-panel><error-message><session>
Title: Getting error "Your session has ended. Enter your password to log back in." every 30 seconds or so
ThreadText: # Getting error "Your session has ended. Enter your password to log back in." every 30 seconds or so
  
  (Asked by: username_0 on 2016-10-13)
  
  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.
  
  **Tags:** control-panel, error-message, session
  
  > **Comments:**
  > **username_1**: 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?  
  > **username_0**: @username_1 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.  
  > **username_1**: Are you on a load-balanced web server setup, by chance?  
  > **username_0**: No load-balancing currently.  
  > **username_1**: If you make sure you're not logged in, you should have a CraftSessionId cookie in your browser. If you reload the page, does its value change?  
  > **username_0**: Not logged in, refresh page and `CraftSessionId` does not change. On login, `CraftSessionId` changes. Page refresh while logged in,  `CraftSessionId` doesn't change.  
  > **username_1**: When you log in, you get an "identity" cookie with a really long random string for its name.  If you refresh when logged in, does that cookie's value change?  
  > **username_0**: The cookie name and value don't change on refresh, going to another page, or logging out and logging back in.  
  > **username_2**: ``we run with an Akamai CDN cache that is set to ignore our entire /admin directory`` Did your setup ever work properly? This is where I'd start. Is Akamai doing any kind of page caching for you?  My guess is your CDN is stripping cookie values—or hanging onto them— on the front end somehow which is causing Craft to try and reauth your session after a period of time. It would be nice if Craft didn't use CraftSessionId as well for auth so if a page author was logged in, you can check that separate "author" cookie and ignore any caching while on the site.  
  > **username_0**: @username_2 if we've already ignored the `/admin` directory, any ideas what else we should ignore? As I understand it, the other system files aren't being cached at all. Is there another directory we should be ignoring?  
  > **username_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.  
  > **username_0**: Curious, if the `/admin` is not cached but the main website **is** cached, would that cause conflicts with how Craft handles sessions?  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2016-10-18. Score: 3 | Accepted answer
  
  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.
  
  > **Comments:**
  > **username_3**: 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.  
  > **username_0**: Hey @username_3 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](https://github.com/nystudio107/craft3-cookies) or if you have Craft 2, it's available [here](https://github.com/nystudio107/cookies)  
  
  ---
  
  