On Saturday 05 March 2005 00:47, Andreas Prohaska wrote: > But even without trusting my client, assume that I have the secured > Account instance in the servlet tier. Now imagine a wizard that allows > the current user to edit the Account, perhaps in multiple steps. > Everyone would agree that it's a common pratice to put the Account > instance into the HttpSession until it's finally saved. > > But since this is an online banking application, we have to use > fail-over, load-balancing superwebservers that use HttpSession > replication (by serializing sessions between servers) and BANG!
I'm unclear _why_ exactly you need Acegi Security (or anything else for that matter) to secure methods and properties on Account domain object instances. As previously mentioned, domain object instances in the UI tier (be they webapp or rich client) are essentially throw-away instances that either (a) get accepted as valid on their return to the services layer and persisted or otherwise operated on, or (b) they are rejected as the principal has insufficient permissions to pass the mutated Account instance to the relevant services layer method. AOP allows you to advise domain object instances, but it's something of a new field and issues such as serialization of advisors from one web container to another is a grey area (I doubt it's done very often or easily). Does the advice look for a local collaborator, or does the container serialize unadvised instances which have advisors re-applied on the target container? It's an area of AOP best practice which sees grey to me; most people are experiencing enough of a paradigm shift getting used to AOP on their services layer. For that reason, if you're keen on using AOP on domain instances, at the very least you should consider which AOP framework you're going to use, which persistence framework, compatibilities between them, and the advice (pardon the pun) of the project team responsible for the AOP framework when it comes to serialization of advisors across containers - particularly in a fail-over-support cluster. For my two cents, I'd focus my energies on using the Acegi Security ACL capabilities properly in this sort of application, enforcing at the services layer boundary. At least you know it's simple, it works, there exists a body of design patterns and samples and people who can critique your architecture, and it is performant. HTH Ben ------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
