jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maxim <maxi...@anahoret.com>
Subject Re[2]: User permissions in JCR
Date Wed, 01 Jun 2005 14:58:28 GMT
Hello jackrabbit-dev.

At first I thank Jukka Zitting for his elaborate comment. Since JCR
specification is finalized, I do not expect any changes in API soon.

But the question of proper implementing of user permission in JCR is
still open.


Wednesday, June 1, 2005, 5:12:50 PM, Jukka Zitting wrote:

>> If, as JCR states, permission system is left up to implementation,
>> then is such application forced to used some proprietary API to set
>> permissions? Doesn't this compromise entirely a concept of "switching
>> repository implementations" and avoiding vendor lock-in?

> There are a number of applications that never need to manage access 
> control settings, or handle more fine-grained access settings using 
> application-level flags or ACLs.

> Do you have some specific use case in mind? It would be interesting to 
> discuss the "correct" way to implement such "permission-intensive" 
> applications on top of JCR.

Consider an enterprise-level web-based knowledge management and
collaboration tool, similar to Wiki but hierarchical, with all data
stored in JCR. Various types of users (e.g. managers or editors)
should be able to set permissions for newly added or existing folders
to enable proper level of disclosure of sensitive data.

In a such dynamic environment various working groups are created and
disbanded often, and usually such groups has their own space (folder)
in repository with write access while some other groups may have read
access to this folder.

As far as I can see, such application will inevitable use an extended
(proprietary) API to allow each user to set permissions.

Notably CRX, a commercial product of Day Software contains its own
(apparently nonstandard) implementations of permissions based on
ACLs.


For the next generation of JCR (maybe JCR 2.0) I can only suggest to
consider adding an AccessManager interface similar to QueryManager
with a few built-in implementations. These could be
- simle superuser/anonymous, like currently in Jackrabbit
- UNIX filesystem,
- NTFS filesystem (ACLs based)
- Generic ACLs (similar to Day implementation)

So applications will be able to either choose form existing variant or
implement their own scheme.


It would be interesting to hear some comments in this issue.

Thank you.

-- 
Best regards, Maxim.
Anahoret Team.


Mime
View raw message