Hi Stephan,
Somehow, I didn't get this email before. It doesn't appear in the archives
either, so it was probably lost on the way. Anyway, thanks for forwarding it
again :)
Yes, I think attributes are the perfect place to put such
information, you can add a user role or any other
Hi,
Now all the logic specific to authentication schemes is delegated to
the Engine. It will now be easy to add pluggable authentication
modules.
That's great to hear.
Support Acegi
http://restlet.tigris.org/issues/show_bug.cgi?id=264
The project for which I'm using Restlet uses Acegi
Hi Stephan,
I think, you are not the only one who wants to save
information about an authenticated user in the Request.
Perhaps we can store some information about the
authentication state in the class ChallengeResponse or somewhere else.
Than we can perhaps delete the secrets
Stephan Koops Stephan.Koops at web.de writes:
Multiple times I've found myself needing the Request instance in
checkSecret()
on Guard so that
I can store the authenticated user's information on the
Request as an attribute. That allows me to later use it in authorize().
Add a new
On 1/4/08, Kevin Conaway [EMAIL PROTECTED] wrote:
Perhaps some kind of hook would be appropriate in authenticate().
Adding that kind of behavior to checkSecrets() feels bolted on to me
because checkSecrets() now becomes check secrets, but maybe do some
other stuff too
Perhaps in
Multiple times I've found myself needing the Request instance in checkSecret()
on Guard so that I can store the authenticated user's information on the
Request as an attribute. That allows me to later use it in authorize().
Maybe we need to add another method with this implementation:
public
/4/08, Alex Milowski [EMAIL PROTECTED] wrote:
Multiple times I've found myself needing the Request instance in
checkSecret()
on Guard so that I can store the authenticated user's information on the
Request as an attribute.
7 matches
Mail list logo
