Hi Elliotte:
On Wed, Sep 19, 2007 at 05:48:25AM -0400, Elliotte Harold wrote:
>
> However the fundamental principle is that full auth data must be sent
> with each request.
>
> Breaking that rule is going to cost you big time when you need to scale
> an application.
Basic and Digest auth are slow when it comes to dealing with large user
bases. They also increase insecurity, particularly when working over
non-encrypted connections. Plus I don't like the idea of keeping
authentication information in the browser.
Sure, session id's introduce security pitfalls such as session hijacking,
but that seems less ominous to me than giving out your user name and
password on each request.
> It very well may introduce single points of failure into
> your app. You can architect around those, but only at the cost of doing
> a lot more work with a lot more machines than you would have had to do
> if your app had followed the design of HTTP instead of working against it.
How is using a session id cookie "working against" the design of HTTP?
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php
