On Wed, 2006-06-21 at 17:04 +0200, Thorsten Scherler wrote:
> El mié, 21-06-2006 a las 15:22 +0200, Andreas Hartmann escribió:
> > Hi Lenya devs,
> >
> > at the moment, it is not possible to protect a usecase from
> > being executed with certain parameters, e.g. it is possible to
> > call
> >
> > lenya.usecase=admin.userProfile
> >
> > for any user ID.
> >
> > We chould hard-code the protection in doCheckPreconditions(),
> > but IMO this violates SoC. Is there a better way to solve this
> > problem?
> >
> > BTW, in 1.2 it was solved by using URLs for users, like
> >
> > /admin/users/john.html
> >
> > and add/remove policies accordingly when a user was added/removed.
> >
> > IMO treating users as "repository objects" and apply policies
> > to restrict permissions sounds appealing, but it leads to some
> > problems:
> >
> > - the policies have to be added explicitly
> >
> > - the user repository items are "self-referencing", i.e. to
> > create the user item properly you need the reference to the
> > user item to set the policies
> >
> >
> > Alternatively, we could add some logic to usecase-policies.xml:
> >
> > <usecase id="admin.userProfile">
> > <condition class="o.a.l.cms.ac.conditions.CheckCurrentUserId">
> > <!-- map the usecase parameter to the condition parameter -->
> > <parameter condition="userId" usecase="userId"/>
> > </condition>
> > </usecase>
> >
> > public class CheckCurrentUserId implements Condition {
> >
> > public boolean isComplied(Map parameters) {
> > return parameters.get("userId").equals(getUser().getId());
> > }
> > }
> >
> >
> > Or is there a simpler solution?
>
> Not sure but the user needs to be part of the admin group, right?
>
> The user is contained in the session, right?
>
> Then we need to check in the precondition whether the current user is in
> the admin group, if not add a errorMessage.
>
> Did I miss something?
The problem is that non-admin users should be able to edit their
profile, but not the profile of other users.
Only admins may edit the profile of other users.
Is it an option to have different usecases for these two situations? One
usecase is for admins only and allows to edit data of any user. The
other one is accessible for anybody, but only allows to edit the data of
the current user.
That's what we want to do with the password usecase. It's maybe not very
generic, though.
Josias
>
> salu2
> --
> thorsten
>
> "Together we stand, divided we fall!"
> Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
