session_cookie_lifetime broken?

Hope someone can help here..

I’ve changed the session_cookie_lifetime system setting to 20 mins (1200), but it isn’t working..

If I leave myself logged in overnight, I can still access it in the morning without logging in again!

I’m running Revolution 2.0.0-pl rev7212, maybe this is a bug that’s been fixed?

Will upgrade now which may hopefully fix the issue, but anyone else experience this issue or know of a fix?

Thanks,
Toby

Just upgraded to revolution version 2.0.4-pl2, put the session_cookie_lifetime to 600 and worked on something else..

Coming back over an hour later still logged in!

PHP Version 5.2.14
MySQL 4.1.22 standard

Can anyone confirm if this is a bug?

Thanks,
Toby

I don’t know if this is a bug... but session settings often can have something to do with PHP’s session settings.... so even if it’s a bug it might have something to do with your server’s session settings... </random thinking out loud>

I changed the session_cookie_lifetime System Setting to 60, logged out (to clear my current session cookie which lasts for 7 days), logged back in, waited 60 seconds and tried to click a menu item. Bam, login page.

IOW, no, I cannot confirm this bug. But make sure you log out after you make configuration changes like that; existing session cookies are in the browser until you log out, and that setting only affects how the expiration is set on new cookies when you change it.

Thanks for the feedback guys, unfortunately I’m unable to replicate the scenario you describe OpenGeek.

I put the session_cookie_lifetime down to 30 seconds, logged out and then logged in, waited over a minute and could still navigate around. Tried flushing permissions and flushed all sessions, still no joy.

Its not working for me in both the mgr context and for resource groups in the web context, so I now assume it must be a PHP setting on our Linux server, although I’ve never had problems with this before.

Here’s a dump of the SESSION settings from Phpinfo:

Session Support enabled
Registered save handlers files user sqlite
Registered serializer handlers php php_binary

Directive Local Value Master Value
session.auto_start Off Off
session.bug_compat_42 On On
session.bug_compat_warn On On
session.cache_expire 180 180
session.cache_limiter nocache nocache
session.cookie_domain no value no value
session.cookie_httponly Off Off
session.cookie_lifetime 1200 0
session.cookie_path / /
session.cookie_secure Off Off
session.entropy_file no value no value
session.entropy_length 0 0
session.gc_divisor 100 100
session.gc_maxlifetime 1200 1440
session.gc_probability 1 1
session.hash_bits_per_character 4 4
session.hash_function 0 0
session.name PHPSESSID PHPSESSID
session.referer_check no value no value
session.save_handler user files
session.save_path /tmp /tmp
session.serialize_handler php php
session.use_cookies On On
session.use_only_cookies Off Off
session.use_trans_sid 0 0

Any further leads greatly appreciated.

Pumping out session_get_cookie_params() I get
Array
(
[lifetime] => 1200
[path] => /
[domain] =>
[secure] =>
[httponly] =>
)
which seems fine as I’ve set it to 20 mins again.

and yet with
print_r($_SESSION) there’s an array var:
[modx.web.session.cookie.lifetime] => 0
which doesn’t look right to me, and what are the differences between
[modx.user..attributes] => Array
[webUserGroupNames] => // this ones empty!
and
[modx.user.2.attributes] => Array
[modx.user.2.userGroupNames] => Array

The cookie lifetime being zero means that you are not checking the rememberme option when logging in; that means the session ends when the user closes the browser.

And those are internal SESSION variables, some legacy, some new, that are used by MODx.

So for the session_cookie_lifetime to work we need to have the rememberme option checked?
Hmm, can I just add this as a hidden variable in the login form me wonders..

Yep that works excellent
Seems a bit counter intuitive having to check remember me to get logged out,
but never mind, now it’s documented.