Alex, We use a similar model 2 setup -- single user repository access.
For finer grained object access control we're using Acegi AOP filters. While this means that a given query against the JCR will likely return more objects than a user has access to, and thus must be iterated over again to perform the filtering, it keeps our DAO layer completely free of any authorization/access control logic. Further, we store permissions as a property of the object itself, so the ACLs that the Acegi filters require can be created on-the-fly from the objects retrieved from JCR without need for a separate/synchronized ACL storage or a separate JCR session and custom AccessManager. I'm not suggesting that Acegi and/or AOP are better solutions for JCR object access control, just an alternative that works for our application. HTH, Doug On Nov 27, 2007 1:28 AM, Alex Lukin <[EMAIL PROTECTED]> wrote: > Hi there! > > Monday 26 November 2007 18:27:23 Jukka Zitting написав: > > Hi, > > > > Personally I'd recommend allowing only a single concurrent thread to > > use a session. Even though multiple concurrent threads may work fine > > with current Jackrabbit, this hasn't really been very well verified > > and some of the cache data structures might well hide serious > > concurrency issues. It is also possible, perhaps even likely, that in > > some future release Jackrabbit will start explicitly synchronizing > > access to a session to simplify and streamline internal locking > > mechanisms. > > > > BR, > > > > Jukka Zitting > > That sounds very good because as for me it is good idea to keep in sync > HttpSession and javax.jcr.Session. May be I'm wrong but anyway... every > application that cares about rights on repository data must associate web > session with JCR session. > > I use model 2 repository with container authentificatoion. At this stage > of > development I use single user for repository access but I need more > fine-granted security on repository. > > When I need to aquire JCR session usualy I need login and password, but I > do > not have password, it is "swallowed" by container. Is there standard way > to > get JCR session from J2EE container for already authenticated user with > the > same user principial as authentificated Http session? > > Thanks, > -- > SY, Alex Lukin > RIPE NIC HDL: LEXA1-RIPE >
