The following warnings occurred:
Warning [2] Undefined variable $unreadreports - Line: 26 - File: global.php(961) : eval()'d code PHP 8.2.25 (Linux)
File Line Function
/global.php(961) : eval()'d code 26 errorHandler->error
/global.php 961 eval
/printthread.php 16 require_once
Warning [2] Undefined property: MyLanguage::$archive_pages - Line: 2 - File: printthread.php(287) : eval()'d code PHP 8.2.25 (Linux)
File Line Function
/printthread.php(287) : eval()'d code 2 errorHandler->error
/printthread.php 287 eval
/printthread.php 117 printthread_multipage



UserSpice
User Sessions, expire time - Printable Version

+- UserSpice (https://userspice.com/forums)
+-- Forum: Support Center (https://userspice.com/forums/forumdisplay.php?fid=23)
+--- Forum: UserSpice 4.3 and Below (https://userspice.com/forums/forumdisplay.php?fid=26)
+--- Thread: User Sessions, expire time (/showthread.php?tid=259)

Pages: 1 2 3


User Sessions, expire time - aseiras - 09-12-2016

Hi,

I'm not sure if this is a bug or a feature,
.- I do not see a way to set logout time (after x minutes idle, for instance)
.- I do not see a way to setup session method (i see the users_session table, but nothing get's written there after login.
.- After 24 hours of login in, a user is still able to get into an old page and continue working.

Can you comment something about this?
I love the platform but I have to make it secure, and people should not be allowed to continue working after 7 minutes inactive, (force login again) .


User Sessions, expire time - mudmin - 09-12-2016

You are right. Currently you are logged in until you logout or kill your cookies. It has always been that way, but we are going to put a place to put in a timer so that the cookie/session expires. Thank you for reminding me of this.



User Sessions, expire time - aseiras - 09-12-2016

Thanks Smile

furthermore, does the table do anything?

I see the sessions still been saved on my filesystem and nothing written to table.


User Sessions, expire time - mudmin - 09-12-2016

Actually no...it was there for compatibility with usercake. The plan has always been to re-use it.



User Sessions, expire time - mudmin - 09-12-2016

I'm building the social logins now for 4.2 so I'm learning how google and fb do it and we will probably go in the same direction


User Sessions, expire time - aseiras - 09-12-2016

Thanks for your prompt replies.

In the world I move, social logins are not acceptable (healthcare industry), so I have made this little modification to your init.php page, right after session_start();

if (isset($_SESSION['LAST_ACTIVITY']) && (time() - $_SESSION['LAST_ACTIVITY'] > 210)) {
// last action by user was more than 7 minutes ago
session_unset(); // unset $_SESSION variable for the run-time
session_destroy(); // destroy session data in storage
}
$_SESSION['LAST_ACTIVITY'] = time(); // update last activity time stamp

with this I will be sure that my users session is destroyed after exactly 7 minutes, adding this option (select time to log out users) into the framework could be doen very easy during the setup process.

Again, thanks for the great framework Smile


User Sessions, expire time - mudmin - 09-12-2016

Thanks for the idea of putting it there. We are definitely building that feature.

Of course, Social logins will be available to be turned off.



User Sessions, expire time - brian - 09-12-2016

Yup definitely a good call, thanks for pointing that out.


User Sessions, expire time - brian - 09-13-2016

Just being pedantic...the above code with session_unset() and session_destroy() will make the session unavailable on the next page load. We would need a Javascript timer or something of the sort to actively check if the session timeout has been reached. However, I think that adds some complexity that I'm not sure will bring benefits. Also, the Javascript can be disabled if someone were nefarious enough.


User Sessions, expire time - brian - 09-13-2016

I have uploaded my patch here:

http://pastebin.com/E6QtikxN

The text is put just before ob_start() near the bottom of init. I had to add the $user->isLoggedIn() check to the conditions so that it would only reset things for when a user is logged in. Otherwise if it "times out" when a user is not logged in, and you try clicking on a secure page, it just does the redirect. The reason for the redirect is to ensure there is a page reload immediately after the session is unset so things stay "in sync"...or at least, that's how it makes sense to me.