NYCPHP Meetup

NYPHP.org

[nycphp-talk] Session timing out too soon

Petros Ziogas petros.ziogas at gmail.com
Thu Dec 4 10:30:41 EST 2008


That was an awesome read.
I felt really good for doing something similar for some years now :)

I also agree that authentication should not rely on anything more than a
well written algorythm.

Petros Ziogas
http://www.royalblue.gr



On Thu, Dec 4, 2008 at 5:09 PM, Paul A Houle <paul at devonianfarm.com> wrote:

> 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.
>
> _______________________________________________
> New York PHP User Group Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> http://www.nyphp.org/show_participation.php
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20081204/f4129f25/attachment.html>


More information about the talk mailing list