on 8/16/01 2:03 PM, "Finn Smith" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
