Preventing resource access for anyone except a single principal

["Marian Schedenig (qs)" <Ma...@qualysoft.com>]

Hi!

I'm sucessfully using versioning via WebDAV now. To modify a version
resource, it has to be checked out, modified, and checked in again. However,
combined with user access control, the fact that checking out does not
prevent other users from modifying the same resource is rather problematic.
DeltaV provides a whole array of advanced features, but they seem much to
complex to implement within a short time.

What I need is a way to lock a resource when it is checked out, so that only
the user who did the checkout can modify the resource until it's checked in
again. DAV locks are not feasable, since the client would have to keep track
of lock tokens.

My idea for a solution was to extend to server-side DavResource (I had to do
some other modifications to it already anyway) and have it automatically
lock and unlock the resource on checkout/checkin. After locking, the lock
token is store on a subnode of the now checked out resource, and whenever a
resource with such a node is accessed, its token is automatically added to
the session. This allows me to lock, unlock and access resources without
client participation. However, to actually be of any use, I now have to
prevent all users save the one who did the checkout from reading the lock
token. I was going to use a simple ACL, granting full access to the checkout
users and denying all privileges to the "everyone" principal. Then I got an
exception telling me that I can't use deny for groups.

My next attempt was to have the AccessManager check this particular case
before invoking the regular permission management. To read my custom lock
info subnode, I needed the system session (to prevent recursive calls in
AccessManager), provided by a custom subclass of DefaultSecurityManager. Now
I'm actually able to manually check subnodes of a target node, whenever
AccessManager tries to evaluate permissions - only to discover that at this
point, I'm actually getting the *version URL* of the resource being checked
out instead of the URL of the actual versioned resource (where my lock info
node is stored).

I'm beginning to wonder if I'm on the right track here. Can (and should) I
find the versioned resource for my version URL at this point? Or would
perhaps implementing a custom access control policy be a better solution?
Such a policy would be quite simple (grant full rights to one particular
user and deny everything for everyone else), but I wouldn't know where to
begin to actually "plug it in". I figure this might all get simpler once JCR
2.0 is fully finalised and implemented, but for now the final draft seems to
different from Jackrabbit to be of any specific help here.

Thanks for reading, and hopefully replying.
Cheers,
Marian.

-- 
View this message in context: http://www.nabble.com/Preventing-resource-access-for-anyone-except-a-single-principal-tp23079114p23079114.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.