Return-Path: Delivered-To: apmail-incubator-jsecurity-dev-archive@locus.apache.org Received: (qmail 37822 invoked from network); 7 Oct 2008 23:08:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 7 Oct 2008 23:08:23 -0000 Received: (qmail 67075 invoked by uid 500); 7 Oct 2008 23:08:22 -0000 Delivered-To: apmail-incubator-jsecurity-dev-archive@incubator.apache.org Received: (qmail 67037 invoked by uid 500); 7 Oct 2008 23:08:22 -0000 Mailing-List: contact jsecurity-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jsecurity-dev@incubator.apache.org Delivered-To: mailing list jsecurity-dev@incubator.apache.org Received: (qmail 67024 invoked by uid 99); 7 Oct 2008 23:08:22 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Oct 2008 16:08:22 -0700 X-ASF-Spam-Status: No, hits=1.5 required=10.0 tests=DNS_FROM_SECURITYSAGE,SPF_NEUTRAL,WHOIS_MYPRIVREG X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.85.200.173] (HELO wf-out-1314.google.com) (209.85.200.173) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Oct 2008 23:07:17 +0000 Received: by wf-out-1314.google.com with SMTP id 27so4139840wfd.21 for ; Tue, 07 Oct 2008 16:07:41 -0700 (PDT) Received: by 10.142.163.13 with SMTP id l13mr3042979wfe.34.1223420861496; Tue, 07 Oct 2008 16:07:41 -0700 (PDT) Received: by 10.142.13.7 with HTTP; Tue, 7 Oct 2008 16:07:41 -0700 (PDT) Message-ID: <44b57a610810071607k43644218h3476a8393f97e35e@mail.gmail.com> Date: Tue, 7 Oct 2008 19:07:41 -0400 From: "Les Hazlewood" Sender: les.hazlewood@anjinllc.com To: jsecurity-dev@incubator.apache.org Subject: Re: [grails-user] JSecurity Plugin, AbstractLdapRealm and Caching Cc: user@grails.codehaus.org In-Reply-To: <8bd9fdba0810070551y36e6578di2165c2c16b04c521@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <19843999.post@talk.nabble.com> <8bd9fdba0810070551y36e6578di2165c2c16b04c521@mail.gmail.com> X-Google-Sender-Auth: 72592e5fcea8178c X-Virus-Checked: Checked by ClamAV on apache.org You are indeed correct that it should be caching the AuthorizationInfo lookup for role/permission checks - at least that is what the code 'says'. There are a few trace/debug/info log messages in AuthorizingRealm that are printed when an authorization check occurs, particularly in the initAuthorizationCache() and getAuthorizationInfo() methods . Do you have that output? - Les On Tue, Oct 7, 2008 at 8:51 AM, Peter Ledbrook wrote: > Hi, > > I'm forwarding this to the JSecurity mailing list since it relates the > the core JSecurity classes. > > Cheers, > > Peter > > 2008/10/6 Skowronek : >> >> I have a Grails application using version 1.0.3. The JSecurity plugin >> version 0.3-SNAPSHOT is installed. >> >> I created a realm called AdamRealm, which extends AbstractLdapRealm to take >> advantage of the services in the hierarchy. Specifically caching. >> AdamRealm is very similar to ActiveDirectoryRealm. >> >> After launching the app, the realm is created as well as the CacheManager as >> shown in the log entries below. >> >> [com.jud.realm.AdamRealm] AdamRealm created >> [org.jsecurity.mgt.CachingSecurityManager] Attempting to initialize default >> CacheManager using EhCache... >> [org.jsecurity.cache.ehcache.EhCacheManager] cacheManager property not set. >> Constructing CacheManager instance... >> [org.jsecurity.io.ResourceUtils] Opening resource from class path >> [org/jsecurity/cache/ehcache/ehcache.xml]... >> [org.jsecurity.cache.ehcache.EhCacheManager] instantiated Ehcache >> CacheManager instance. >> [org.jsecurity.cache.ehcache.EhCacheManager] implicit cacheManager created >> successfully. >> >> >> If a user tries to access a restricted resource for the first time, I see >> that the queryForAuthenticationInfo(AuthenticationToken token, >> LdapContextFactory ldapContextFactory) implementation is called as expected >> and the user is authenticated. >> >> [com.jud.realm.AdamRealm] queryForAuthenticationInfo started >> DEBUG [org.jsecurity.authc.AbstractAuthenticator] Authentication successful >> for token [org.jsecurity.authc.UsernamePasswordToken - abc00, >> rememberMe=false]. Returned account: >> [org.jsecurity.subject.SimplePrincipalCollection@3fe59b3e] >> >> >> Next, the the queryForAuthorizationInfo(PrincipalCollection principals, >> LdapContextFactory ldapContextFactory) implementation is called as expected >> since this is the first time a restricted resource is being accessed by the >> user. >> >> DEBUG [com.jud.realm.AdamRealm] queryForAuthorizationInfo started >> >> My understanding is that for all subsequent requests made by the user, the >> queryForAuthorizationInfo() shouldn't be called. Instead, >> AuthorizingRealm.getAuthorizationInfo(PrincipalCollection principals) should >> pull the AuthorizationInfo from the cache, but that doesn't happen. For >> every subsequent request, I see the queryForAuthorizationInfo() being >> called. >> >> Any assistance on how to get the realm to pull the AuthorizationInfo from >> the cache would be appreciated. >> >> Thank you. >> >> -- >> View this message in context: http://www.nabble.com/JSecurity-Plugin%2C-AbstractLdapRealm-and-Caching-tp19843999p19843999.html >> Sent from the grails - user mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> > > > > -- > Software Engineer > G2One, Inc. > http://www.g2one.com/ >