manual/en/features.cookies.php

20170101_rev01 · COMPARED WITH 20161107_rev01 · ARCHIVE SNAPSHOT, DATE APPROXIMATE

Full text changes — 20161107_rev01 to 20170101_rev01

33Any cookies sent to you from the client will automatically be included into a [$\_COOKIE](http://php.net/manual/en/reserved.variables.cookies.php) auto-global array if [variables\_order](http://php.net/manual/en/ini.core.php) contains "C". If you wish to assign multiple values to a single cookie, just add _\[\]_ to the cookie name.
44
55Depending on [register\_globals](http://php.net/manual/en/ini.core.php), regular PHP variables can be created from cookies. However it's not recommended to rely on them as this feature is often turned off for the sake of security.
66
77For more details, including notes on browser bugs, see the [setcookie()](http://php.net/manual/en/function.setcookie.php) and [setrawcookie()](http://php.net/manual/en/function.setrawcookie.php) function.
88
9117
9121
1010
1111[**_Tugrul_**](http://php.net/manual/en/features.cookies.php) [¶](http://php.net/manual/en/features.cookies.php)
1212
1313**1 year ago**
1414
1515`Setting new cookie ============================= <?php setcookie("name","value",time()+$int); /*name is your cookie's name value is cookie's value $int is time of cookie expires*/ ?> Getting Cookie ============================= <?php echo $_COOKIE["your cookie name"]; ?> Updating Cookie ============================= <?php setcookie("color","red"); echo $_COOKIE["color"]; /*color is red*/ /* your codes and functions*/ setcookie("color","blue"); echo $_COOKIE["color"]; /*new color is blue*/ ?> Deleting Cookie ============================== <?php unset($_COOKIE["yourcookie"]); /*Or*/ setcookie("yourcookie","yourvalue",time()-1); /*it expired so it's deleted*/ ?> Reference: [http://gencbilgin.net/php-cookie-kullanimi.html](http://gencbilgin.net/php-cookie-kullanimi.html)`
1616
1713
1712
1818
1919[**_myfirstname at braincell dot cx_**](http://php.net/manual/en/features.cookies.php) [¶](http://php.net/manual/en/features.cookies.php)
2020
2121**13 years ago**
2222
2323`[Editor's note: Wilson's comment has been deleted since it didn't contain much useful information, but this note is preserved although its reference is lost]`
2929`Stuart Livings`
3030
3131\-19
3232
3333[**_ingen at stocken.ws_**](http://php.net/manual/en/features.cookies.php) [¶](http://php.net/manual/en/features.cookies.php)
3434
35**9 years ago**
35**10 years ago**
3636
3737`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)*.`
3838
3939`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.`
4040
4141`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.`
7575`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).`
7676
7777`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.`
7878
7979`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.`
8080
81\-38
82
83[**_Anonymous_**](http://php.net/manual/en/features.cookies.php) [¶](http://php.net/manual/en/features.cookies.php)
84
85**3 years ago**
86
87`Your note is too short. Trying to test the notes system? Save us the trouble of deleting your test, and don't. It works.`
88
8981\-42
9082
9183[**_kalla\_durga at gmail dot com_**](http://php.net/manual/en/features.cookies.php) [¶](http://php.net/manual/en/features.cookies.php)
9284
9385**10 years ago**
9486
9789`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).`
9890
9991`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.`
10092
10193`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.`
10294
103\-41
95\-42
10496
10597[**_mega-squall at caramail dot com_**](http://php.net/manual/en/features.cookies.php) [¶](http://php.net/manual/en/features.cookies.php)
10698
10799**11 years ago**
108100
109101`I found a solution for protecting session ID without tying them to client's IP. Each session ID gives access for only ONE querry. On the next querry, another session ID is generated and stored. If somebody hacks the cookie (or the session ID), the first one of the user and the pirate that will use the cookie will get the second disconnected, because the session ID has been used.`