NYCPHP Meetup

[Paul A Houle]

Dan Cech wrote:
> If you switch to a custom session storage system (ie, database-backed
> sessions), then you can control the GC this way because they won't be
> cleaned up by the default garbage collector.
>   
    This is the real answer.  PHP sessions (as well as the session 
mechanisms built into other systems such as JSP and ASP.NET) are flawed 
in a number of ways.  They are highly seductive to newbies,  since they 
help you write an application that almost works quickly,  but you can 
spend forever dealing with glitches and stability problems with them.

    User authentication should be done like this:

http://pdos.csail.mit.edu/papers/webauth:sec10.pdf

    That paper has been around for a decade and it still astonishes me 
that people are still using authentication systems that don't really 
work.  I mean,  an authentication system that's bound to a specific 
language?  That isn't good enough for the booby prize,  never mind the 
enterprise. 

The cryptography-based system in the above paper is scalable and can be 
implemented in about 100 lines of code in just about any language.  That 
mean you can log in once and access applications written in PHP,  Perl,  
Java,  Ruby,  C# or whatever.  It's possible to authenticate a user 
using only cryptography,  so you put a very limited load on a central 
database or session store.
 
Other than that,  it turns out that the sessions scope is rarely the 
~correct~ scope for any application.  For instance,  I've seen that 
sites that use language-bound sesson mechanisms often lose about 50% of 
sales because of glitches.  These glitches are hard to reproduce or 
monitor because session systems don't provide any log of lost shopping 
carts.  You'll hear businessmen complain about how they can't afford to 
do things right,  but then they're just happy to lose $2K of sales a day 
to a bad shopping cart.