On Wed, 2006-06-21 at 17:21 +0200, Andreas Hartmann wrote: > 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.
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. 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. > > 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? Josias > > -- Andreas > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
