From users-return-14577-apmail-jackrabbit-users-archive=jackrabbit.apache.org@jackrabbit.apache.org Wed Mar 03 11:45:42 2010 Return-Path: Delivered-To: apmail-jackrabbit-users-archive@minotaur.apache.org Received: (qmail 77846 invoked from network); 3 Mar 2010 11:45:42 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 3 Mar 2010 11:45:42 -0000 Received: (qmail 67685 invoked by uid 500); 3 Mar 2010 11:45:35 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 67655 invoked by uid 500); 3 Mar 2010 11:45:35 -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 67646 invoked by uid 99); 3 Mar 2010 11:45:35 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Mar 2010 11:45:35 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of anchela@day.com designates 207.126.148.88 as permitted sender) Received: from [207.126.148.88] (HELO eu3sys201aog102.obsmtp.com) (207.126.148.88) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 03 Mar 2010 11:45:24 +0000 Received: from source ([209.85.220.228]) by eu3sys201aob102.postini.com ([207.126.154.11]) with SMTP ID DSNKS45Lv5D/rU/QjLz0OcBzGM5ZcunNMvmR@postini.com; Wed, 03 Mar 2010 11:45:04 UTC Received: by fxm28 with SMTP id 28so613824fxm.19 for ; Wed, 03 Mar 2010 03:45:03 -0800 (PST) Received: by 10.87.62.28 with SMTP id p28mr11904098fgk.55.1267616703404; Wed, 03 Mar 2010 03:45:03 -0800 (PST) Received: from bslm-106.corp.day.com (bsl-rtr.day.com [62.192.10.254]) by mx.google.com with ESMTPS id d8sm12293321fga.24.2010.03.03.03.45.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 03 Mar 2010 03:45:02 -0800 (PST) Message-ID: <4B8E4BC2.2020806@day.com> Date: Wed, 03 Mar 2010 12:45:06 +0100 From: Angela Schreiber User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: users@jackrabbit.apache.org Subject: Re: Get Path from Node References: <8f70391003010927p55a4d040i9510568961972e9e@mail.gmail.com> <510143ac1003011053p5476674ag695be9d06361e150@mail.gmail.com> <8f70391003011119r312dcdf6t9807c76645c9a662@mail.gmail.com> <510143ac1003011152w3fb2d3a2s649c63816ecf9c50@mail.gmail.com> <8f70391003011219j40743c78qfd4e8da66a4e3a1c@mail.gmail.com> In-Reply-To: <8f70391003011219j40743c78qfd4e8da66a4e3a1c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Paco Avila wrote: > I have implemented my own AccessManager, does this method work? And the AccessManager is a jackrabbit-core internal interface and is used internally for the access control evaluation. the AccessControlManager is an interface defined by JSR 283 and offers access control functionality to the API consumers. currently jackrabbit assumes that access control functionality can be exposed if the internal AccessManager implementation also is an AccessContolManager. > actually my code is not using jcr-2.0 but I plan to support it soon. then you can't make use of the jcr 2.0 AccessContolManager... i would not recommend to use the pre-release interfaces that were temporarily available in jackrabbit-api as the access control underwent quite some changes until the final version. > I'm not very happy with my own implementation of an AccessManager, but > in jackrabbit 1.4 there was no solution for this. And now, I found a > bit complex the new authorization API because is pooly documented. I > have readed the specification but some things like the user management > is obscure for me: how can I make use of this internal user management > if my user info is located in an external database? as of jackrabbit 2.0: the user management is not part JSR 283 and is an optional add on in jackrabbit-core. same as the principal discovery which was by intention was not included in the specification but left to the implementations. if you want expose your custom user-management you need to write your own implementation. otherwise - in case your API consumers don't need the user management - you may simply omit the user management (and even principal management)... what you have to make sure is that the sessions subject is properly populated with principals based on you user database [-> LoginModule]. the access control evaluation again depends on your needs. you can use the functionality present with jackrabbit-core that uses access control lists or you may provide your own logic... regards angela > Cheers. > > On Mon, Mar 1, 2010 at 8:52 PM, Jukka Zitting wrote: >> Hi, >> >> On Mon, Mar 1, 2010 at 8:19 PM, Paco Avila wrote: >>> myNode.getPath() returns an string, and I need a Path. I need to make a call to >>> >>> boolean isGranted(Path absPath, int permissions) >>> >>> from AccessManager and this requires a Path. >> Can you not use the AccessControlManager.hasPrivileges() method [1] for this? >> >> [1] http://www.day.com/maven/javax.jcr/javadocs/jcr-2.0/javax/jcr/security/AccessControlManager.html#hasPrivileges(java.lang.String, >> javax.jcr.security.Privilege[]) >> >> BR, >> >> Jukka Zitting >> > > >