Re: Auth feature

On Mon, 2003-04-07 at 13:43, Yavor Shahpasov wrote: > 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), I don't like passing around yet another parameter. Better use something like Auth::setUseChallenge() or similar. > 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 prefer path I). > Martin Jansen wrote: > > >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. That someone didn't answer my question, but I suppose that there is no need to store non-encrypted passwords, right? > >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. Both of these options are kinda ugly, whilst include("Auth/md5.js") sounds like the less uglier way. - Martin