Le lundi 08 février 2010 03:23:14, Rickard Öberg a écrit : > I have some concerns regarding the above, which are more general > thoughts on RBAC. > > Typically you will never want to couple code to application specifics > such as users (RequiresUser above) and roles (RequiresRoles above). It > is much better if you can create any user which can use any > application-defined role, which then implies application-specific (and > hardcoded) permissions. So you might have "rickard" user, with an > application-defined (i.e. defined by USER of the app, not the developer) > role "administrator", which implies the "user administration" > permission. Then you can check for "user administration" permission. > Don't check for "rickard", and don't check for "administrator". > > So I personally would remove the RequiresUser and RequiresRoles above, > and stick with the guest/authentication/permissions annotations.
I totally agree that RBAC system must not interfere with actors domain modeling. Shiro agrees too :) @RequiresUser do not takes any parameter and states only that the target element requires that the current Subject is an Authenticated User, not that it is a particular user you specify. And yes, this is much better to use @RequiresPermissions that @RequiresRoles but as Shiro provides it, I just wrote it. Now, I plan to write a custom Shiro Realm for my app, and will try to extract a sort of AbstractQi4jRealm. It should provide boilerplate code for implementing custom Realms loading authc & authz data from qi4j Entities, whatever the domain model you have. Paul _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
