Jump to content

Being logged out of admin after a short session - a new phenomena


BooJewels
 Share

Recommended Posts

Good morning.  My old CC3 store used to log me out of Admin after a set period of inactivity and I simply got used to working with it, albeit annoying if I'd just typed up a long product description etc. But when Al helped me upgrade to the new CC6, I found I remained logged in as Admin and this was a joy, as I could work with impunity, knowing I wouldn't lose work by getting logged out mid-task.  As I work alone, security of an open browser window wasn't an issue.

But about a month ago, something changed and I now get logged out after a short period of time - something like 30 minutes I think.  I hadn't changed anything and it happens on all platforms (Win7 desktop, Android tablet etc.) and all browsers etc. so this would suggest it's something beyond my immediate control, on the server, that has changed.

Can you give me some pointers as to where to look, so that I might be able to extend the logged in time please? 

From my dashboard:

CubeCart Version   6.0.11
PHP Version   5.3.29
MySQL Version   5.5.55-cll
Server Software   Apache
Link to comment
Share on other sites

Thanks Al, but I have absolutely no idea where that file is or how to edit it.  I've done a search of the server and phpMyAdmin, but can't see any reference to it or the setting you mention.  Can you give me an idiots guide to find it please.  I apologise for my stupidity and lack of understanding.

The php Info page shows the loaded configuration file as /usr/selector.etc/php.ini  - but none of those directories show in the area I can access.

Link to comment
Share on other sites

If it is related to gc maxlifetime, then the setting is called session.gc_maxlifetime, which is a setting in the PHP config on the server, you may not have access to this, as it has to be performed at OS level. Maybe your hosting provider might be willing to change this on your hosting plan.

If you look in cart PHP info, you should find 2 settings. One will be 604800 (7 days) the other 1440 (24 minutes)

It seems for what ever reason, the master setting of 24 minutes is taking precidence over the local setting of 7 days.

Maybe this is also occuring with other local vs master settings, and quite possibly something which has come about with a PHP update.

Something we discovered last week.

 

I'm not sure of the long term fix, Al would have a better understanding of this.

 

It seems that it may be possble to set this in .htaccess

https://stackoverflow.com/questions/6253498/declaring-session-max-life-time-in-htaccess

However, I did mine at OS level, so never tried with .htaccess

 

 

Edited by keat
Link to comment
Share on other sites

Many thanks keat.  On the Admin page 'PHP Info', under Session, I can see session.gc_maxlifetime    604800    1440 - and 24 minutes does sound about right for the time the Admin log in sessions are lasting - I'd need to test it more thoroughly to be sure of the actual time.

I haven't yet found anything in phpMyAdmin where I can see that this setting could be edited.  I might have to contact the hosts, see if they could change it for me.

Link to comment
Share on other sites

Thanks, I'll create a support ticket with the host and see if they can help extend the time. 

At the moment I can't even ascertain what the session time limit is - because it's obviously down to inactivity and if you try a page change or something to see if you're still logged in, if you are, that presumably re-sets the clock.

Link to comment
Share on other sites

Sessions.gc_maxlifetime is garbage cleanup.

If a session has been left open and untouched for 1440 seconds (24 minutes) it's deemed by PHP to be garbage and is then deleted.

However, 24 minutes is not hard and fast as the deletion is done by another process which runs as a schedule.

In my case 24 minutes, turns out to be about 40.

 

Cubecart appears to be telling PHP to use 604800 (7 days), but for whatever reason, PHP is ignoring this and using the master setting of 24 minutes.

This also has me wondering if other local settings are being ignored.

 

I have a thread running on the Cpanel forum, which may or may not turn in to a support ticket.

https://forums.cpanel.net/threads/session-gc_maxlifetime.606031/

 

 

 

 

Link to comment
Share on other sites

My hosts increased the time to 604800 of the Master Value of session.gc_maxlifetime in the php.ini my shop was using (I can see the change on the php info page in Admin) and unfortunately that hasn't fixed the short session log in time for Admin.

As you say keat - the time does seem to vary - yesterday it seemed around 15 minutes on one occasion and probably over an hour another time - so my feeling is that it's averaging around 30-40 minutes - my very loose testing would suggest that it's certainly not a precisely fixed time.  From your description, that would suggest it happens when the session meets the criteria of two schedules simultaneously.

Link to comment
Share on other sites

Both Al and myself are now wondering if a script on another domain could affect this.

 

 

eg, sessions are stored on the server in a central location, possibly along with other sessions from other domains (as is the case for certain on my server).

What happens if a script triggers the garbage clean, how would it identify which sessions to clean and which to remove.

So changing the setting on your domain, may not have any impact if your sessions are stored along with everyone elses.

something else on the server could send the instruction to perform a clean up.

I have my own server, so changing the setting was a global server wide setting for me, which could explain why mine now works.

I'm certainly no expert in this area, so it might be worth watching the Cpanel thread (posted above) and see what they have to say.

see Als comments regarding domain x and Y

Hopefully we'll have an answer in a few days.

 

Edited by keat
Link to comment
Share on other sites

My hosts are perplexed too. 

One thing they suggested was that they found this somewhere in an error file:  "PHP Warning: Stored session data did not match DB record. Session aborted as possible session hijack."  It then gave different IP addresses - none of which were mine - and were based in the US.  They were also using different user agents from mine. 

So maybe that is another legit user on another domain trying to log in to their account and kicking me out in the process?

Link to comment
Share on other sites

The reply from Cpanel indicates that this may require further config changes at server level.

 

Thank you for the additional information. The behavior you noticed is by design. The "/usr/local/cpanel/scripts/clean_user_php_sessions" script will only recognize the global "session.gc_maxlifetime" PHP configuration value configured for each version of PHP. If a custom value for "session.gc_maxlifetime" is preferred for an individual account, then the workaround is to also configure a custom "session.save_path" value for the account. This will allow PHP to handle the session cleanup, as opposed to the "/usr/local/cpanel/scripts/clean_user_php_sessions" script.

 

In other words, the server by default will probably have sessions.gc_maxlifetime configured for 1440 seconds as it's master value.

The cleanup script looks at this mater value for it's basis of when to perform the job.

Changing the master value on your domain will have no effect, as it's still looking at the master value on the server.

As my server is our own, I can change this master value server wide.

 

Link to comment
Share on other sites

Yes, I saw that last night, but it's now getting beyond my own ability to understand or act upon. 

What no one has yet answered is that this is a new phenomena - I wasn't getting regularly logged out a few weeks ago and now I am, so something clearly changed in an upgrade of something - I think I can pin it down to week commencing 12th June in my case, as I was dashing to get all my orders out before I went on holiday that weekend and didn't have the time to look at it further then.

It's irritating that it's happening to me as Admin - but 24 / 40 minutes whatever isn't long enough for customers - if they get distracted half way through an order.  I regularly put stuff in carts to return to and it's very annoying when a cart empties.  So I hope that customers aren't being lost due to this.  I need to test that on my own shop as a customer.

Link to comment
Share on other sites

The issue I have is that some of my customers will use the cart as a live ordering system, keep coming back to it throughout the day and adding items as and when they sell them, not committing to order until the end of the day.

This is OK if they close their browser as CubeCart should save the cart contents. However, leave the window open and this garbage clean up takes effect, deletes the session, which results in an empty cart, I guess CubeCart then saves the empty cart. I had one customer two weeks ago lose a cart with about 100 items, he's not been back since.

I beleive CPanel have said that this is a feature of Cpanel version 64, however version 64 isn't new and I've been having the above issue for well over a year. Only last week did we discover what the cause was.

Unless your host only performed the update in June (unlikely)

It might not be a bad idea to go back to your host and ask if they've updated anything in the last 6 weeks, as any additional info we can find may help.

Also, they may have a trick up thier sleeve to fix this, maybe explain to them you beleive sessions.gc_maxlifetime is using a server wide setting of 1440 seconds, can they do anything to resolve this. Cubecart is asking for 604800 seconds (7 days), but the server is ignoring this.

I know that Al is looking in to this, but it may be beyond his control being a server setting, I wonder how many other carts and the like are affected. Something I might have a tinker with tomorrow.

 

Incidentally, it's also gone beyond my ability.

Link to comment
Share on other sites

I have asked the hosts if they changed anything and gave them the week that I think the issue started for me.  Having asked the question in more than one message, they didn't choose to answer that detail.  They think the issue is with the cart and suggested that I take it up with the developers.

Thankfully, the nature of my shop is that most customers only order on average a couple of items at a time, so the cart emptying won't be as big an issue for me as it obviously is for you - but as you illustrated, an irritated customer is not a returning one.  I like to think that I've set up my shop with care, to give customers the best possible experience (and thorough details about what they can expect of me, the service and the products), so I don't like to think that anything doesn't run optimally.

ETA:  I was going to see if there was a more definitive explanation crop up before going back to the host to see if they could help further - at the moment we're just speculating as to the cause.

Edited by BooJewels
Addition
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...