Jason Pruim wrote:
Just for my own curiosity, why do you think sessions are evil? I haven't found a better way to store my variables between different pages... Other then always posting them in either $_POST or $_GET each time... But that can add up quite a bit on a complicated site though...
Sessions in the way that most PHP developers think about them are an enemy of horizontal scalability, but if slightly alter the way you think about how your app works you can effectively remove the need for this type of session.
Think about how much info you need to store between page requests that isn't already available to you some other way, in a database for example. Now consider that if your app needs to scale then chances are you'll end up with your session storage in a database. What do you gain by extracting that data from it's natural home in the database and putting it into another location in the database for the duration of a users visit?
The one thing you do need to transfer from request to request is something to identify the logged in user. This is done in the same way sessions pass their identifier, in a cookie or in the URL. The only difference is that you need to encrypt it to make it a bit harder to fake. I generally include a timestamp in the encrypted cookie so I can impose a hard limit on the lifetime of a session. Normal rules for good encryption apply here, but bear in mind that every single request will need to decrypt it, and potentially encrypt it too so don't go overboard.
Of course it's possible that the app you're working on will never need to scale beyond one machine, but I have been involved in scaling too many sites that weren't designed to do it to not plan for the possibility in everything I do now.
Anyway, that's why I avoid using 'sessions' wherever possible - IMHO there are better ways to achieve the same goal for most applications.
-Stut -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
