Josias Thöny wrote:
[...]
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.
This is certainly an option from a feasibility point of view, but
IMO the functional aspects of a usecase should be clearly separated
from the access control aspects. Therefore I'd like to avoid putting
access control related code in the checkPreconditions() methods.
That's why I suggested to delegate the access control functionality
to condition classes, which could be used to protect arbitrary usecases.
But maybe this is overkill, see below.
That's what we want to do with the password usecase. It's maybe not very
generic, though.
The UserPasswordWithCheck usecase has built-in protection because
it checks the existing password. This ensures that nobody can change
your password when you forgot to log out. Maybe we should just add an
"Enter password" field to the profile page as well?
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED] [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
