Re: [PHP] Cookies/Sessions and how they work
It brings up another question, though. Let's say that I have a session_start() call at the beginning of a bunch of pages. So that each time one of these pages is called, the call is made to session_start(). It seems like it would screw things up royally if each call to session_start() generated a new SID. The browser sends an SID cookie to the server on page request. And if the page has a session_start() call at the beginning of it, is it reasonable to assume that the server will not generate a new SID, but instead use the one sent in the HTTP request to find its session information? (Assuming the timeout hasn't expired, the user is still using the same instance of the browser, etc.) Similarly, if an SID *isn't* sent by the browser, then a call to session_start() at the beginning of the page *will* generate a completely new SID, right? Correct. Easy test: ?php session_start(); echo sess id: . session_id(); visit the page in your browser, refresh a couple of times (id will be the same). Clear the cookies in your browser, refresh - new id. -- Postgresql php tutorials http://www.designmagick.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies/Sessions and how they work
Paul M Foster wrote: This is in two parts. First cookies. I'm a little unclear on how they work. From what I've read, cookies are stored by the browser. When a request for that cookie comes in from the server, the browser returns only the value, and no other data. One question: When the browser requests a page from a server, does it automatically search its cookies for that domain and send them along with the other requests? If that's now how it works, then how does it work? The browser sends all cookie information as part of the request. You can see this by creating a dummy page that does not call seesion_start() that includes an XSS attack that reads the cookie and displays the session ID in an alert. Second part is about sessions. According to the notes for the cookies page at php.net, it's considered bad practice to store user IDs and passwords in cookies. It's considered better practice to use PHP's native session-handling code to do this. But if a user has cookies turned on in the browser, then PHP will store the session information (possibly user ID and password) as a cookie. So what's the difference? session stuff is stored server side, only the session ID is stored in the cookie. It is still a bad idea to store username and password in the session because if you are on a shared server and you are not using a DB for session management (default is not to) another user on the server can read your cookies. Even if you are using a database for session management, storing username/password in the session is a risk in case there is an sql injection attack that succesfully dumps your session database (which is bad enough w/o it exposing passwords). I store a user id in the session and get the username from a db lookup if/when I need the username (but storing the username itself isn't really dangerous and would save an sql lookup in some cases). There's no need to store password. If the user is not logged in, the session userid is set to 0. Anything that requires authentication in my code requires a session userid 0 - and the userid can only be changed to a positive value via login. -=- A gotcha - changing a session variable doesn't actually happen until the script exits. So if you set a session variable and then use the session variable later in the script, it will use the OLD value and not the new value, because the new value hasn't yet been written to the session. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies/Sessions and how they work
Paul M Foster wrote: This is in two parts. First cookies. I'm a little unclear on how they work. From what I've read, cookies are stored by the browser. When a request for that cookie comes in from the server, the browser returns only the value, and no other data. One question: When the browser requests a page from a server, does it automatically search its cookies for that domain and send them along with the other requests? If that's now how it works, then how does it work? Yep (afaik). Second part is about sessions. According to the notes for the cookies page at php.net, it's considered bad practice to store user IDs and passwords in cookies. It's considered better practice to use PHP's native session-handling code to do this. But if a user has cookies turned on in the browser, then PHP will store the session information (possibly user ID and password) as a cookie. So what's the difference? When a page request comes in, the browser sends a cookie - but it's only the session id. No other info is stored in the cookie or browser. PHP then looks for that session id in a specified location (session.save_path) and then loads that data from the server. -- Postgresql php tutorials http://www.designmagick.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies/Sessions and how they work
On Mon, Mar 9, 2009 at 10:26 PM, Paul M Foster pa...@quillandmouse.com wrote: This is in two parts. First cookies. I'm a little unclear on how they work. From what I've read, cookies are stored by the browser. When a request for that cookie comes in from the server, the browser returns only the value, and no other data. One question: When the browser requests a page from a server, does it automatically search its cookies for that domain and send them along with the other requests? If that's now how it works, then how does it work? Second part is about sessions. According to the notes for the cookies page at php.net, it's considered bad practice to store user IDs and passwords in cookies. It's considered better practice to use PHP's native session-handling code to do this. But if a user has cookies turned on in the browser, then PHP will store the session information (possibly user ID and password) as a cookie. So what's the difference? The reference for the above is: http://us2.php.net/manual/en/features.cookies.php#36058 Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php When a website sends the Cookie: in a HTTP header, the browser decides what to do with it (or not to do). Generally, it saves the cookie name and contents into a file. Although, various browsers handle cookies differently, and some browsers ignore them completely (or have options to). Within the cookie data are various things, such as the domain and expiration. When you point the browser to a website, the browser checks all it's cookies and see if the website matches the domain field in any of the cookies. If so, it sends the name/content of the cookie/cookies to the site in a/an HTTP header automatically. A very useful tool in monitoring all this and viewing what your browser does behind the scenes is the Firefox extension Live HTTP Headers. https://addons.mozilla.org/en-US/firefox/addon/3829 PHP sessions use cookies. When you call session_start() for the first time, php randomly generates a unique hash ID for that session. It sends it to the browser as a cookie with the name PHPSESSID (this is customizable in php.ini). The server keeps a list of all the sessions on the HDD (and expires them when needed, of course). When you store any variable into the $_SESSION superglobal var, it stores the data ON THE SERVER - nothing is sent to the browser. The browser only sends the session ID cookie, which tells the server hey, get the $_SESSION data for this session ID. So it's up to the browser to send the session cookie each time, else all the $_SESSION data is lost. Help clear it up for ya? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Cookies/Sessions and how they work
Hi I don't think PHP stores Session information in Cookies. However It dose store the sessionId (a unique alphanumeric string) in cookies. This SessionId is used to identify the requests sent from one user. The Session information is by default stored in the /tmp directory on your system in a flat file. Chetan Dattaram Rane | Software Engineer | Persistent Systems chetan_r...@persistent.co.in | Cell: +91 94033 66714 | Tel: +91 (0832) 30 79014 Innovation in software product design, development and delivery- www.persistentsys.com -Original Message- From: Paul M Foster [mailto:pa...@quillandmouse.com] Sent: Tuesday, March 10, 2009 7:57 AM To: php-general@lists.php.net Subject: [PHP] Cookies/Sessions and how they work This is in two parts. First cookies. I'm a little unclear on how they work. From what I've read, cookies are stored by the browser. When a request for that cookie comes in from the server, the browser returns only the value, and no other data. One question: When the browser requests a page from a server, does it automatically search its cookies for that domain and send them along with the other requests? If that's now how it works, then how does it work? Second part is about sessions. According to the notes for the cookies page at php.net, it's considered bad practice to store user IDs and passwords in cookies. It's considered better practice to use PHP's native session-handling code to do this. But if a user has cookies turned on in the browser, then PHP will store the session information (possibly user ID and password) as a cookie. So what's the difference? The reference for the above is: http://us2.php.net/manual/en/features.cookies.php#36058 Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies/Sessions and how they work
On Mon, Mar 09, 2009 at 11:35:57PM -0400, APseudoUtopia wrote: On Mon, Mar 9, 2009 at 10:26 PM, Paul M Foster pa...@quillandmouse.com wrote: This is in two parts. First cookies. I'm a little unclear on how they work. From what I've read, cookies are stored by the browser. When a request for that cookie comes in from the server, the browser returns only the value, and no other data. One question: When the browser requests a page from a server, does it automatically search its cookies for that domain and send them along with the other requests? If that's now how it works, then how does it work? Second part is about sessions. According to the notes for the cookies page at php.net, it's considered bad practice to store user IDs and passwords in cookies. It's considered better practice to use PHP's native session-handling code to do this. But if a user has cookies turned on in the browser, then PHP will store the session information (possibly user ID and password) as a cookie. So what's the difference? The reference for the above is: http://us2.php.net/manual/en/features.cookies.php#36058 Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php When a website sends the Cookie: in a HTTP header, the browser decides what to do with it (or not to do). Generally, it saves the cookie name and contents into a file. Although, various browsers handle cookies differently, and some browsers ignore them completely (or have options to). Within the cookie data are various things, such as the domain and expiration. When you point the browser to a website, the browser checks all it's cookies and see if the website matches the domain field in any of the cookies. If so, it sends the name/content of the cookie/cookies to the site in a/an HTTP header automatically. A very useful tool in monitoring all this and viewing what your browser does behind the scenes is the Firefox extension Live HTTP Headers. https://addons.mozilla.org/en-US/firefox/addon/3829 PHP sessions use cookies. When you call session_start() for the first time, php randomly generates a unique hash ID for that session. It sends it to the browser as a cookie with the name PHPSESSID (this is customizable in php.ini). The server keeps a list of all the sessions on the HDD (and expires them when needed, of course). When you store any variable into the $_SESSION superglobal var, it stores the data ON THE SERVER - nothing is sent to the browser. The browser only sends the session ID cookie, which tells the server hey, get the $_SESSION data for this session ID. So it's up to the browser to send the session cookie each time, else all the $_SESSION data is lost. Help clear it up for ya? Yes, this essentially echoes what Chis said. Thanks. It brings up another question, though. Let's say that I have a session_start() call at the beginning of a bunch of pages. So that each time one of these pages is called, the call is made to session_start(). It seems like it would screw things up royally if each call to session_start() generated a new SID. The browser sends an SID cookie to the server on page request. And if the page has a session_start() call at the beginning of it, is it reasonable to assume that the server will not generate a new SID, but instead use the one sent in the HTTP request to find its session information? (Assuming the timeout hasn't expired, the user is still using the same instance of the browser, etc.) Similarly, if an SID *isn't* sent by the browser, then a call to session_start() at the beginning of the page *will* generate a completely new SID, right? Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
