On 1/18/02 8:11 PM, "Daniel Rall" <[EMAIL PROTECTED]> wrote:
> So far I like the use of the Decorator pattern that Dan D. suggests
> below the best.
I too believe this is the only real viable solution and the only one that
I'm really in favour of. As I've mentioned in previous posts: there's no
reason why we can't have some default implementations, but I don't think
there's any way we're going to come up with a security scheme that will
accommodate every scenerio. The Strategy pattern coupled with the Decorator
pattern is a great solutions.
The valves are pluggable now in Turbine 3.x and right now we have a
DefaultACLCreationValve (bad name, I know)
And this is where someone can push whatever they want into RunData, couple
that with a customized base Module with convenience methods for your
particular security setup and you're off to the races. Or a SitePolicy which
I'm going to try and whip up.
This setup is totally flexible and will allow us to build up a small
collection of implementations that can either be used in their entirety or
will be a great place for people start.
+1
> 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]>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
