PHPSESSID expiration problem

The PHPSESSID expires for N minutes. when the PHPSESSID is refreshed, the logged-on user naturally exits.
The problem is that the cause of PHPSESSID change cannot be found.

Session. cookie_lifetime = 0

Ps:

Ini_set ('session. use_cookies ', 1); // use the COOKIE to save the session ID in ini_set ('session. cookie_domain', 'ABC. com ');

Reply to discussion (solution)

The thinkphp framework 3.23 used

'Session _ options' => array ('type' => 'DB', // SESSION uses the database to save 'expire '=> 7200, // session expiration time, if not set, php is used. default value set in ini), 'session _ table' => 'V4 _ session', // This must be set. if no data TABLE is found without the prefix, note that

The session must be rewritten with session_set_save_handler.
In fact, you set the expiration time for one year, but other users who haven't saved it for one year will trigger the gc of the session and forcibly recycle your session.

Rewrite the following two methods:
1. store redis, mysql, and other databases. you can control the expiration time by yourself.
2. my skill is to force the modification of the session file time to the future time, so that other users will not be able to recycle your session file after triggering gc.

The session must be rewritten with session_set_save_handler.
In fact, you set the expiration time for one year, but other users who haven't saved it for one year will trigger the gc of the session and forcibly recycle your session.

Rewrite the following two methods:
1. store redis, mysql, and other databases. you can control the expiration time by yourself.
2. my skill is to force the modification of the session file time to the future time, so that other users will not be able to recycle your session file after triggering gc.

For stored data, the session follows the cookie. The problem is that the sessid of the cookie has expired, instead of the session has expired.

Session. gc_maxlifetime = 1440; specify that the last access will expire in 1440 seconds.
But whether it is actually invalid depends on
Session. gc_probability and session. gc_pisor ratio (failure probability)

For thinkphp, you have 'expire '=> 7200
It should expire after 7200 seconds (2 hours) of the last access.
If not, give up thinkphp.

Session. gc_maxlifetime = 1440; specify that the last access will expire in 1440 seconds.
But whether it is actually invalid depends on
Session. gc_probability and session. gc_pisor ratio (failure probability)

For thinkphp, you have 'expire '=> 7200
It should expire after 7200 seconds (2 hours) of the last access.
If not, give up thinkphp.

It doesn't matter if the program is stored in the database. 7200 is valid
Because the PHPSESSID value is invalid (a is changed to B), a exists in the database, but B does not exist, so the entire session of the user is quite invalid.

The session on the server is invalid. of course, a sessionid is assigned again when the web page is refreshed.
Session. cookie_lifetime = 0 indicates that the cookie is deleted when the browser is closed, unless it is manually deleted or the cookie is cleared by other software.

I don't know, right? PHPSESSID is uploaded to the client based on the cookie to determine the uniqueness of the user. if the cookie is set to 0 seconds, it will be automatically cleared. the client does not have phpsessid, and the server will certainly allocate another one, so I logged out.

The session on the server is invalid. of course, a sessionid is assigned again when the web page is refreshed.
Session. cookie_lifetime = 0 indicates that the cookie is deleted when the browser is closed, unless it is manually deleted or the cookie is cleared by other software.

The server session is not invalid and the database is saved...
This is because the phpsessid value of coookie has changed, and this phpsessid has no data in the database.

I don't know, right? PHPSESSID is uploaded to the client based on the cookie to determine the uniqueness of the user. if the cookie is set to 0 seconds, it will be automatically cleared. the client does not have phpsessid, and the server will certainly allocate another one, so I logged out.

Yes. The problem is that the system configuration is two hours. sometimes 10 minutes, sometimes the PHPSESSID is re-allocated within one hour (the same page is refreshed all the time)
No reason is found

I don't know, right? PHPSESSID is uploaded to the client based on the cookie to determine the uniqueness of the user. if the cookie is set to 0 seconds, it will be automatically cleared. the client does not have phpsessid, and the server will certainly allocate another one, so I logged out.

Yes. The problem is that the system configuration is two hours. sometimes 10 minutes, sometimes the PHPSESSID is re-allocated within one hour (the same page is refreshed all the time)
No reason is found

It is not difficult to talk about session and cookies. it is simple and easy to talk about. the whole process is perfect. The two companies have to study the cooperation perfectly, but it will save time after the encapsulation.

Check whether you are using session_id ($ _ COOKIES ['sess _ id.
There is also the scope of cookies, the role path problem. check the setcookie parameter and you will know...

Normally, this is not the case. since tp is set to 7200 effective, it will only be cleared after 7200 seconds according to session. gc processing.

You can check whether other programs cause session effectiveness.

The previous practice was to store the session in cookies. if the session is invalid but the cookie is ineffective, the cookie is copied to the session for processing.

Problem Found

function session($name='',$value='') {            ini_set('session.gc_maxlifetime',   $name['expire']);            //ini_set('session.cookie_lifetime',  $name['expire']);}

It's TP. here we overwrite the cookie life cycle of the session. as a result, the sessionid's life cycle in the cookie is the parameter we set.