On 5/22/08, Geert Bevin <[EMAIL PROTECTED]> wrote:
>
> > 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.
Yes, with owner (in owner-instance) I mostly refer to the current user;
generic instance-based permission rules as just too hard; many have tried
and failed. In Trails though, the current implementation is a bit bolted on
since we are using JPA/Hibernate. However, the annotation-based rule
declaration is simple and generic; for example @ViewRequiresAssociation,
@ViewRequiresAssociation("owner") where "owner" refers to a property "owner"
in that object. (Comparable to @ViewRequiresRole("admin") )
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.
No, this is not for crud-only; you can use it with any persistent entity.
Although, I'm not quite sure what you mean by "crud related stuff", what
other operations are there in a database-driven web app? (Well, maybe CRUD+S
- Trails offers Lucene integration, Hibernate's Criteria API and HQL/SQL for
the last letter). But if you mean RoR-style starter pages and flows, then
no, Trails doesn't generate any scaffolding. Trails provides usable defaults
for component-oriented, domain-driven web development, but you can customize
the CRUD operations to your heart's content. The caveat is that Trails is
heavily Tapesty-centric; which some people like, some don't.
> 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.
In Trails, we really view it as an association; the instance-based
permission model is based on assocating instances one way or another with
the current user. For example; you can be allow to view your wife's data -
you are not quite an owner :), but somehow associated with her. Anyway,
that's what I was referring to earlier; arbitrary association-based
permissions can be too complex to support in a generic way if you don't tie
one end to the current user.
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.
Sure, that's probably a good starting point. And just a note; I didn't want
to make this a blurb on Trails, but that's where I'm coming from. That said,
I don't particularly care which web framework I use and while I'm very happy
with my domain-based permission model in Trails, web conversations have
proven to be a tough nut to crack generically with a conventional web
framework. My three main issues with web development are security, ajax and
conversations; and since RIFE uniquely and rather convincingly solves the
last one, maybe I can find a decent solution for the other two in RIFE
rather than trying to figure out elaborate, yet complicated solutions for
conversations in conventional web frameworks (be it Tapestry, JSF, Seam or
Spring WebFlow).
Kalle
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
