<p>Turns out this was caused by me setting a "Cache-Control: max-age" header which I was testing with Google Page Speed and I forgot to move it. This meant the browser was caching everything including the session cookie. </p>

CC BY-SA 3.0
2015-09-17T21:34:43.680Z
2015-09-17T21:34:43.680Z
Andy
<p>I have a login area on a site which basically just shows a users profile fields. I'm using the {{ logoutUrl }} tag for my logout link and when the user goes to the logoutUrl they're redirected to the homepage however if they visit the profile page URL again, they can still see the content (as if they're logged in) until they do a hard refresh (CMD + SHIFT + R). This seems to be the case in three different browsers. I have tried both of the following to determine if the user is logged in:</p>

<pre><code>{% if craft.session.isLoggedIn %}
</code></pre>

<p>And</p>

<pre><code>{% if currentUser %}
</code></pre>

<p>Both seem to be effective at showing the content once they login but it's as if the session is being cached or something as these tests are still true after logging out. </p>

<p>Note this happens when I either click a link to the profile URL or manually type it in the address bar. I am not clicking back in the browser.</p>

<p>Also I have also set a custom path with "logoutPath" in the config but this doesn't seem to be affecting the issue I'm having.</p>

<p>Any help would be greatly appreciated!</p>

CC BY-SA 3.0
2015-08-19T00:40:35.003Z
Maybe some browser or PHP opcache caching going on?  Open your browser's inspector and click on the Resources tab and click on cookies. When you're authenticated, you'll have a cookie with a name that is  random letters and numbers (like 4190d8c6874f8615f88325f5b285fc40). Does that go away when you click logout?
Brad Bell
CC BY-SA 3.0
2015-08-22T09:30:10.423Z
Two really simple things to check. 1. Is the logoutUrl correct? 2. Is the content they're looking at actually behind a {{ requireLogin }} tag?
darylknight
CC BY-SA 3.0
2015-08-24T19:44:20.287Z
@BradBell the cookie seems to stay there, both locally (basic mamp setup) and on my server. When I log out and even when I do a hard reload the cookie "CraftSessionId" remains.
Andy
CC BY-SA 3.0
2015-08-24T19:55:02.060Z
@Andy It's not the CraftSessionId cookie (that's for PHP sessions), it's the one with the name that is random letters/numbers.
Brad Bell
CC BY-SA 3.0
2015-08-24T20:08:25.867Z
@BradBell sorry I misread your comment, I've just checked an the cookie seems to still be set once logged out. Same again with the reload etc. :(
Andy
CC BY-SA 3.0
2015-08-24T20:23:32.400Z
Does the cookie go away when you log out from the control panel?
Brad Bell
CC BY-SA 3.0
2015-08-25T08:54:52.530Z
@BradBell no :( I've been logging into the profile stuff in an incognito window (so I'm not logged into the CP) by the way. But yes the cookie stays when logging out of the CP. It's just bizarre as it's doing it locally and on my server. I've got devmode enabled locally too.
Andy
CC BY-SA 3.0
2015-08-25T15:32:26.903Z
@Andy If you want to send some CP/FTP credentials over to support@buildwithcraft.com and mention this thread, we can take a quick stab at it.
Brad Bell
CC BY-SA 3.0
2015-09-02T14:54:09.900Z
@BradBell sorry for my late reply! I'll email you guys asap. Thanks!
Andy
<users><user-profile><login><session>
User not being logged out when visiting {{ logoutUrl }} link
# User not being logged out when visiting {{ logoutUrl }} link

(Asked by: username_0 on 2015-08-18)

I have a login area on a site which basically just shows a users profile fields. I'm using the {{ logoutUrl }} tag for my logout link and when the user goes to the logoutUrl they're redirected to the homepage however if they visit the profile page URL again, they can still see the content (as if they're logged in) until they do a hard refresh (CMD + SHIFT + R). This seems to be the case in three different browsers. I have tried both of the following to determine if the user is logged in:
{% if craft.session.isLoggedIn %}

And
{% if currentUser %}

Both seem to be effective at showing the content once they login but it's as if the session is being cached or something as these tests are still true after logging out. 
Note this happens when I either click a link to the profile URL or manually type it in the address bar. I am not clicking back in the browser.
Also I have also set a custom path with "logoutPath" in the config but this doesn't seem to be affecting the issue I'm having.
Any help would be greatly appreciated!

**Tags:** users, user-profile, login, session

> **Comments:**
> **username_1**: Maybe some browser or PHP opcache caching going on?  Open your browser's inspector and click on the Resources tab and click on cookies. When you're authenticated, you'll have a cookie with a name that is  random letters and numbers (like 4190d8c6874f8615f88325f5b285fc40). Does that go away when you click logout?  
> **username_2**: Two really simple things to check. 1. Is the logoutUrl correct? 2. Is the content they're looking at actually behind a {{ requireLogin }} tag?  
> **username_0**: @BradBell the cookie seems to stay there, both locally (basic mamp setup) and on my server. When I log out and even when I do a hard reload the cookie "CraftSessionId" remains.  
> **username_1**: @username_0 It's not the CraftSessionId cookie (that's for PHP sessions), it's the one with the name that is random letters/numbers.  
> **username_0**: @BradBell sorry I misread your comment, I've just checked an the cookie seems to still be set once logged out. Same again with the reload etc. :(  
> **username_1**: Does the cookie go away when you log out from the control panel?  
> **username_0**: @BradBell no :( I've been logging into the profile stuff in an incognito window (so I'm not logged into the CP) by the way. But yes the cookie stays when logging out of the CP. It's just bizarre as it's doing it locally and on my server. I've got devmode enabled locally too.  
> **username_1**: @username_0 If you want to send some CP/FTP credentials over to support@buildwithcraft.com and mention this thread, we can take a quick stab at it.  
> **username_0**: @BradBell sorry for my late reply! I'll email you guys asap. Thanks!  

---

## 1 answers

### Answer by username_0 on 2015-09-17. Score: 1

Turns out this was caused by me setting a "Cache-Control: max-age" header which I was testing with Google Page Speed and I forgot to move it. This meant the browser was caching everything including the session cookie.


---

