In an attempt to authenticate multiple users for a Seaside app, I made a subclass of WAAuthenticatedSession and overwrote the method #authenticateUser:password: returning true or false based on our own test.
This didn't work at all, not when choosing that session class in /seaside/config, and not when using WAController>>registerAsApplication:sessionClass:
In both cases the effect was quite bizar: Seaside kept sending redirects until Safari gave up.
What am I doing wrong, or is there a better approach ?
Thx,
Sven
On Nov 20, 2003, at 11:05 AM, Sven Van Caekenberghe wrote:
In an attempt to authenticate multiple users for a Seaside app, I made a subclass of WAAuthenticatedSession and overwrote the method #authenticateUser:password: returning true or false based on our own test.
This didn't work at all, not when choosing that session class in /seaside/config, and not when using WAController>>registerAsApplication:sessionClass:
In both cases the effect was quite bizar: Seaside kept sending redirects until Safari gave up.
What am I doing wrong, or is there a better approach ?
Hi Sven,
I managed to replicate this by throwing an error in the #authenticateUser:password: method. I imagine that if you put a "self halt" there you will find that there's some exception being thrown in yours as well.
My guess is that what's happening is that it keeps trying to display the error page, but requiring authentication for that too, resulting in an infinite recursion. Obviously this is a bug - I think it will get fixed naturally as a result of some of the work I've been doing towards the next release.
Avi
On 20 nov. 03, at 20:28, Avi Bryant wrote:
On Nov 20, 2003, at 11:05 AM, Sven Van Caekenberghe wrote:
In an attempt to authenticate multiple users for a Seaside app, I made a subclass of WAAuthenticatedSession and overwrote the method #authenticateUser:password: returning true or false based on our own test.
This didn't work at all, not when choosing that session class in /seaside/config, and not when using WAController>>registerAsApplication:sessionClass:
In both cases the effect was quite bizar: Seaside kept sending redirects until Safari gave up.
What am I doing wrong, or is there a better approach ?
Hi Sven,
I managed to replicate this by throwing an error in the #authenticateUser:password: method. I imagine that if you put a "self halt" there you will find that there's some exception being thrown in yours as well.
My guess is that what's happening is that it keeps trying to display the error page, but requiring authentication for that too, resulting in an infinite recursion. Obviously this is a bug - I think it will get fixed naturally as a result of some of the work I've been doing towards the next release.
Avi
Hi Sven and Avi,
I ran into exactly the same issue last week trying to solve the same problem.
The error I made (which caused the same Safari redirection problem as Sven reports) was to not return aBoolean in my home-grown:
MultipleUserAuthenticatedSession>>authenticateUser: username password: password
At one point I had the method returning False (on username/password mis-match) instead of false. Yes, I've been spending too much time with Python... At the time I felt too silly to blog my error...
Ian.
On 20 Nov 2003, at 20:28, Avi Bryant wrote:
I managed to replicate this by throwing an error in the #authenticateUser:password: method. I imagine that if you put a "self halt" there you will find that there's some exception being thrown in yours as well.
Thanks Avi, it now works - there was some error there that got swallowed.
My guess is that what's happening is that it keeps trying to display the error page, but requiring authentication for that too, resulting in an infinite recursion. Obviously this is a bug - I think it will get fixed naturally as a result of some of the work I've been doing towards the next release.
Maybe there should be some option somewhere to do more logging.
Subclassing WAAuthenticatedSession for use through /seaside/config has another problem in the defaultPreferences class method - no ?
Also, how do you 'log out' ?
Doing new session doesn't re-authenticate as far as i can tell.
Sven
On Nov 20, 2003, at 2:10 PM, Sven Van Caekenberghe wrote:
Maybe there should be some option somewhere to do more logging.
Yes, definitely.
Subclassing WAAuthenticatedSession for use through /seaside/config has another problem in the defaultPreferences class method - no ?
Yeah, I wouldn't really recommend starting with that class. It was intended as a *really* simple way of protecting an app from the general public, not for any real authentication/authorization.
Also, how do you 'log out' ?
Doing new session doesn't re-authenticate as far as i can tell.
AFAIK there isn't a reliable way of logging out from HTTP Basic Auth, short of quitting the browser - that's one of the problems of the protocol. New session does reauthenticate - in fact, you're reauthenticated on every page view - but the browser is remembering your credentials and presenting them each time.
Because of this, most people use form-based login pages these days...
On 20 nov. 03, at 23:19, Avi Bryant wrote:
Also, how do you 'log out' ?
Doing new session doesn't re-authenticate as far as i can tell.
AFAIK there isn't a reliable way of logging out from HTTP Basic Auth, short of quitting the browser - that's one of the problems of the protocol. New session does reauthenticate - in fact, you're reauthenticated on every page view - but the browser is remembering your credentials and presenting them each time.
It's a pity that more browsers do no offer a "clear passwords" option like OmniWeb does via its very useful "Clear Cache option.
Because of this, most people use form-based login pages these days...
Sigh... which is a real pain if you need to write a client http application to interact with the session cookies instead of simply "calling" http://user:password@www.server.com
IMHO the protocol is fine, it's the browsers the are broken.
Ian.
On 20 Nov 2003, at 23:19, Avi Bryant wrote:
Because of this, most people use form-based login pages these days...
It is a pity then that WAAuthenticatedSession isn't doing this ;-)
In any case, the behavior of putting a component under security control should be pluggable.
I tried this:
WAComponent subclass B9WALogin with user/password instance vars, answers itself on login
WAControllerSession subclass B9WAAuthenticatedSession with user instance var and the following #start: method
start: aRequest user ifNil: [ | login | login := self call: B9WALogin new. (self authenticateUser: login user password: login password) ifTrue: [ user := login user. super start: aRequest] ifFalse: [ ]] ifNotNil: [ super start: aRequest]
I haven't tried this because I known it can't work: #call: isn't implemented/supported here, I also do not know very well what to do on failed logins (the login page should come up again I guess). I looked at how errors/warnigns are handled, but that looks like internal stuff to me...
Is there a way to make this work ?
Sven
seaside@lists.squeakfoundation.org
-
Avi Bryant -
Ian Prince -
Sven Van Caekenberghe