On 6/27/08, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Hi Andreas, > > I also consider the "separate workspaces" approach best. In particular it > lends hand to an extended solution if you decide to complete separate author > and staging, where you have two distinct repositories and replicate data > from author to staging. > > Access Control handling depends on the JCR repository implementation. > JSR-170 (JCR 1.0) does not have any standardized ACL (except a single call > to check for access). JSR-283 (JCR 2.0) will bring standardized ACL. Still, > how this is implemented remains - of course - unspecified. > > IIRC the approach taken in Jackrabbit is to attach ACL child nodes to the > nodes to which access control is applied. So if you replicate (workspace > update, cross-repository replication) any node (or subtree) and include the > ACL child nodes in the replication, you get the same access control on both > sides. in an upcomming version of jackrabbit that will implement some features of the to-be-released JSR283 spec, there will also be a user-based hierarchical access control. this usually suits better for CMS application, since CMS authors are usually authorized to maintain one subtree of the site. that hierarchical user-based ACLs will be stored per-workspace, i.e. if copying a node to another workspace, the same user can have different ACLs. This makes sense, since a content author might not be allowed to alter content on the staging or even the live workspace. with a document-based ACLs you would need to remove/alter them 'manually' when copying them to another workspace. however, this might not be a big problem, if you define some ACLs on the respective parent nodes, because the privileges get inherited to the child nodes.
regards, toby > > For the workspace update mechanism, you don't have to care for the user > setup as users are stored repository-wide in the system workspace. For a > cross-repository replication you have to take care that the user base > matches on both repositories, of course. > > Hope this helps. > > Regards > Felix > > > Andreas Hartmann schrieb: > > > Hi Felix, > > > > > Andreas Hartmann schrieb: > > >> is it possible to access multiple JCR workspaces via a > > >> Sling application? > > > > > > Basically yes. Your application may grab the Repository (or > > > SlingRepository) service from the service registry and login to the > > > repository specifying different workspaces to access. > > > > thanks for your answer, it's good to know that accessing multiple > workspaces is possible. > > > > I'd be interested in your opinions about the correct approach to a staging > environment like it is provided by traditional CMS applications. I see the > following options: > > > > Separate workspaces > > =================== > > * Corresponding nodes with same UUID possible > > * Updating nodes/subtrees possible > > * Question: How are access control settings handled? > > > > Separate areas in a single workspace > > ==================================== > > * No corresponding nodes with same UUID possible > > * Maintaining access control definitions could be complicated > > * Updating nodes/subtrees has to be implemented > > > > Separate areas as child nodes > > ============================= > > * Areas not self-contained > > * No direct URI-to-path mapping possible > > > > Labelled versions > > ================= > > * Changes applied immediately, without calling Session.save() > > (might be a problem wrt transactions) > > * Access control to version history has to be considered > > > > > > My gut feeling tells me that separate workspaces are the most promising > approach. But I don't know how the access control settings (in this case, > permissions to change properties of particular nodes) are maintained across > workspaces. Would they have to be kept in sync manually? > > > > Is there a general best practise to model this kind of functionality? > > > > Thanks a lot in advance for any hints! > > > > -- Andreas > > > > > > >
