manual/en/features.cookies.php

ARCHIVED 2006-12-01, DATE APPROXIMATE · VERSION 20061201_rev01 · COMPARED WITH 20061014_rev01

Full text changes — 20061014_rev01 to 20061201_rev01

COLOUR MARKS THE SEVERITY OF A FLAGGED CLAUSE · + AND − MARK ADDED AND REMOVED

+- [HTTP authentication with PHP](http://www.php.net/manual/en/features.http-auth.php)
+- [Cookies](http://www.php.net/manual/en/features.cookies.php)
+- [Sessions](http://www.php.net/manual/en/features.sessions.php)
+- [Dealing with XForms](http://www.php.net/manual/en/features.xforms.php)
+- [Handling file uploads](http://www.php.net/manual/en/features.file-upload.php)
+- [Using remote files](http://www.php.net/manual/en/features.remote-files.php)
+- [Connection handling](http://www.php.net/manual/en/features.connection-handling.php)
+- [Persistent Database Connections](http://www.php.net/manual/en/features.persistent-connections.php)
+- [Safe Mode](http://www.php.net/manual/en/features.safe-mode.php)
+- [Using PHP from the command line](http://www.php.net/manual/en/features.commandline.php)
 ## Chapter 35. Cookies
 PHP 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.
 Any cookies sent to you from the client will automatically be included into a [$\_COOKIE](http://www.php.net/manual/en/reserved.variables.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.
 For 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.
   [add a note](http://www.php.net/manual/add-note.php) User Contributed Notes
 **Cookies**
+**ingen at stocken.ws**
+[19-Nov-2006 12:26](http://www.php.net/manual/en/features.cookies.php)
+`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)*.`
+`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.`
+`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.`
+`:: Pseudo example: :: :: [Start of script:] :: :: 1. Get the session ID(s) from cookie :: 2. If one of the session ID's is still valid (that is, if there's a storage associated with it - in DB, file or whatever) :: ____2.1. Open the session :: 3. Generate a new session ID :: 4. Save the new session ID with the one just used in cookie :: 5. Register shutdown function :: :: [End of script (shutdown function):] :: :: 1. If script ended prematurely :: ____1.1. Save session data using the old Session ID :: 2. Else :: ____2.1. Save session data using the new Session ID :: ____2.2. Make sure the old session ID is added to a list of ID's (used for the purpose described below) :: ____2.3. Trash the old session storage`
+`There's still the possibility of some deviant network sniffer catching the session cookie as it's sent to the client, and using it before the client gets the chance to. Thus, successfully hijacking the session.`
+`If an old session ID is used, we must assume the session has been hijacked. Then the client could be asked to input his/her password before data is sent back. Now, since we have to assume that only the legitimate user has the password we won't send back any data until a password is sent from one request.`
+`And finally, (as a sidenote) we could obscure the login details (if the client has support for javascript) by catching the form as it is sent, take the current timestamp and add it to the form in a dynamically generated hidden form object, replace the password field with a new password that is the MD5 (or similar) of the timestamp and the real password. On the serverside, the script will take the timestamp, look at the user's real password and make the proper MD5. If they match, good, if not, got him! (This will of course only work when we have a user with a session that's previously logged in, since we know what password (s)he's supposed to have.) If the user credentials are saved as md5(username+password), simply ask for both the username and password, md5 them and then md5 the timestamp and the user cred.`
+`---`
+`If you need a javascript for md5: [http://pajhome.org.uk/crypt/md5/md5src.html](http://pajhome.org.uk/crypt/md5/md5src.html)`
+`---`
+`* 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.`
 **kalla\_durga at gmail dot com**
 [03-Feb-2006 12:10](http://www.php.net/manual/en/features.cookies.php)
 `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:`
 `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).`