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 On 20 May 2008, at 20:03, Kalle Korhonen wrote: > > > Talked to Geert a bit in IRC, but basically my question was about > > the domain model-based security in RIFE. My experience has been that > > typically offered role-based security is not flexible enough, but > > "owner-instance" (my concept) solves about 90% of the remaining > > cases. Basically, I want to be able to secure access to user's own > > profile or automatically get only things user owns (or is > > "associated with") from all things available, so I see no point > > trying to secure access to some specific urls as the permissions > > depend on the instance rather than type. I've implemented and used > > the concept very successfully with Trails ( > http://trailsframework.org/Security+module > > ) - basically only requiring me to add a single annotation on my > > domain entity to establish a permission that allows only the current > > user to access the entity. Unfortunately for me, Tapestry (or any > > other standard framework) doesn't have a built-in support for > > conversations (of which I've also written about in > http://docs.codehaus.org/display/TRAILS/2008/01/24/Full+Steam+ahead+with+Trails+2.0%21 > ) > > which of course is the bread and butter in RIFE. So, I wonder if > > RIFE supports domain-model based security and how is it done in > > practice (e.g. can you add these rules to the metadata)? I didn't > > find anything much about it from the documentation, I'd appreciate a > > link if I missed it. > > > > 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 -~----------~----~----~----~------~----~------~--~---
