What is the norm for session login timesouts on remote hosts?? Plz help!
Results 1 to 13 of 13

Thread: What is the norm for session login timesouts on remote hosts?? Plz help!

  1. #1
    Senior Member Paul help!'s Avatar
    Join Date
    Aug 2013
    Location
    Manchester, England.
    Posts
    249

    What is the norm for session login timesouts on remote hosts?? Plz help!

    Hi guys.


    I was just curious.


    Do hosting companies generally tend to have a login timeout limit for websites when a customer either forgets to log out (of there admin area) or if there is a lack of activity once they are logged in?


    The reason I am asking this is because I have built a number of login/logout applications for different customers over the past year and I want to make sure there is some level of security in place if they forget to log themselves out.


    Paul.

  2. #2
    Senior Member cluelessPHP's Avatar
    Join Date
    Apr 2015
    Location
    Scotland
    Posts
    429
    It really depends, if you look at something like Facebook it never times out but this forum does have session timeout coded in, so realistically you should build to the requirements of the client, however have you ever heard of Cross-Site Request Forgery (CSRF) by any chance?
    Once you had a good excuse, you opened the door to bad excuses ― Terry Pratchett, Thud
    Blog

    Six month project

  3. #3
    High Energy Magic Dept. NogDog's Avatar
    Join Date
    Aug 2006
    Location
    Ankh-Morpork
    Posts
    14,842
    You can configure it at the application level, particularly easily if you have a config or other file that is always included first. Then you can set the session cookie timeout to whatever you want, as well as the session data lifetime.

    http://php.net/manual/en/session.configuration.php

    session.cookie_lifetime and session.gc_maxlifetime are the settings of interest.
    "Well done....Consciousness to sarcasm in five seconds!" ~ Terry Pratchett, Night Watch

    How to Ask Questions the Smart Way (not affiliated with this site, but well worth reading)

    My Blog
    cwrBlog: simple, no-database PHP blogging framework

  4. #4
    Settled 4 red convertible dalecosp's Avatar
    Join Date
    Jul 2002
    Location
    Accelerating Windows at 9.81 m/s....
    Posts
    8,493
    It really depends on the site/application.

    My banking site, for example, runs a JS timer, and if you don't do anything (mouseover, link click, scroll, etc.) within 10 minutes it logs you out and send the browser to the home page.

    Contrast that with a growing number of e-commerce sites/apps, for example Newegg, Amazon, etc. They cookie you at login and don't give an option for session length; they actually keep your session open *basically* forever, but require a login for "sensitive" operations (personal settings, payment, account history, etc.). I recall reading about this a couple years ago ... I'll see if I can find a link.
    /!!\ mysql_ is deprecated --- don't use it! Tell your hosting company you will switch if they don't upgrade! /!!!\ ereg() is deprecated --- don't use it!

    dalecosp "God doesn't play dice." --- Einstein "Perl is hardly a paragon of beautiful syntax." --- Weedpacket

    Getting Help at All --- Collected Solutions to Common Problems --- Debugging 101 --- Unanswered Posts --- OMBE: Office Machines, Business Equipment

  5. #5
    Senior Member Paul help!'s Avatar
    Join Date
    Aug 2013
    Location
    Manchester, England.
    Posts
    249
    Thanks guys.


    Is there any way of setting a session timeout through the $_SESSION superglobal?

    If so, can you provide me with some illustration code?

  6. #6
    High Energy Magic Dept. NogDog's Avatar
    Join Date
    Aug 2006
    Location
    Ankh-Morpork
    Posts
    14,842
    Quote Originally Posted by Paul help! View Post
    Thanks guys.


    Is there any way of setting a session timeout through the $_SESSION superglobal?

    If so, can you provide me with some illustration code?
    Nope. $_SESSION is not available (or at least not populated) until after the session_start() has been executed, and you need your session configuration options set before session_start() is called.

    You can either set them in the web host config via the php.ini file, or on Apache, at the directory level via .htaccess. If you want to set in in the PHP code itself, then it has to be done before the call to session_start() (as referred to above), so you might want it in a general config file:
    PHP Code:
    <?php
    $session_time 
    60 60// 1 hour
    ini_set(session.gc_maxlifetime$session_time);
    session_set_cookie_params($session_time'/''.example.com'); // replace with domain
    if(!headers_sent()) {
        
    session_start();
    }
    else {
        throw new 
    Exception('Cannnot start session, headers already sent');
    }
    Then make sure you require that config file in any file that requires session data (including login authentication).

    Caveat emptor: untested code, so beware typos.
    "Well done....Consciousness to sarcasm in five seconds!" ~ Terry Pratchett, Night Watch

    How to Ask Questions the Smart Way (not affiliated with this site, but well worth reading)

    My Blog
    cwrBlog: simple, no-database PHP blogging framework

  7. #7
    Senior Member Paul help!'s Avatar
    Join Date
    Aug 2013
    Location
    Manchester, England.
    Posts
    249
    Thanks NogDog.

    Can I ask?

    Does ini_set() target the php.ini file which is already situated on the host?

    ...... and in order to use: session_set_cookie_params() ..... does the code expect me to have set a cookie myself?

    Paul.

  8. #8
    High Energy Magic Dept. NogDog's Avatar
    Join Date
    Aug 2006
    Location
    Ankh-Morpork
    Posts
    14,842
    ini_set() overrides any system settings -- or for that matter anything else that has set that particular setting. (Note however that not all settings can be overridden by it, but in this case, these can.)

    In normal usage, session_start() sends a cookie and looks for an incoming one (which would have the session ID). session_set_cookie_params() tells session_start() to use its session cookie parameters instead of whatever the defaults would be.
    "Well done....Consciousness to sarcasm in five seconds!" ~ Terry Pratchett, Night Watch

    How to Ask Questions the Smart Way (not affiliated with this site, but well worth reading)

    My Blog
    cwrBlog: simple, no-database PHP blogging framework

  9. #9
    Senior Member Paul help!'s Avatar
    Join Date
    Aug 2013
    Location
    Manchester, England.
    Posts
    249
    Thanks NogDog.

    When you say:

    In normal usage, session_start() sends a cookie and looks for an incoming one
    .... What do you mean by an incoming cookie??

    Do you mean one that has already been set?
    Last edited by Paul help!; 07-16-2017 at 01:02 PM.

  10. #10
    Senior Member
    Join Date
    Apr 2016
    Posts
    121
    As to 'automatically' logging someone out or making a hijacked session id no longer match any session data, DON'T rely on the underlying session garbage collection operation to do this. The session garbage collection has a random probability of running and on a server that has few page requests, the session data could persist for a long time, allowing a hijacked session id to remain usable to impersonate a user.

    Next, to positively log someone out, you need to have an actual data value, stored in the database table holding user data, that gets set to a value that indicates logged in, that gets cleared to indicate the logged out state. You should not rely just on the existence or absence of a session to permit access. By having an actual value stored on the server, it will require someone to enter correct authentication credentials in order to become logged in, which will prevent a hijacked session id from allowing someone to impersonate a user that is in the logged out state.

    Lastly, to 'automatically' log someone out, you need to record the date and time of the last page request of the visitor in a database table, then check on each request if the last request is farther in the past then a value you have picked. If it is, you clear the logged in value stored in the database table, which will result in the visitor, or someone using a hijacked session id, needing to provide correct authentication credentials in order to become logged in.
    Programming should not be a painful activity. If you are experiencing pain while programming, you are probably doing something wrong.

  11. #11
    High Energy Magic Dept. NogDog's Avatar
    Join Date
    Aug 2006
    Location
    Ankh-Morpork
    Posts
    14,842
    Quote Originally Posted by Paul help! View Post
    Thanks NogDog.

    When you say:



    .... What do you mean by an incoming cookie??

    Do you mean one that has already been set?
    Yes: I suggest doing some reading up on cookies in general and session cookies in particular. In very short form: the server sends a cookie with a session ID to the browser with any page that includes a session_start() (in PHP). The browser receives that cookie, does whatever magic it does to remember it, and then sends a copy back with any subsequent HTTP request to that server domain, including that session ID (as long as the cookie has not yet timed out). That's how the server-side script differentiates requests from different session users, (which can include those that have logged onto your site).
    "Well done....Consciousness to sarcasm in five seconds!" ~ Terry Pratchett, Night Watch

    How to Ask Questions the Smart Way (not affiliated with this site, but well worth reading)

    My Blog
    cwrBlog: simple, no-database PHP blogging framework

  12. #12
    Senior Member Paul help!'s Avatar
    Join Date
    Aug 2013
    Location
    Manchester, England.
    Posts
    249
    NogDog.

    Back to your illustration code.

    Wouldn't the following be enough (on it's own) to set a session timeout limit:


    $session_time = 60 * 60; // 1 hour
    ini_set(session.gc_maxlifetime, $session_time);

    Surely setting the 'session.gc_maxlifetime' directive to something else is all that is necessary?
    Last edited by Paul help!; 07-18-2017 at 06:21 PM.

  13. #13
    High Energy Magic Dept. NogDog's Avatar
    Join Date
    Aug 2006
    Location
    Ankh-Morpork
    Posts
    14,842
    It gets a little messy/fuzzy, as the "gc" process only runs when someone causes session_start() to be executed, and then there's a random chance it will or will not run the "garbage cleanup", with that random probability being another session config option. Also, in my experience, it does not clean up the session data of the user who triggered the session_start(), so that can also mess things up a bit. So just in case, I suggest setting both -- it's just one more line of code, and if you put it somewhere in a config file that always gets called, you're good to go.
    "Well done....Consciousness to sarcasm in five seconds!" ~ Terry Pratchett, Night Watch

    How to Ask Questions the Smart Way (not affiliated with this site, but well worth reading)

    My Blog
    cwrBlog: simple, no-database PHP blogging framework

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •