Hi Toby, Thanks for the suggestion! I was initially exploring that route but wasn't sure if I would run into any semantic issues with the two open sessions. It seems I should be able to handle any problems in maintaining the two views that might arise however. Thanks again! Regards, -- Mike
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Tobias Bocanegra > Sent: Saturday, January 21, 2006 9:52 AM > To: [email protected] > Subject: Re: Value based AccessManager? > > hi mike, > one solution is to give a system session to the access > manager that is separate from the one actually accessing the > workspace (user session). > during the save operation of the user session, this system > session still has the 'old' view on the workspace and can be > used to determine the authorization. > > regards, toby > > On 1/20/06, Daglian, Michael (IT) > <[EMAIL PROTECTED]> wrote: > > Hello everyone, > > > > I am having a bit of trouble determining how to use the > AccessManager > > interface to provide authorization rather than > authentication. We have > > a Jackrabbit-external authorization service based upon certain > > attributes of the repository data (the path and declaring > node type of > > the modified item as well as property values - we don't > authorize to > > the individual property level). I can work around the > access manager > > configuration not including a session instance (albeit a > less than ideal solution). > > However, an issue arises when attempting to authorize removal > > operations. Jackrabbit appears only to invoke the access manager to > > check for removal permissions upon save (i.e. in the > > validateTransientItems method of ItemImpl). However, access to > > property values (or even the removed item) at this point isn't > > possible since the item has been removed from the session > (even it's > > state is not very accessible as it's in the attic of the > > TransientItemStateManager). Has anyone else ventured down > this path and come up with a clean solution? > > Apologies if this has been addressed in earlier discussions but a > > search of the archives did not yield anything. > > > > Regards, > > > > -- Mike > > -------------------------------------------------------- > > > > NOTICE: If received in error, please destroy and notify > sender. Sender does not waive confidentiality or privilege, > and use is prohibited. > > > > > -- > -----------------------------------------< > [EMAIL PROTECTED] >--- Tobias Bocanegra, Day > Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 > 226 98 98, F +41 61 226 98 97 > -----------------------------------------------< > http://www.day.com >--- > -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.
