March, Andres wrote:
Ahh, I see now. This is like a permission type. I debated this idea
here but could not find a use for it. I could not see how it would add
info to what the permission meant. It seems that the recipient,
accessed object, and mask conveyed everything I need to. I was planning
on leaving it to the security framework to interpret the class of
permission on the fly. In this way it is also polymorphic in nature.
Different domain objects are likely to have very different permission
meanings. A BankAccount object would have permissions like allowDeposit,
allowWithdraw, allowBalanceCheck, allowClosure. A Folder object would
have permissions like create, delete, read, write and execute. It's
better to provide a concrete class that reflects the possible
permissions, which bit represents which permission, and easy getters to
whether a permission is granted. Thus relying classes simply call
AclManager to get the AclEntry[]s, cast the AclEntry to the appropriate
concrete class, and call the respective getters (eg isAllowDeposit,
isAllowWithdraw). Enabling this behaviour requires the extra acl_class
column.
Is this easier to implement than just putting this info into the
object_identity table? Or is it better because you have a clear
division between recipient and domain objects? This design is
constraining to use cases such as mine but I can see the clarity in
doing this. I figure on implementing my own dao anyway. I am using
hibernate.
Indeed. The problem from a security framework design point of view is
that fuzzy line between what belongs in the framework and what belongs
in the realm of end developer responsibility. I can some applications,
like yours and say LDAP directories, do need to treat users and roles as
both recipients and domain object instances. The grey line is whether
that's "mainstream" enough to make the base JDBC implementation support
it or not. Whether it belongs in the framework or not, we must ensure
the base JDBC class is modular enough (in terms of protected methods)
such that it _could_ be done without writing a DAO from scratch. Do you
believe the existing JDBC DAO provides enough flexibility in this regard?
Ben
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Acegisecurity-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
