administrator wrote:
Thanks Ben,
What I'm trying to do on a functional level is quite straightforward.
The application that I am writing is intended for the real estate business.
In this business a sales agent will only be able to view/edit properties that he/she has been assigned/brought into the company.
So when for example an agent does a search for houses they should only be returned those that they are in charge off.
Hi Bryan
The way I'd approach this is to use as much Acegi Security infrastructure as possible. Whilst you could use your own SystemUser object etc, unless there is a compelling value-add you will have to maintain it when there is likely an already functional alternative maintained as part of Acegi Security. Specifically, the UserDetails interface and the User implementation of same can store your authenticated user information. This will be available from the ((SecureContext) ContextHolder.getContext()).getAuthentication(). Is there any particular reason you wouldn't want to use these classes?
As for the access control list (ACL) part, you'd use the new net.sf.acegisecurity.acl.basic package. This is discussed in the 0.6 reference manual, although there still isn't a sample application. Essentially you'd use the JdbcDaoImpl which retrieves ACLs from a JDBC backend. You'd then use the AclProviderManager as your AclManager implementation, which is wired to a BasicAclProvider, and in turn that is wired to the JdbcDaoImpl. You'd then write a custom AccessDecisionVoter which has a reference to the AclManager bean. The AccessDecisionVoter would check with the AclManager to ensure the Authentication object has access to the presented real estate property. If access is denied, the AccessDecisionVoter would throw an AccessDeniedException. That's all fine for working with specific real estate properties, but in terms of getting a list of real estate properties that users have access to, you would probably be best to write a MethodInterceptor which inspects a returned List and mutates it to remove real estate properties to which the user has no access. Thus it could be used with any of your finders, as it is a cross-cutting concern.
In relation to the Hibernate filters, yes, it seems like they would work if each real estate property could only have a single salesperson. But for the sake of spending a little time writing the MethodInterceptor and setting up the ACL package, you'd have much more flexibility (eg >1 salesperson per property, hierarchy perhaps based on locations of the real estate properties, hierarchy perhaps based on internal sales teams, allowing clients to edit their property details over the web, permitting limited access to certain real estate properties by other team members and so on).
Best regards Ben
------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
