security question: Foo interface vs. TurbineFoo implementation

[Finn Smith <fs...@nntllc.com>]

Playing around with the security in the sample app I found that I could not
update the name of a User, Group, Role, or Permission. Attempting to do so
with the standard issue Flux templates and classes results in an error. This
is because the Action classes which implement the update behavior use the
name field of these security objects to retrieve them from the
TurbineSecurity service.

Security in Turbine has been implemented in such a way that the  Turbine
programmer is encouraged to use the standard security interfaces (User,
Group, Role and Permission in the org.apache.turbine.om.security package)
rather than the actual classes that implement these interfaces (the
equivalent TurbineUser, TurbineGroup, etc. in the same package). This makes
sense, and is a good modular design which allows for the implementaion of
whatever underlying security system that you want, but it prevents you from
using a security object's underlying database primary key to access it. You
could cast the security object e.g. (TurbineGroup)Group, but this seems
pretty hacky to me.

Other than casting, the only solution to the above problem I can think of is
to use a hidden form field in the *.vm template to keep track of the old
name, then submit the new name along with the old name. This way the Action
can retrieve the security object with the old name, change the name field,
and then save the changes. Besides the fact that this also seems like a
hack, it doesn't work. Apparently, the name is stored in more than one
place, as I could get a change I saw on my webapp site, but when I looked in
the GROUP_NAME column in the TURBINE_GROUP table it was still the old name.

Can anyone think of a nicer way to get around this limitation in the
security design? Or is the choice to do this in an ugly way or not do it at
all? Is it necessary to delete a security object and create a new one if all
you want to do is change its name?

Thanks,
-F


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org

Re: security question: Foo interface vs. TurbineFoo implementation

[Jon Stevens <jo...@latchkey.com>]

on 8/16/01 2:03 PM, "Finn Smith" <fs...@nntllc.com> wrote:

> Playing around with the security in the sample app I found that I could not
> update the name of a User, Group, Role, or Permission. Attempting to do so
> with the standard issue Flux templates and classes results in an error. This
> is because the Action classes which implement the update behavior use the
> name field of these security objects to retrieve them from the
> TurbineSecurity service.
> 
> Security in Turbine has been implemented in such a way that the  Turbine
> programmer is encouraged to use the standard security interfaces (User,
> Group, Role and Permission in the org.apache.turbine.om.security package)
> rather than the actual classes that implement these interfaces (the
> equivalent TurbineUser, TurbineGroup, etc. in the same package). This makes
> sense, and is a good modular design which allows for the implementaion of
> whatever underlying security system that you want, but it prevents you from
> using a security object's underlying database primary key to access it. You
> could cast the security object e.g. (TurbineGroup)Group, but this seems
> pretty hacky to me.

The other problem is that systems such as LDAP (which Turbine has the goal
of being integrated with...work has started, but is not complete...see
LDAPSecurityService) have no concept of primary keys. You could also write
things to retrieve the User information via XML-RPC from an entirely
disassociated system. Again, another case of not necessarily having a PK.

> Other than casting, the only solution to the above problem I can think of is
> to use a hidden form field in the *.vm template to keep track of the old
> name, then submit the new name along with the old name. This way the Action
> can retrieve the security object with the old name, change the name field,
> and then save the changes. Besides the fact that this also seems like a
> hack, it doesn't work. Apparently, the name is stored in more than one
> place, as I could get a change I saw on my webapp site, but when I looked in
> the GROUP_NAME column in the TURBINE_GROUP table it was still the old name.
> 
> Can anyone think of a nicer way to get around this limitation in the
> security design? Or is the choice to do this in an ugly way or not do it at
> all? Is it necessary to delete a security object and create a new one if all
> you want to do is change its name?

    Yes.

-jon


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org