Hi everyone,

 

I’ve started work on implementing acegi’s post-invocation security w/ ACLs.  I am also using Spring/Hibernate to handle the data, and tx layer.

 

What I am attempting to do is have the post-invocation “scrub” an domain object (which will have nested domain objects that need to be checked).  Making up an example, we have a Store object which can contain a collection of Item objects.  So when a service call is made load a store #233, the post invocation chain would first check to see if the user has permission to view the Store itself.  Once that is allowed, the check goes deeper into the Store itself, and checks each Item in turn to ensure the proper permissions.  So far it seems to work well.

 

But however, since I am using Spring/Hibernate’s session/tx management, I found out that when Acegi was scrubbing the Store object, the “changes” would be written back to the database by hibernate at the end of the session (due to the automatic flush).  Which in hindsight, is quite obvious that would happen, and is indeed correct behavior by Hibernate/Spring. 

 

My next thought was to move the post-invocation stuff outside the Hibernate/Spring transaction boundary, but then as a co-worker pointed out, I would lose the benefit of having the proper version of data within the transaction when doing the ACL checks against those items.  Nested transactions is an option, but I thought I’d write a email to the list and inquire if anyone else here has run into this situation and perhaps be willing to share a good solution?  Or if there is none, we could discuss this, and contribute to the knowledge base of good Acegi practices, since this issue is likely to come up again when people start to adopt post-invocation more widely.

 

Some options that I thought of.

 

  1. Nested Transactions.
  2. Force an hibernate eviction of object at start of post-invocation chain (clunky though.. we have some straight jdbc calls too so I hate to pollute chain w/ hibernate specific calls).

 

Im hoping others might have ideas as well.

 

-tim

Reply via email to