Hi Kalle, > 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?
Domain-model based security. The owner instance one feels a bit bolted on to me, not sure if it's worth explicitly supporting this. It seems to me that by adding the domain-model based security to RIFE's meta data system, the owner instance based one is covered too, since the meta data is handled on an object instance base. > 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. Sounds good. Can you please confirm that this is only active for crud related stuff in Trails (not even sure if Trails even does something else). I'm thinking that I might actually make this more generic and add it both to crud for generating the interfaces and to the GenericQueryManager when database operations are performed on the domain model. This could make this security model more applicable in general. > 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. That will probably not be the case if this gets implemented by RIFE since there's no standard concept of an owner or which instance is owned by who. > 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. Would you mind adding this as an issue to Jira, with possibly some ideas of how you would want to use this in RIFE (pseudo code samples). Since you have first hand experience with domain-model based security from Trails, you can probably suggest good approaches to do this with RIFE from a user's perspective. Thanks, Geert -- 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 -~----------~----~----~----~------~----~------~--~---
