Hi Kalle, just thought about this some more, and it seems to me that the domain- base security could actually be a special use of instance-based meta data that is created by inspecting the identity of an authenticated user.
We could just added some constraints to ConstrainedBean, for instance 'visible', 'editable', 'removable'. These can then be added when the meta data is constructed, based on for instance the role on an identified user, or any other criteria. The crud layer can use these constraints to adapt the interface, and the GenericQueryManager can use them when executing queries to either reduce the results that are returned, or to make update and delete statements no-ops. What do you think? Geert On 22 May 2008, at 02:44, Kalle Korhonen wrote: > On 5/21/08, Geert Bevin <[EMAIL PROTECTED]> wrote: Hi Kalle, > this is in interesting idea and there's no default support for what > Trail has. However, this doesn't mean that it wouldn't be easy to add > > Which one you meant as an interesting idea - the whole domain model - > based security or owner-instance? Based on > http://rifers.org/wiki/display/RIFE/GuideAuthentication#GuideAuthentication-sect1authenticationsitestructure > > , it sounds like currently it's not possible to set role-type > permissions on the domain model either, is that right? > > something similar. To be able to give you an educated response, would > you mind explaining me what happens when a user is accessing data that > he doesn't have access to? Does the functionality or the entity simply > disappear? If that's the case, it wouldn't be hard to add this to crud > > On view/load, it "disappears", or simply isn't available if > requested as the primary entity. We considered whether it'd be > better to throw some kind of security exception if the data is > available, but the user has no permissions to it, but since it > really would require two operations on the database, we felt that by > default it's better just to hide the data. We consider the situation > to be somewhat similar to "username or password incorrect", i.e. > security-wise it's better not to let the user know which case it is. > On delete/update we throw a security exception if user doesn't have > a permission to execute that operation. > > In Trails, owner-instance security is on by default if user context > is available and it can be "turned off" explicitly if the developer > so wishes, but by default it's on if you use the security feature. > > features of RIFE. We could add meta data to the ConstrainedBean class > that would basically allow you to specify the same information, and > that would then be used by the crud functionalities when the view is > built or the operations are executed. > What do you think? > > To me, it obviously sounds great; I think that domain model -based > security is far more powerful and flexible than url-based. Also, the > way metadata is specified in RIFE would in principle allow more > complex domain-model rules to be specified than what can be achieved > with annotations. > > Kalle -- Geert Bevin Terracotta - http://www.terracotta.org Uwyn "Use what you need" - http://uwyn.com RIFE Java application framework - http://rifers.org Music and words - http://gbevin.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "rife-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rife-users?hl=en -~----------~----~----~----~------~----~------~--~---
