So far I like the use of the Decorator pattern that Dan D. suggests
below the best.
Dan Diephouse <[EMAIL PROTECTED]> writes:
> 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]>
