Thread

I have a client site with a member area. Everything is working great except that users don’t get logged out after quitting their browser. They do get logged out when choosing the Logout link. However, the client would like the logins to automatically expire when quitting the browser and after a specified period of time. What is the standard time frame for cookie expiration? And how can I go about implementing this? Thanks.
Using EE 2.2.1

Hi DavidG,

Are you using the “cookies only” in Admin-> Security and Privacy-> Cookie Settings ? Are you seeing this behavior on the user side or in the Control Panel? Do you have the “auto login” option enabled on the user login form?

If you are allowing users to be “remembered” the cookies will not expire for quite some time. By design, browsers do not destroy cookies when they are quit. Have a look in the User Guide for {if auto_login} for more clarification. Is there anything else we can assist you with?

Cheers,

Having the same exact issue here. Running EE 2.2.2, have User Session Type set to cookies only.

auto_login is NOT set using the login form, so one would expect to be auto logged off when closing the browser, otherwise what is the auto_login for?

expressionengine/modules/member/mod.member_auth.php#249 does not execute, hence auto_login == false.

Workaround / solution? I consider this a serious issue.

I think you’d have to use session only, there’s no way for EE to affect a cookie on the user’s browser and to know that the browser was closed.

Thanks Rob!

I do however use my own auth system with codeigniter, and you can set a cookie to be only valid for a browser session. What happens is the session expires is not set for the cookie, and hence only exists for the current browser session.

Probably in the case of EE it handels the user auth in the “regular” session, and this does have an expire date.

I’ll try “session only” as a workaround, let’s see what it does with segment variables and if it will play nice with safecracker. You probably have the anwser to at least the last 😊

One more thing to try, in your config file, set user_session_ttl to 0.

$config['user_session_ttl'] = 0;

If that actually works (I’ve never actually done this, but glancing at the source code…), the cookie should expire when the browser is closed.

Thanks for the suggestion Rob! I’ve tried that but it doesn’t work.

$u_item = $this->EE->config->item('user_session_ttl');
$this->user_session_len = ($u_item) ? $u_item : $this->user_session_len;

0 or false will return the default (7200). If I set it to one, you immediatly get logged out. Funny thing is, the time doesn’t get incremented with every request. So if your working more then 2 hours, your gone.

See attachement, it defaults to 2 hours. The tracker however has a cookie that is only valid for the current session, which is what you’d also expect for the session cookie.

Bummer. I thought that might work, but that conditional kills it.

Unfortunatly it does, I’ll try to hack something. But my postion is still the same on this. To me it’s a serious bug. Are you able to replicate this Rob?

It might still be a user error, I can’t replicate this with expressionengine.com. Hopefully someone from Ellislab can shed some light on this.

—- EDIT: disregard this comment, it was meant for another thread——-

We had the same issue and in our case it was a matter of dynamic ip addresses in the clients network.  Every 10 minutes they switched.
After some digging around we ended up in the function fetch_session_data.  Regardless of your settings to require an ip address or not, it will try to match it with the one stored in the database.  Of course, when the ip switches, you get thrown out of the CP.

On line 700 of system/expressionengine/libraries/Session.php you will find the check for ip in the fetch session data function.  In the end we ended up commenting that one and that solved our issue.

public function fetch_session_data()
    {
        // Look for session.  Match the user's IP address and browser for added security.
        $this->EE->db->select('member_id, admin_sess, last_activity')
                     ->where('session_id', (string) $this->sdata['session_id'])
                     ->where('ip_address', $this->sdata['ip_address'])
                     ->where('user_agent', $this->sdata['user_agent']);

If only the inline documentation of the session class would do as supposed to….
(I’ve set it Cookies & Session ID, and still the same results)

ExpressionEngine User Classes (* = current):

  1. Session*
  2. Authentication
  3. Permissions

There are three validation types, set in the config file: 
 
  1. User cookies AND session ID (cs)
        
    This is the most secure way to run a site. Three cookies are set:
    1. Session ID - This is a unique hash that is randomly generated when 
                    someone logs in.
    2. Password hash - The encrypted password of the current user
    3. Unique ID - The permanent unique ID hash associated with the account.
    
    All three cookies expire when you close your browser OR when you have been 
    inactive longer than two hours (one hour in the control panel).
    
    Using this setting does NOT allow 'stay logged-in' capability, as each 
    session has a finite lifespan.

  2. Cookies only - no session ID (c)
    
    With this validation type, a session is not generated, therefore
    users can remain permanently logged in.
    
    This setting is obviously less secure because it does not provide a safety net
    if you share your computer or access your site from a public computer.
    It relies solely on the password/unique_id cookies.

  3. Session ID only (s).  
    
    Most compatible as it does not rely on cookies at all.  Instead, a URL 
    query string ID is used.
    
    No stay-logged in capability.  The session will expire after one hour of 
    inactivity, so in terms of security, it is preferable to number 2.
    
    NOTE: The control panel and public pages can each have their own session preference.
*/

*bump*

Can someone from Ellislab please have a look at this issue, or at least confirm it has been read?

I can easily reproduce this, the cookie does not expire. I tried this on a clean EE2 install; no addons installed what so ever.

Reproduce

Template group with 3 templates:

index
login
test

Both test and index have access set to deny guests and show the login form instead.

When logged out I cannot access index/test and am shown the login template. After login in I can access both index/test. So far so good.

Result:
After closing and reopening the browser I can still access the “secured” templates. I have set “User Session Type” to Cookies & Session ID but also tried the other options.

Expected result:
Having to log in again

Hi Jeroen,

I’m sorry you feel like you were abandoned over the weekend. As you know, we only have a limited support staff on weekends, so we definitely aren’t trying to ignore you.

I just wanted to update this thread to let you know that I’ve reviewed this thread, I am able to confirm that sessions do not work as described in the inline documentation when sessions are set to “Cookies and Session ID”, and I’m working on getting you a fix.

David, it looks like this is the same issue for you, and I wanted to make sure you knew we haven’t forgotten you either.

I’ll update this thread when we’ve got something for you both.

Hi Kevin,

Thanks for the update. I didn’t think you guys where ignoring me on purpose, no worries about that. I was just a little upset because I did see other threads updated and to me this is a core security function that should work as advertised. Also the pressure of client work doesn’t help 😊 

Anyway, I’m really glad you are able to reproduce the issue and even happier you are cooking up a fix.
You are probably can guess my next question 😊 Any timeframe?

Thanks again for the explanation, and eagerly waiting for the fix.

p.s. I will take up with Leslie about the Enterprise support he noted in the e-mail.

We were trying to get it squared away today, but it’s taking more time than we’d hoped.  (At first and second glance, I thought the ttl config settings would do the trick).  Somewhere between the authorization lib and the sessions lib, (or possibly reset cookie) it’s not handling a 0 expiration like you’re needing it to.  It’s not new behavior, but it is something we’d have liked to addressed in the new auth lib.

Anyway- long way of saying hopefully we’ll make faster progress in the morning.  Code isn’t that complex- so not sure why I’m not spotting it right off the bat.  But I’m not.  It’s hiding somewhere in there in a very sneaky manner.

Will update once it’s narrowed down!