manual/en/features.cookies.php

20130923_rev01 · COMPARED WITH 20130822_rev01 · ARCHIVE SNAPSHOT, DATE APPROXIMATE

Full text changes — 20130822_rev01 to 20130923_rev01

1Change language:
19
22
3PHP transparently supports HTTP cookies. Cookies are a mechanism for storing data in the remote browser and thus tracking or identifying return users. You can set cookies using the [setcookie()](http://www.php.net/manual/en/function.setcookie.php) or [setrawcookie()](http://www.php.net/manual/en/function.setrawcookie.php) function. Cookies are part of the HTTP header, so [setcookie()](http://www.php.net/manual/en/function.setcookie.php) must be called before any output is sent to the browser. This is the same limitation that [header()](http://www.php.net/manual/en/function.header.php) has. You can use the [output buffering functions](http://www.php.net/manual/en/ref.outcontrol.php) to delay the script output until you have decided whether or not to set any cookies or send any headers.
4
5Any cookies sent to you from the client will automatically be included into a [$\_COOKIE](http://www.php.net/manual/en/reserved.variables.cookies.php) auto-global array if [variables\_order](http://www.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.
6
7Depending on [register\_globals](http://www.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. $HTTP\_COOKIE\_VARS is also set in earlier versions of PHP when the [track\_vars](http://www.php.net/manual/en/ini.core.php) configuration variable is set. (This setting is always on since PHP 4.0.3.)
8
9For more details, including notes on browser bugs, see the [setcookie()](http://www.php.net/manual/en/function.setcookie.php) and [setrawcookie()](http://www.php.net/manual/en/function.setrawcookie.php) function.
10
116
12
133[**_ingen at stocken.ws_**](http://www.php.net/manual/en/features.cookies.php) [¶](http://www.php.net/manual/en/features.cookies.php)
144
155**6 years ago**
166
177`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)*.`
188
3323`If you need a javascript for md5: [http://pajhome.org.uk/crypt/md5/md5src.html](http://pajhome.org.uk/crypt/md5/md5src.html)`
3424
3525`---`
3626
3727`* You could use session_set_save_handler and make sure the session ID is generated in the open function. I haven't done that so I can't make any comments on it yet.`
3828
391
292
4030
4131[**_Anonymous_**](http://www.php.net/manual/en/features.cookies.php) [¶](http://www.php.net/manual/en/features.cookies.php)
4232
43**4 months ago**
33**5 months ago**
4434
4535`Your note is too short. Trying to test the notes system? Save us the trouble of deleting your test, and don't. It works.`
4636
471
372
4838
49[**_mega-squall at caramail dot com_**](http://www.php.net/manual/en/features.cookies.php) [¶](http://www.php.net/manual/en/features.cookies.php)
50
51**8 years ago**
52
53`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.`
54
55`If the user gets disconnected, he will reconnect : as my policy is not to have more than one session ID for each user (sessions entries have a UNIQUE key on the collomn in which is stored user login), every entries for that user gets wiped, a new session ID is generated and stored on users dirve : the pirate gets disconnected. This lets the pirate usually just a few seconds to act. The slower visitors are browsing, the longer is the time pirates get for hacking. Also, if users forget to explicitly end their sessions .... some of my users set timeout longer than 20 minutes !`
56
57`IMPORTANT NOTE : This disables the ability of using the back button if you send the session ID via POST or GET.`
58
590
60
6139[**_meetyashah at gmail dot com_**](http://www.php.net/manual/en/features.cookies.php) [¶](http://www.php.net/manual/en/features.cookies.php)
6240
63**3 months ago**
41**5 months ago**
6442
6543`PAGE 1`
6644
6745`<?php echo $_COOKIE["first"]; ?> PAGE 2`
6846
6947`<?php if(isset($_COOKIE["first"])) { echo $_COOKIE["first"];} echo '<br />'; if(isset($_COOKIE["second"])){ echo $_COOKIE["second"]; } echo '<br />'; if(isset($_COOKIE["third"])){ echo $_COOKIE["third"]; } ?>`
7048
71\-1
492
7250
73[**_James Olsen_**](http://www.php.net/manual/en/features.cookies.php) [¶](http://www.php.net/manual/en/features.cookies.php)
51[**_mega-squall at caramail dot com_**](http://www.php.net/manual/en/features.cookies.php) [¶](http://www.php.net/manual/en/features.cookies.php)
7452
7553**8 years ago**
7654
77`Tying the session to the IP of the user is not a good idea. Some users, notably AOL users, are behind a rotating proxy which means their hits to the server will actually be coming from different IP addresses over the duration of their visit. Trying the session to the IP will not work properly for those users.`
55`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.`
7856
79\-1
57`If the user gets disconnected, he will reconnect : as my policy is not to have more than one session ID for each user (sessions entries have a UNIQUE key on the collomn in which is stored user login), every entries for that user gets wiped, a new session ID is generated and stored on users dirve : the pirate gets disconnected. This lets the pirate usually just a few seconds to act. The slower visitors are browsing, the longer is the time pirates get for hacking. Also, if users forget to explicitly end their sessions .... some of my users set timeout longer than 20 minutes !`
8058
59`IMPORTANT NOTE : This disables the ability of using the back button if you send the session ID via POST or GET.`
60
610
62
8163[**_myfirstname at braincell dot cx_**](http://www.php.net/manual/en/features.cookies.php) [¶](http://www.php.net/manual/en/features.cookies.php)
8264
8365**9 years ago**
8466
8567`[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]`
8668
8769`Just a general comment on Wilton's code snippet: It's generally considered very bad practice to store usernames and/or passwords in cookies, whether or not they're obsfucated. Many spyware programs make a point of stealing cookie contents.`
8870
8971`A much better solution would be to either use the PHP built in session handler or create something similar using your own cookie-based session ID. This session ID could be tied to the source IP address or can be timed out as required but since the ID can be expired separately from the authentication criteria the authentication itself is not compromised.`
9072
9173`Stuart Livings`
9274
75\-1
76
77[**_Henry_**](http://www.php.net/manual/en/features.cookies.php) [¶](http://www.php.net/manual/en/features.cookies.php)
78
79**4 years ago**
80
81`It is better to note not to attach your cookies to and IP and block the IP if it is different as some people use Portable Browsers which will remember the cookies. It is better to show a login screen instead if the IP does not correspond to the session cookie's IP.`
82
9383\-2
9484
95[**_bmorency at jbmlogic dot com_**](http://www.php.net/manual/en/features.cookies.php) [¶](http://www.php.net/manual/en/features.cookies.php)
85[**_kalla\_durga at gmail dot com_**](http://www.php.net/manual/en/features.cookies.php) [¶](http://www.php.net/manual/en/features.cookies.php)
9686
9787**7 years ago**
9888
9989`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:`
10090
10191`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).`
10292
10393`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.`
10494
10595`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.`
10696
107\-3
97\-2
10898
109[**_Henry_**](http://www.php.net/manual/en/features.cookies.php) [¶](http://www.php.net/manual/en/features.cookies.php)
99[**_bmorency at jbmlogic dot com_**](http://www.php.net/manual/en/features.cookies.php) [¶](http://www.php.net/manual/en/features.cookies.php)
110100
111**4 years ago**
101**7 years ago**
112102
113`It is better to note not to attach your cookies to and IP and block the IP if it is different as some people use Portable Browsers which will remember the cookies. It is better to show a login screen instead if the IP does not correspond to the session cookie's IP.`
103`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:`
114104
115\-3
105`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).`
116106
117[**_john at host89 dot net_**](http://www.php.net/manual/en/features.cookies.php) [¶](http://www.php.net/manual/en/features.cookies.php)
107`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.`
118108
119**3 years ago**
109`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.`
120110
121`I'm currently developing a secure system utilizing PHP session cookies, and rather than trying to deal with recreating a session every time the script runs (which would hurt server performance), I'm having the script send a 2nd cookie to the client which contains an MD5 of their username along with a random value (so that it's harder to generate a matching key if somebody is trying to hijack the session.) The original random value can be stored as $_SESSION['rndvalue'] or something of the like, and easily re-hashed and compared to the cookie. If it isn't valid, just a simple session_destroy(); does the trick. For higher security, the random value could even be changed at every new page, and to make leeway for that double-click phenomon, save the old one as 'rndvalueold' with the expiration time as 'rndvalueexpire' or something. This will also let users use the back button even if the session ID is passed via GET or POST.`
111\-2
122112
123\-3
113[**_James Olsen_**](http://www.php.net/manual/en/features.cookies.php) [¶](http://www.php.net/manual/en/features.cookies.php)
124114
125[**_kalla\_durga at gmail dot com_**](http://www.php.net/manual/en/features.cookies.php) [¶](http://www.php.net/manual/en/features.cookies.php)
115**8 years ago**
126116
127**7 years ago**
117`Tying the session to the IP of the user is not a good idea. Some users, notably AOL users, are behind a rotating proxy which means their hits to the server will actually be coming from different IP addresses over the duration of their visit. Trying the session to the IP will not work properly for those users.`
128118
129`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:`
119\-5
130120
131`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).`
121[**_john at host89 dot net_**](http://www.php.net/manual/en/features.cookies.php) [¶](http://www.php.net/manual/en/features.cookies.php)
132122
133`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.`
123**3 years ago**
134124
135`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.`
125`I'm currently developing a secure system utilizing PHP session cookies, and rather than trying to deal with recreating a session every time the script runs (which would hurt server performance), I'm having the script send a 2nd cookie to the client which contains an MD5 of their username along with a random value (so that it's harder to generate a matching key if somebody is trying to hijack the session.) The original random value can be stored as $_SESSION['rndvalue'] or something of the like, and easily re-hashed and compared to the cookie. If it isn't valid, just a simple session_destroy(); does the trick. For higher security, the random value could even be changed at every new page, and to make leeway for that double-click phenomon, save the old one as 'rndvalueold' with the expiration time as 'rndvalueexpire' or something. This will also let users use the back button even if the session ID is passed via GET or POST.`