Daniel Convissor wrote:
Basic and Digest auth are slow when it comes to dealing with large user
bases.
I've seen no evidence of that whatsoever.
They also increase insecurity, particularly when working over
non-encrypted connections.
For basic I'd use encrypted connections only. Digest is fine in the
"clear".
Plus I don't like the idea of keeping
authentication information in the browser.
Tough. That's being done anyway.
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.
Only basic really gives out user name and password info one each
request. Digest never passes the password at all. And there are other
schemes.
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?
Because HTTP is explicitly designed to be stateless and sessionless.
See, for example, Sam Ruby's RESTful Web Services.
--
Elliotte Rusty Harold [EMAIL PROTECTED]
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
_______________________________________________
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
