Josias Thöny wrote:
[...]
Maybe I'm misunderstanding you, but the example I described doesn't
really require to have access control code in the checkPreconditions()
method. The usecase which allows to edit the profile of the current user
just wouldn't use a userId parameter. It assumes that the profile
belongs to the user from the current session.
OK, that is a good idea.
So instead of having a usecase which checks access control by itself, we
have two usecases with different functionality:
1. edit profile of an arbitrary user (this usecase is protected with a
policy)
2. edit profile of the current user (may require to enter the password)
(Of course some functionality can be shared between the two usecases.)
Not sure if this is really good, though. Maybe it just works in this
specific situation.
IMO it sounds very reasonable.
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.
The SoC is better with this approach, but when speaking about overkill,
it may be possible that for most cases a simpler solution exists which
is "good enough".
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?
If we want to allow an admin to change the profile of other users, would
that require a separate usecase?
Yes, I think so ...
-- 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]
