Andy's Books
forum
| forum >> Programming questions >> HTML / XHTML / HTML5 / CSS | |
PHP Sessions & Cookies |
|
| Posted May 09 2012 at 8:55 AM by Pete Woodhead (petewdhd) |
This is kind of a two parter. First: Quote:
Any mundane hacker can sniff out your session ids if you allow them to be stored in the URL. To keep this from happening, use the session.use_only_cookies directive in your PHP configuration file.
Harris, Andy (2010-10-28). HTML, XHTML and CSS All-In-One For Dummies (p. 587). For Dummies. Kindle Edition. So not being exactly sure what this meant I did some research and have come to believe that you are referring to the PHP.ini file. I looked there and found that session.use_only_cookies is a Boolean function and is set to (1) or true as opposed to(0) or false. Thus initializing with the use of session_start() to set up a cookie on the users computer instead of passing the session id information to the server. Now, just in case I've given the impression that I have any idea of what I'm talking about, please keep reading. You also mentioned just ahead of the section I've quoted above, that the session function does assign a session id to identify the users browser, which is passed to the server so it will remember the variables associated with it. Further on you mention "session and cookie information are passed entirely in the clear" (I may have paraphrased a bit there). So this is where I become a bit confused. In spite of investigating and reading more about this on my own I'm still not completely sure what is happening. On one hand the session_start gets the session thing rolling, then session.use_only_cookies seems to prevent passing the users id through the URL to the server, but if that is true how is the server recognizing it then or later, and the same with cookies? I hope I'm being clear.  Following on that: You also pointed out that sessions are are different than cookies. My understanding is that the big difference is cookies are stored on the users computer and sessions are not. So it would seem, to a noob like me, anyway, that session.use_only_cookies really just creates a cookie so why use a session at all? Probably most of my confusion centers around my lack of understanding about cookies or sessions. As mentioned, I've done some research, including php.net, which pretty much could just be in Greek for what I'm usually able to glean from it. Can you provide a fuller explanation to help me get my head around this. Thanks, Pete |
| Author | Message | |
| Andy |
Posted: May 15 2012 kl. 10:32 PM This is a kind of messy topic, but I'll give it a shot. Both sessions and cookies are meant to solve the same problem, which is that HTTP has a form of automatic amnesia. Every time you go from the client to the server and back, everything is forgotten. Technically this is called having a stateless protocol. For simple applications, this is fine, but sometimes you want to have things stored from one call of the system to another. Somehow, you're going to have to store the persistent data somewhere. You have two options: store the data on the client, or on the server. The primary way to store data on the client is through the browser's cookie mechanism. This stores all the data in a plain text file managed by the browser. You can give a cookie a predetermined lifespan, but it can be viewed (and hacked) by the client. There is also a practical limit to the amount of information that can be stored in a cookie, determined by the browser. Cookies got a bad reputation in the early days, because they were sometimes used by notorious sites (the cookies themselves did nothing wrong, but somehow the idea that cookies were evil began.) The other solution is to store the persistent information on the server. You can do this yourself through the file commands or a database, or you can use the session mechanism to make this work. The session is essentially a server-side cookie. This file is stored on the server, so it can be large, and it's less likely to be hacked, because it doesn't reside on the client. Session data is always destroyed when the client closes her browser. Just when it sounds sensible, here's the wrinkle. A session also usually involves a small client-side cookie. When you store a session variable, the server will also store a tiny cookie on the client machine to automate synchronization of the server and client. It's this client-side cookie you can turn off, but there's really not much of an advantage to that. In general, a session and a cookie work in much the same way. If in doubt, the session mechanism is safer and pretty well tested. I hope this helps. -Andy |
|
| Pete Woodhead |
Posted: May 16 2012 kl. 9:17 AM Thanks Andy it helps a lot. I'm sure I'll understand this more as I progress. |
|