Return-Path: X-Original-To: apmail-jackrabbit-users-archive@minotaur.apache.org Delivered-To: apmail-jackrabbit-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id BC43376AE for ; Tue, 26 Jul 2011 10:16:25 +0000 (UTC) Received: (qmail 67638 invoked by uid 500); 26 Jul 2011 10:16:24 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 67015 invoked by uid 500); 26 Jul 2011 10:16:09 -0000 Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@jackrabbit.apache.org Delivered-To: mailing list users@jackrabbit.apache.org Received: (qmail 66953 invoked by uid 99); 26 Jul 2011 10:16:03 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 26 Jul 2011 10:16:03 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of fcarriedos@gmail.com designates 209.85.216.177 as permitted sender) Received: from [209.85.216.177] (HELO mail-qy0-f177.google.com) (209.85.216.177) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 26 Jul 2011 10:15:56 +0000 Received: by qyk7 with SMTP id 7so300972qyk.1 for ; Tue, 26 Jul 2011 03:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:from:date:message-id:subject:to:content-type; bh=kjAzRikZrtqG8Kum8pcq2sYEfcXv2S8Uk6Xkd+b4KPs=; b=Vmhuyoktrrmoq4me1MP20kdorg46k4KBPKeK8cMRqcvqJv4dAEZd6XeAXbacgpui+d N65QPS2igIIqLeI/Y8RhsJDhv2w4daOEEccnrQkB3w9oD0nEQF7rd3Mik8yu2+b+fpnl ONEurx72wSTNHAiukjRneA9hBsJlvX2d+qLvQ= Received: by 10.229.190.83 with SMTP id dh19mr433430qcb.175.1311675335273; Tue, 26 Jul 2011 03:15:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.186.137 with HTTP; Tue, 26 Jul 2011 03:15:15 -0700 (PDT) Reply-To: fcarriedos@gmail.com From: Francisco Carriedo Scher Date: Tue, 26 Jul 2011 12:15:15 +0200 Message-ID: Subject: AccessControlException To: users@jackrabbit.apache.org Content-Type: multipart/alternative; boundary=0016e65bbc466b6df404a8f63649 --0016e65bbc466b6df404a8f63649 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi there, i am trying to assign an Acl to a folder node with the code below. Some questions regarding access control arised and i would like to ask for links where accurate info about my issues could be found or a brief explanation i= n order to explore the appropiate path (could be i went the wrong way while checking the wiki and the Javadoc of the API...). The code: *********** BEGIN OF MY CODE ******************* private void assignInitialPermissions(User u, Principal principal, String usersPath, Session session) throws UnsupportedRepositoryOperationException, RepositoryException { ValueFactory vf =3D session.getValueFactory(); AccessControlManager acm =3D session.getAccessControlManager(); List aces =3D new ArrayList(); Privilege privileges[] =3D acm.getSupportedPrivileges(usersPath);//= new Privilege[2];// =3D { Privilege.JCR_ADD_CHILD_NODES, Privilege.JCR_REMOVE_CHILD_NODES}; Map restrictions =3D new HashMap(= ); privileges =3D new Privilege[] { privileges[3] , privileges[8] }; // Adding restrictions: dummy restrictions since i found no clear explanation, but just trying right now restrictions.put("rep:nodePath", new Integer(1234)); restrictions.put("rep:glob", new Integer(1234)); System.out.println("Privilegios a a=F1adir: " + privileges[0].getName() + " " + privileges[1].getName()); // IMPORTANT, adding at the very first place!!! // since it takes the first matching entry aces.add(0,new AccessControlEntryImpl(principal, privileges) { @Override protected ValueFactory getValueFactory() { // TODO Auto-generated method stub return null; } @Override protected NameResolver getResolver() { // TODO Auto-generated method stub return null; } }); // Finally build and acl and assign it to the corresponding path UnmodifiableAccessControlList acl =3D new UnmodifiableAccessControlList(aces, usersPath, restrictions); acm.setPolicy(acl.getPath(), acl); } ************** END OF MY CODE *********************** ********************* ADDITIONAL CODE FROM JACKRABBIT IMPLEMENTATION *************************** /** * Always throws AccessControlException * * @see javax.jcr.security.AccessControlManager#setPolicy(String, AccessControlPolicy) */ public void setPolicy(String absPath, AccessControlPolicy policy) throw= s PathNotFoundException, AccessControlException, AccessDeniedException, RepositoryException { checkInitialized(); checkPermission(absPath, Permission.MODIFY_AC); throw new AccessControlException("AccessControlPolicy " + policy + = " cannot be applied."); } ********************* END OF ADDITIONAL CODE ***************************************************************** My questions: - Why does the code from JR implementation throw always an exception instea= d of trying to assign the policy? It must be a regular practice since i saw similar always-throwing-exception methods in the same class but i must confess that i have no idea about such behavior. By the way about this, am = i assigning properly the acl to grant the brand new user (User u param in the code above) over the brand new folder (let's say "user HOME" defined by String usersPath). - Where can i find detailed info about Restriction class/interface? What is exactly the meaning of such class (specifying special behavior for certain nodes???)? - I am accessing the repository through the shell (java -jar jackrabbit-standalone-2.2.7.jar --cli file:///media/Datos/Solaiemes/workspace/FileRepo/repository) to check if my code works and so far it worked fine while testing the folde= r and file nodes creation. But now, when trying to check the just written access control code, i can log in with any username (invented i mean) and password and any action is allowed aswell for such users. I guess that such behavior could be the default and it must be customized when developing you= r own solution, but so far i did not find any concrete place where to restric= t the access (i.e. not allowing any invented name to perform any operation an= d checking that the ACL i assign actually define restrictions on the nodes). Thanks in advance! --0016e65bbc466b6df404a8f63649--