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 information from the
> Request and for security reasons we have to remove them from
> the "org.restlet.http.headers" attribute Map. I think that
> only as few as necessary classes / objects should have access
> to the secret informations. But I now, that we change the
> Request object, that should describe the request as it came
> from the client.
What is useful in keeping the challenge response intact is that a request
can be forwarded to another local application for example without having to
change anything. Also, there will always need to be a high level of trust
within a Restlet application. The Restlet component should however shield
each application from others, unless there is an explicit need for
communication.
Maybe another way to achieve way you suggest would be to add an option in
Guard to clear the secret once authentication is done but I'm not really
sure that this is really useful (for the trust reason I gave before).
> * Add a boolean attribute "authenticated" to
> ChallengeResponse. The Guard can set it to true and set the
> secret chars to '\0' or whatever and set the array to null.
You can also image scenarios where several Guard are chained an need to
authenticate a request at several levels. The "authenticated" info wouldn't
be useful.
> * Add a new attribute "authenticatedUser" to the Request
> from type of a new class AuthenticatedUser (for example).
> This class conatins by default only the identifier of
> ChallengeResponse, but the class can be exended from every
> deveolper. If we use a changeable factory to create it, than
> the default Guard class can create the AuthenticatedUser
> subclass. Another way is to give the Guard the
> AuthenicatedUser subclass and the instantiated this class
> itself by the reflection API.
I'm not sure about the use cases we would solve with this changes. Also, I
tend to favor keeping the number of classes as low as possible in the API.
> * If we don't want to change the request, we can add some
> util methods (perhaps an own Util class), which stores the
> autenticated user's information object in the Request as an
> attribute, like Alex wrote.
Yes, I think attributes are the perfect place to put such information, you
can add a user "role" or any other application specific info about your
authenticated user.
Best regards,
Jerome
