Forums » SEPHP Help and Tips

Extend Session Time

    • 31 posts
    April 25, 2018 4:47 PM EDT

    We have had many complaints from members on the need to login several times throughout the day. We would like to extend the session time.

    I understand this is not able to be changed from the admin panel. Can someone provide some direction on where this can be viewed and possibly changed in the source code?

    Thanks in advance.

  • gs
    • 861 posts
    April 25, 2018 5:37 PM EDT

    Are they closing their browser tabs?  I've never experienced this even after several hours of non-use, as long as I leave at least one browser tab logged-in.  In fact, I often leave a tab logged-in to this forum, close the tablet for hours (not powered off), and when I return (often the next day), I'm still logged-in (but other times I'm no longer logged-in, so I haven't determined the consistency yet)

     

    So I too am curious about how/where this is configured.

    • 31 posts
    April 25, 2018 5:49 PM EDT

    Over 60% of our user traffic is mobile. I'm guessing our users are visiting our site, going somewhere else, and coming back to the site later on. When they do they are required to login again. This is the issue we are trying to resolve.

    • 373 posts
    April 25, 2018 6:14 PM EDT

    I am interested in a solution for this as well

    • Moderator
    • 4691 posts
    April 26, 2018 5:11 AM EDT

    As this would be a huge security issue, it's not something I'll look at the code to give tips. For our standpoint, all we can do is warn against such changes. In any script, having a session expire is secure. Changing the session expiry, or making it last forever, is a bad idea as it can lead to hacks. 

  • gs
    • 861 posts
    April 26, 2018 8:56 AM EDT
    Isn't allowing an unlimited # of concurrent logins per User also a potential security risk (yet that is allowed by default)?

    1. ADMINs should be able to decide their own risk level (once again, not a decision for a software dev 2 make for a client)
    2. What if the question was how to shorten the session time, i.e. 'reduce' risk - would the information then be provided?

    Not being difficult here, but open/honest as ADMINs should have the info they need to manage their own site how they wish.
    • 31 posts
    April 26, 2018 9:24 AM EDT
    We are not necessarily looking to change it. Or prevent them from not expiring all together. We are simply looking to find out where this is so we can see what it is currently set at and be able to make a business decision on how to proceed.
    • Moderator
    • 4691 posts
    April 26, 2018 11:44 AM EDT
    gs said:
    Isn't allowing an unlimited # of concurrent logins per User also a potential security risk (yet that is allowed by default)? 1. ADMINs should be able to decide their own risk level (once again, not a decision for a software dev 2 make for a client) 2. What if the question was how to shorten the session time, i.e. 'reduce' risk - would the information then be provided? Not being difficult here, but open/honest as ADMINs should have the info they need to manage their own site how they wish.

    There is a feature request for the unlimited concurrent user feature.

    Yes, admins can choose to do what they want. We will NOT provide the code for those modifications. Noting that our support policy is NOT to assist with customizations and that when I do provide code tips, it is at our discretion as stated in the support policy. Feel free to edit whatever you would like. We will NOT be responsible for the outcome should you get hacked if changing this. We already said the possible vulnerability you would create. I already saw, first hand, what can happen when sessions get hacked due to browser vulnerabilities. Not in SE, in another script. It wasn't fun. It was due to something in an ad. That allowed the hacker to grab the current session and then hack into the site. 

    • Moderator
    • 4691 posts
    April 26, 2018 11:46 AM EDT
    CNDAdmin said:
    We are not necessarily looking to change it. Or prevent them from not expiring all together. We are simply looking to find out where this is so we can see what it is currently set at and be able to make a business decision on how to proceed.

    I'm not sure where it is as I've not looked into this. There is a feature request to allow admin to determine the session duration. I would assume to check the user module or authentication area? I'm sorry but due to the nature of this sort of hack, it's not something I'm comfortable looking into. Normally, I provide tips when I can. For things that can create vulnerabilities, it's just not something I can spend time on. I hope you find your solution.

    • 373 posts
    April 26, 2018 2:21 PM EDT

    What is the current time out for a session?

    • 53 posts
    April 27, 2018 1:45 AM EDT

    From what I can tell, most of the issues people are experiencing are based on server config issues. This could be something like php.ini has a short session time, or it could be even an apache/nginx/lighttpd issue. If you are using a hosting provider and not in full control of your server you will need to speak to them. 

    Generally speaking, with the right server config, the ONLY time people should need to login is if they close their browser. Session login is very common and should NEVER be changed. Using what SHOULD be an extreme situation but is all too common is someone who uses the iOS/MacOS eco system. If you were to change the timeout from session to X time, this would mean that if a user were to login on one device and you had the login time set to 24 hours, then the other device would automatically be logged in as well. 

    Do NOT change this. If you value your members and their data, DO NOT CHANGE THIS PLEASE!

    • 53 posts
    April 27, 2018 1:49 AM EDT

    Side note, if you do run your own server/cluster - you should be setting php.ini to use a REDIS server for session AND DB caching. You should also be using opcache/apc for server caching as well. Finally, you should also offload your static content (images, videos, css, externals) to a CDN. A lot of minimal cost tuning can save you lots of load time and improve the customer experience so the login time alone is reduced by 40-70%.

    (if this is ok with you SE) - I do offer SE hosting on a custom nginx cluster protected by a full CDN and static uploading. I can also help you build your own web cluster if you want help. I am NOT endorsed or promoted by SE, but I have been an SE user and developer for many years now and have learnt a LOT of lessons, some of them the hard way to make SE load quickly (example, I have 50,000 users on one site with a page load time under 2 seconds).

    • Moderator
    • 4691 posts
    April 27, 2018 4:58 AM EDT
    FM Ryan said:

    Side note, if you do run your own server/cluster - you should be setting php.ini to use a REDIS server for session AND DB caching. You should also be using opcache/apc for server caching as well. Finally, you should also offload your static content (images, videos, css, externals) to a CDN. A lot of minimal cost tuning can save you lots of load time and improve the customer experience so the login time alone is reduced by 40-70%.

    (if this is ok with you SE) - I do offer SE hosting on a custom nginx cluster protected by a full CDN and static uploading. I can also help you build your own web cluster if you want help. I am NOT endorsed or promoted by SE, but I have been an SE user and developer for many years now and have learnt a LOT of lessons, some of them the hard way to make SE load quickly (example, I have 50,000 users on one site with a page load time under 2 seconds).

    It's ok for you to do hosting, I do hosting. We don't allow advertising without payment though so please don't put links or contact details.  

    Thanks for the great info!

    On a side note - SocialEngine PHP is not supported on nginx so if anyone uses it, you're on your own if you need support.  

    • 373 posts
    April 27, 2018 11:49 AM EDT

    Great info Ryan - thanks!

  • gs
    • 861 posts
    May 11, 2018 6:06 PM EDT

    (deleted post)


    This post was edited by gs at May 11, 2018 8:09 PM EDT