Gonzalo A. Diethelm wrote:
>These are all good points. That got me started thinking that perhaps
>we ARE trying to do too much with Turbine's security system. Perhaps
>we should just focus on answering the following questions:
>
>* Are these credentials valid for this user?
>* Change the credentials for this user.
>* Does this user have this capability?
>
Question: Don't those depend on the security scheme? Let me explain.
Consider "Are these credentials valid for this user?" The only way to
test that is to do something like data.getACL().hasPermission(). But,
if I don't have permissions in my scheme, I'm screwed. Once again there
is no standard way to change credentials.
I think the only thing Turbine needs to worry about is the User object
and associating it with the session.
I suppose we need something like this.
interface Credentials {}
interface User {
getName() // Or get Id, or something...
}
interface SecurityManager {}
Then in the rundata object, instead of a getACL(), we have
getCredentials(). And on go on my merry way using my own security
scheme I specified in my TR.props,
security.credentials.class=com.somewhere.project.security.CustomCredentials
security.manager.class=com.somewhere.project.security.CustomSecurityManager
security.user.class=com.somewhere.project.om.TorqueUser
Notice there are no standard methods in the interface except getName()
in the User object. It could also have the getCredentials method if you
wanted. We could then distribute custom security implementations.
Are there other places where the security system is used that I'm not
thinking of? We really don't have much to worry about. Just the
RunData object.
- Dan Diephouse
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
