NYCPHP Meetup

[Elliotte Harold]

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  elharo at metalab.unc.edu
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/