Re: session or cookie

> Not entirely true - I made a shopping cart (as many others have) that stored > tons of info in a table. This was keyed by ONE cookie that was 32 characters > long (aka a sessionID). So I don't *really* buy that. > yeah, that's only 32 bytes. a cookie can store something like 4000 characters (4K). It's when you get to that size that it's like having another small image on your page. You're right though, even at 4K, it's not that big a deal unless you're doing millions of page views a day and you need to shave off bandwidth. > > The chances of someone altering the cookie and then stealing someone elses > data is quite slim - if you seed your random sessionID well enough you shoudn't > have any problems. > absolutely. using a sessionID is a great way to go, then have that point to more data on the server. It's when you store information like OrderID in a cookie that you start getting hacked. That's a silly example. But let's say you did store OrderID in a cookie, the user could just change the value of that and view someone else's order. DOH! you don't want that. A better way to do it is just like you said, store a random sessionID in the cookie (or URL for that matter) and have that point to the OrderID in the database. > > Even with the speed issues, use session vars, they're more flexible and > > they add one more layer of security. :) > > I don't see how this is true ... I personally think session vars are for people > who didn't quite understand the setcookie() function :) (this is meant as a > joke - don't flame) > They both have different purposes. The only real reason I've seen to ever set a cookie is to store that "sessionID" that you were talking about a second ago, make that point to real data on the server side. > AFAICT cookies and session id's are pretty much six one way; half a dozen the > other (or 5cm one way 50mm the other for metric people) > touché Steve Nelson http://www.SecretAgents.com Tools for Fusebox Developers