Problem with session timeout Front End Users

[Freud]

Since I've updated my cmsms to version 1.10 I have a problem with active sessions in FEU.
The number of seconds an inactive FEU-session should expire is 1800.
That works for inactive users, but even active users will be logged out after the 1800 seconds.
I've never had that problem in 1.9-versions and couldn't find anything in the forum.
Any ideas?

Cms Version: 1.10.3
Installed Modules:
CMSMailer: 2.0.2
FileManager: 1.2.0
MenuManager: 1.7.7
ModuleManager: 1.5.3
News: 2.12.3
Printing: 1.1.2
Search: 1.7
ThemeManager: 1.1.4
TinyMCE: 2.9.4
CGExtensions: 1.27.9
CGSimpleSmarty: 1.4.8
FormBuilder: 0.7
FormBrowser: 0.4
FrontEndUsers: 1.17
SelfRegistration: 1.6.14
CustomContent: 1.7.3
CGUserDirectory: 1.3
CMSPrinting: 1.0
MicroTiny: 1.1.1

[Freud]

Am I realy the only one with this problem?!?

I did a fresh install of 1.10.3 and added only the modules CGExtensions (1.27.9) and FrontEndUsers (1.16.. (FrontEndUsers 1.17 I can't get to work properly at all.)

Any user is logged out after the period 'Session Timeout (seconds)' in the prefences-tab, even if the user is active during that period.

The explanation of the Session Timeout-variable says: "Specify the number of seconds before an inactive user is automatically logged out of the website".

I see the module was build by Calguy: Do you have any ideas? Do I have to make a bug-report for this?

----------------------------------------------

Cms Version: 1.10.3

Installed Modules:

CMSMailer: 2.0.2
CMSPrinting: 1.0
FileManager: 1.2.0
MenuManager: 1.7.7
MicroTiny: 1.1.1
ModuleManager: 1.5.3
News: 2.12.3
Search: 1.7
ThemeManager: 1.1.4
CGExtensions: 1.27.9
FrontEndUsers: 1.16.8


Config Information:

php_memory_limit:
process_whole_template: false
output_compression: false
max_upload_size: 50000000
default_upload_permission: 664
url_rewriting: none
page_extension:
query_var: page
image_manipulation_prog: GD
auto_alias_content: true
locale:
default_encoding: utf-8
admin_encoding: utf-8
set_names: true


Php Information:

phpversion: 5.3.3
md5_function: On (True)
gd_version: 2
tempnam_function: On (True)
magic_quotes_runtime: Off (False)
E_STRICT: 0
E_DEPRECATED: 0
memory_limit: 128M
max_execution_time: 60
output_buffering: 0
safe_mode: Off (False)
file_uploads: On (True)
post_max_size: 32M
upload_max_filesize: 50M
session_save_path: /tmp (0777)
session_use_cookies: On (True)
xml_function: On (True)


Server Information:

Server Api: cgi-fcgi
Server Db Type: MySQL (mysql)
Server Db Version: 4.1.21


----------------------------------------------

[Freud]

I've done some more research on this and tested 1.10.3 and 1.9.4.3 with debug=true. Both versions have exactly the same FEU-preferences.

The diference I see in the debug-report is that in the 1.9.4.3-version the lastused-value is updated on every page request:

Code: Select all

(mysql): UPDATE cms_module_feusers_loggedin SET lastused = ### where sessionid = '###'

This is missing in the debug-report of the 1.10.3 version. This explains why the user is logged out when the session timout-period has expired.

I've looked at FrontEndUsers.api.php but can't figure out why the lastused-value isn't updated.

I use the FEU-module on several websites, including the session timeout-parameter, so I realy need a solution for this. Otherwise I can't upgrade to 1.10 for those websites.

[tophers]

Bumping this thread because we're experiencing the same issue here - the session times out at the interval entered, regardless of activity. So if it's set to 60 seconds, you get logged out after a minute, regardless of activity. The client has requested a 15 minute (900 second) session expiry, and it's causing some concern - it's a big site that's entirely password-protected, and 15 minutes isn't very long to remain on the site, especially if you are accessing info on a long page or one within certain modules.

I'm running:
CMSMS 1.11.3
FrontEdnUsers 1.21.2

Any help is appreciated!

[calguy1000]

Although this is an OLD thread, and there isn't enough information for me to glean what the problem is. I will respond. Once, and once only.

FEU can only refresh the users activity IF and when it is called.

So if you have umpteen pages that are public, and only a few pages that are private... and not displaying any information (even the username) on those public pages, then the FEU loggedin info will not be refreshed while the user visits public pages.

Best is to display some information from FEU on all pages (like the username) or to increase the session timeout to a larger number.

[tophers]

I appreciate the reply - I know this one has been lurking around a while. But the issue exists (several tests both here and at the client's confirm it), and I have a few questions regarding the call to FEU. But first to clarify some information:

1) To start, the site is entirely password-protected content, with the exception of the login screen, so it isn't a case of the user not interacting with the site as a logged-in user.

2) However, I do have the logout form called onto every protected page:

Code: Select all

{FrontEndUsers form='logout'}

Now the questions:

1) Is the Logout form considered an active call?

2) With the new (-ish) method of protecting content (Pages > Permissions > Groups), the only time I actively call FEU is on login - is the Permissions call considered an active call?

3) If the answer to both of the above is no, then will form='silent' qualify?

4) Or do I have to display some information on the page about the logged in user in order to have an 'active' call?

Again, I appreciate any responses to this - I could simply increase the logout time, but since I have different categories of users all in one office I want to avoid lengthy session times in case people forget to log out (I know, when would that ever happen!).

[calguy1000]

if your site is 100% protected (other than the login page). And using the new ProtectedContent content type... and your menu template is not cachable... then this should not be occurring.

This is because FEU needs to check the active login id, and group memberships in order to decipher what pages should be shown in the navigation.

[rotezecke]

i had this issue a while back (still do) and managed to reproduce it with a fresh install with minimal modules enabled (but i only have php 5.2).

http://dev.cmsmadesimple.org/bug/view/8769

being no expert, i cannot rule out any wrong doings on my end. i only tested with a single (non cached) page which i kept refreshing until i was logged out again.

as far as i remember, i tested in FF and IE.

there's a thread about IE not handling sessions properly, unrelated but interesting nonetheless

http://forum.cmsmadesimple.org/viewtopi ... =8&t=65482

[tophers]

It does have me stumped - the site is fairly straight-forward, without a lot of extra functionality added on. We do have a script running to check off a User Property (to see if they've reset their password or not on the first visit), but otherwise there isn't much I can see that would interfere with FEU. And there is a menu call on all pages that checks to see if you are a member of Management, and show a menu category based on that:

Code: Select all

{if $ccuser->memberof('Management')}menu call{/if}

But whether or not you a member of that group, you still get logged out after the session interval, regardless of activity level.

Any thoughts on next steps for testing this? I can set up some temporary access if needed.

[tophers]

Still no idea what's going on with my session timeout issue. As an added bonus, on some machines (specifically our Macs here, in Firefox and Chrome), quite often we NEVER get logged out. Just went in to the back end to add some new features, and when I viewed the site to check on them I was logged in. Last time I logged in was yesterday afternoon (well past the hour I have it set to!).

Anyone have any ideas?

[paulbaker]

As an added bonus, on some machines ... quite often we NEVER get logged out.

If website behaviour is different using another machine/browser then doesn't that point to a local problem....perhaps cookies not being remembered?

I have used FEU and the clients have never reported problems. I can test and report back behaviour with Chrome/IE on Windows here if you think it might help.

[tophers]

It's strange - when I test the log out procedure (setting it to a really short time span, for instance) it logs me out at the end of the interval, regardless of activity - the same as the client is experiencing. But when I have it set for longer I've seen it keep me logged in for days on my machine.
I noticed another anomaly - when I change the interval it resets the 'Use cookies to keep logins alive:' to No. I've tested it both ways but haven't seen any difference.

The client is in the process of demoing the site internally, so I have the interval set to an hour again. I appreciate the offer to help test this - if you'd like to do a few tests just let me know and I'll set the interval to something shorter and PM you the login info.

[paulbaker]

Have sent you a PM

[paulbaker]

Well I did some tests with the login you provided and basically it behaved like a "normal" private site on 3 browsers. i.e. If I clicked around I stayed logged in and if I was not active then after a time I was logged out. So it seemed to work OK for me.

Have PMed you with details.

Great looking site BTW

[tophers]

Thanks for the testing (and the kudos!).

It's strange - I left the site open on my machine when I left work last night, and this morning it's still logged in. We'll see if the clock starts ticking again now that I'm actively on the site.

Another though occurred as I was checking the site again - we get 'lazy' here and let the browser remember our login details on sites like this, where we're constantly in and out of the site during development. Do you think that could have anything to do with our staying logged in? It doesn't explain the other behavior (logging us out even when we're active), but might be part of the issue?

Thanks again Paul, and to all of this community that make this my CMS of choice.