Hi,
Maxim wrote:
It looks like my previous post was missed,
so I will try to ask my question again.
Sorry about that. I think that most of the Jackrabbit developers are
currently heavily involved in making JSR 170 final. I'll try to answer
the best I can.
In Jackrabbit current implementation of access permissions
(org.apache.jackrabbit.core.security) it is only possible to have "all
permissions" (superuser) or "read-only" (anonymous) session.
Is it planned to add more flexible permission system to Jackrabbit, so
it will be possible to have different permissions for different nodes,
for the single session.
You are right in that the current SimpleAccessManager implementation
only supports a very coarse permission set. However, the idea is to
extend the SimpleAccessManager to support a more fine-grained set of
JAAS permissions. How and when this will be done is still an open
question, you should file an enhancement request in Jira if you want to
speed up the process.
In addition to the default JAAS access manager, it is possible to
implement custom access control mechanisms by implementing the
AccessManager interface. There have been a few questions about this on
the list before, it would be nice to hear about any
succeses/difficulties people have experienced with this approach.
Another JCR question is not Jackrabbit specific. Consider an
application which uses some JCR implementation and this application
requires setting permissions for nodes on behalf of its users. As
there is no API to set user permissions for nodes specified in JCR,
which API should be used in such application?
Access control is in general a very complex issue, and I think that the
API is correct in not trying to mandate a single solution. It could also
be argued that access control is a management function just like node
type management that also is outside the scope of JSR 170. I think that
JSR 170 is correct in specifying the effects of access control
violations (javax.jcr.AccessDeniedException, etc.) but not the mechanism
for modifying or even querying access control settings.
> 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.
BR,
Jukka Zitting
