On 5/22/08, Geert Bevin <[EMAIL PROTECTED]> wrote: > > 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.
Yes, that absolutely sounds like the right approach. Again in Trails, we figured we can divide (the security) meta data in three categories; static (such as role-type), instance-based (such as our owner-instance) and dynamic (new rules can be placed or removed; often application-specific ACLs). This is important (at least in Trails) so you know what part of metadata can be cached and when it needs to be re-built. 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? Sounds good at least in theory, now somebody just need to implement it :) I'll take a look at these classes and open JIRA issues based on my experiences and how I could see it working in RIFE (without intimate knowledge of your framework). Kalle 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 -~----------~----~----~----~------~----~------~--~---
