Re: Auth feature

I generally see that the following changes would have to be made to auth, either in the base class or subclassing it a) a new method drawLoginChap b) two new variables added to the auth data (challenge and challenge responce) c) a new option should be passed to auth (useChap), d) two paths here I)if option useChap is enabled and container has a fetchChapData method, call that instead with ($this->username, $this->password, $this->challenge, $this->challengeresponce) II)alternativly the fetchData method could be extended to accept two more optional parameters and if provided work on those I would also like to see the things proposed by Michael Bretterklieber and see if those could be used see below for answers to your questions Yavor Martin Jansen wrote:

This sounds like cool stuff, but I actually have some points: a) There has to be a fallback mechanism for user agents without JavaScript support. Users with out js support would use the normal features of auth

b) The Challenge support would require storing the password non-encrypted somewhere, no? This is a bad idea, IMO. Depending on the way auth works it should take into account the options['cryptType'] parameter, if it is not md5 it would fallback to the default auth behaviour. In the case md5 is used he algorithm could be changed a bit as proposed by alan responce(user, md5(pass), challenge). Of cource this would restrict it to the db container.

c) How do you want to populate the necessary JavaScript code? Currently the PEAR installer can't place a file in a document root. two options here either have the save script code in the slass it's self, or in a second .js file which will be included

include("Auth/md5.js"), I know it is an ugly way to do it but those are the options I see, alternativly you could include it from the pear/data dir but am not sure how that can happen.

- Martin