manual/en/features.cookies.php
20180101_rev01 · COMPARED WITH 20171002_rev01 · ARCHIVE SNAPSHOT, DATE APPROXIMATE
Full text changes — 20171002_rev01 to 20180101_rev01
| 29 | 29 | `Stuart Livings` |
| 30 | 30 | |
| 31 | 31 | \-15 |
| 32 | 32 | |
| 33 | 33 | [**_bmorency at jbmlogic dot com_**](http://php.net/manual/en/features.cookies.php) [¶](http://php.net/manual/en/features.cookies.php) |
| 34 | 34 | |
| 35 | **11 years ago** | |
| 35 | **12 years ago** | |
| 36 | 36 | |
| 37 | 37 | `In response to the solution posted in the comment below, there are some practical issues with this solution that must be kept in mind and handled by your code. I developed an application using a similar "use-it-once" key to manage sessions and it worked great but we got some complaints about legitimate users getting logged out without reasons. Turns out the problem was not tentative highjacking, it was either:` |
| 38 | 38 | |
| 39 | 39 | `A- Users double click on links or make 2 clicks very fast. The same key is sent for the 2 clicks because the new key from the first click didn't get to the browser on time for the second one but the session on the server did trash the key for the new one. Thus, the second click causes a termination of the session. (install the LiveHttpHeaders extension on firefox and look at the headers sent when you click twice very fast, you'll see the same cookie sent on both and the new cookie getting back from the server too late).` |
| 40 | 40 | |
| 41 | 41 | `B- For any given reason, the server experiences a slow down and the response with the new key (which has replaced the old one on the server) is not returned to the browser fast enough. The user gets tired of waiting and clicks somewhere else. He gets logged out because this second click send the old key which won't match the one you have on your server.` |
| 43 | 43 | `Our solution was to set up a grace period where the old key was still valid (the current key and the previous key were both kept at all times, we used 15 seconds as a grace period where the old key could still be used). This has the drawback of increasing the window of time for a person to highjack the session but if you tie the validity of the old key to an IP address and/or user agent string, you still get pretty good session security with very very few undesired session termination.` |
| 44 | 44 | |
| 45 | 45 | \-28 |
| 46 | 46 | |
| 47 | 47 | [**_ingen at stocken.ws_**](http://php.net/manual/en/features.cookies.php) [¶](http://php.net/manual/en/features.cookies.php) |
| 48 | 48 | |
| 49 | **10 years ago** | |
| 49 | **11 years ago** | |
| 50 | 50 | |
| 51 | 51 | `If you want a secured session not tied to the client IP you can use the valid-for-one-query method below, but to safeguard against a scenario where the legitimate user clicks twice, you can use a shutdown function (register_shutdown_function)*.` |
| 52 | 52 | |
| 53 | 53 | `It will check to see if the script terminated prematurely (connection_aborted), and reset the valid session ID. That way, it's still valid when the user makes the second request. If the script ends properly, the new session ID will be used instead.` |
| 54 | 54 | |
| 55 | 55 | `Now, since you can't set a cookie from the shutdown function (after output has been sent), the cookie should contain both the previous valid session ID and the new one. Then the server script will determine (on the next request) which one to use.` |