Hi Stephan, Thanks for the patch, I've applied it with some refactoring to SVN trunk.
In case you don't want to decode the password, there is always the possibility to override checkSecret() directly. Another option would be to encode the received password (using MD5, SHA, etc.) so that the default checkSecret() logic would work unchanged. Best regards, Jerome > -----Message d'origine----- > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Envoyé : lundi 25 février 2008 11:40 > À : [email protected] > Objet : Re: Guard > > Hello Jerome, > >> what about put the javax.security.Principal in the request > attributes > >> after successfull authentication? > >> > > This is a possibility, maybe a good compromise that would > also you to get > > rid of your subclass? > > > Yes. I've created a patch and attach it to this email. > > Your implementation of "findSecret(id)" can perfectly > retrieve an encrypted > > password in a database, decode it and return the password > in clear, just for > > the time of the verification. > But than you have to save the password decryptable. If you put the > password hashed with a Crypto hash (MD5 or SHA) into the > database, than > it could be undecryptable by anyone. It has the advantage, > that no one > with access to the database (allowed or criminal attack) > could get the > password. > But that's not the point for my thesis :-) > > best regards > Stephan >
