[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