In our model, the lazy approach wouldn't have bought us too much since we have rich clients, meaning that all service invocations happen remotely. One of our goals was to prevent sensitive information from even being transmitted to the client. This means that we would have had to apply the lazy ACL before transmitting the objects to the client anyway. We considered the caretaker approach at first, and I think it is a very good idea. The downside is that it would require you to either define a different access strategy for your domain objects (instead of plain POJO get/set methods) or proxy/AOP your domain objects. This is perfectly acceptable in many cases, and again, is a good solution. In our case it would not have interacted well with other requirements.
- Andy On Thursday 10 February 2005 07:58 am, Tim Kettering wrote: > I am quite relieved to find that I'm not the only person facing this issue. > > The discussion so far is quite invaluable and I hope we can continue this > thread. I have tried looking at Hibernate Interceptor, but I don't think > it is the ideal solution because not all of my objects are obtained by > Hibernate (most of them are, but not all). So I need whatever solution > that I ultimately go with to work outside of Hibernate. > > To me, it seems the following conditions are important if we are looking at > "scrubbing" the object instance. > > 1. ability to apply specific security to variable, or method level > granularity. > > 2. persistence strategy independent. > > 3. ideally participate in the same transaction as the data load itself to > guarantee a consistent version of the data. > > For the last option - however, if a caretaker pattern is applied, then > caretaker implementation itself might choose to take a more lazy-load > approach, not actually checking ACL permissions until the method is > actually invoked. Is that a feasible option? This particular approach > would happen outside the transaction though, so there could be a mismatch > in the database object graph and the instanced object. > > -tim > > > > > > I have previously played with GCLIBing domain object instances, but that > caused some complications with Hibernate. In the end that's what > motivated me to write the AspectJ integration, but I was disappointed by > the poor incremental compilation reliability in the Eclipse IDE. That's > going back probably six months, so it might have improved and using > AspectJ is a realistic/viable option for a "caretaker"-style solution to > method invocation. > > Alternatively, I am just wondering if a Hibernate Interceptor > (http://www.hibernate.org/hib_docs/api/net/sf/hibernate/Interceptor.html) > might be able to help in this case? It seems to offer the necessary > hooks to introspect the object. > > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Home: http://acegisecurity.sourceforge.net > Acegisecurity-developer mailing list > Acegisecurity-developer@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
