Hello Alex,
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().
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.
Some concrete alternative proposals for a generic way to handle users
information:
* 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.
* 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.
* 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.
What do you think? If the community agrees about one proposal I can
implement it.
best regards
Stephan
