On Jun 12, 2008, at 7:51 AM, Lionel wrote: > Lionel wrote: >> Etienne Bernard wrote: >>> Hi Alan, >>> >>> Personnaly I would use hibernate filters to automatically add the >>> where >>> clause. >> >> Filters work fine for criterias and queries, but they are not applied >> on a session.get or session.load... >> You still have to check the customerId manually > > You can try to implement org.hibernate.classic.LifeCycle and check the > customerId in doLoad. > Throw an exception if it does not match. > > I don't now if it's the best approach, but it's easy to code and it > seems to > work. > doLoad seems to be called before any action (load/insert/update/ > delete).
Ultimately, I created an Interceptor. During ActionBeanResolution it takes the account slug from the path... http://domain.com/stripes/PublicationEdit.action?publication=5 The slug is "stripes". It looks up the account id. No account id and it returns the default resolution, which then goes on to run the normal Stripes URL bindings. If it finds an account it performs some simple checks. It checks if there are any account parameters like... http://domain.com/stripes/PublicationEdit.action?publication=5&account=3 ...and matches it up to the account id of the account with the URL slug "stripes". If anything looks wrong, it returns an ErrorResolution with a 404. Otherwise, it tucks the account id into a request attribute returns ForwardResolution. If it's a GET or HEAD it adds the account = id to the query string. Then after BindingAndValidation it looks for ActionBean properties that implement an Accountable interface. The Accountable interface will check that the account of the object matches account of the slug. If it doesn't, it returns a 404. All of my ActionBean classes derive from a base class that has an account property. All of my domain model objects implement Accountable except for the Account entity. Then I had to create my own FormTag, so that I could specify the account slug and have the form correctly generated and the proper ActionBean resolved. I use my custom form tag when only for forms that are using the account slug. It subclasses the Stripes FormTag and fixes up the URL binding. And I'm back to coding with minimal ActionBean code for CRUD with Stripersist. If anyone trys to plug in arbitrary ids it's treated as if they were asking for objects that didn't exist, which is pretty much how it would be if there were not Account entity. There are only a few places where I need to modify queries to say "where acount.id = ?". I could use Hibernate filters, but that makes my JPA code Hibernate specific. This is going to be a matter of discipline (and security) but I suppose the one database many accounts implementation will always carry this concern. It was not at all difficult to do this with Stripes. It probably could be generalized. Maybe something for 1.6. Powerful framework. Sociable community. Stripes is fun. -- Alan Gutierrez | [EMAIL PROTECTED] | http://blogometer.com/ | 504 717 1428 Think New Orleans | http://thinknola.com/ ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Stripes-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/stripes-users
