My pleasure! I'm glad to hear it is working for you now. Best,
Les On Wed, Jul 29, 2009 at 3:35 PM, mad rug<[email protected]> wrote: > Hi Les, > > Sorry about the delay, I'm quite busy on this project, and little Internet > access. > Yes, that makes sense. > > You menioned about the DefaultAdvisorAutoProxyCreator, and that reminded me > of the problem I had with it a while ago. I use <aop:config> to define > transaction management for my beans, and I was having some double-proxying > problems. Because of that I removed the DefaultAdvisorAutoProxyCreator from > the Spring XML, it solved my problem and security was still working (at > least until I needed it in the non-MVC context). > > I don't know exactly how, but it worked perfectly for my MVC context, while > the Servlet one did not, as I described. Now I reactivated > DefaultAdvisorAutoProxyCreator and the security checks are working now on > both contexts. I had no double-proxy problems after a couple of bean calls, > and hope it remains like this =) > > Thanks for mentioning the auto-proxy... right to the spot. I'll mail again > if I have any new problems with it. > > Many thanks again for your time, Les. > > On Mon, Jul 27, 2009 at 6:30 PM, Les Hazlewood <[email protected]> > wrote: >> >> Hi Mad, >> >> Are you using Spring xml namespace declarations for AOP?, i.e. >> <aop:config/> notation? >> >> If so, this style of declaration does not play nice with the >> DefaultAdvisorAutoProxyCreator: >> >> >> http://static.springsource.org/spring/docs/2.5.x/reference/aop.html#aop-schema >> >> Note the warning. >> >> I'm not sure if this is affecting you or not, but I thought I'd check >> first. >> >> Also, the annotations require the existence of a thread-bound Subject >> on which to perform security checks. If the Subject instance is not >> there, the security checks will always fail (no Subject = no user = no >> access). >> >> The ShiroFilter automatically sets up this thread-bound Subject and >> cleans up the thread for every request. You need to make sure the >> ShiroFilter is defined in your 2nd webapp so it can perform this >> infrastructure work. >> >> In your case, you might think about subclassing the >> org.apache.shiro.spring.SpringIniWebConfiguration class and obtain the >> SecurityManager from your existing BeanFactory. Then ensure your >> IniConfiguration subclass is specified in the ShiroFilter web.xml >> configuration via an init-param (documented in the ShiroFilter JavaDoc >> - specify the 'configClassName' init param). That will allow the >> ShiroFilter to pick up your application's configured SecurityManager, >> which is required for Subject creation and binding during requests. >> >> Does all of this make sense? >> >> Regards, >> >> Les >> >> On Mon, Jul 27, 2009 at 5:05 PM, Les Hazlewood<[email protected]> >> wrote: >> > Hi Mad, >> > >> > For some reason I didn't see this - I'll read it and see if I can help. >> > >> > On Mon, Jul 27, 2009 at 4:31 PM, mad rug<[email protected]> wrote: >> >> Hi, >> >> >> >> It's over a week since this email, but no replies so far. I'm most sure >> >> I'm >> >> missing some silly detail here. >> >> Any help, please? >> >> >> >> Thanks! >> >> >> >> On Fri, Jul 17, 2009 at 5:55 PM, mad rug <[email protected]> wrote: >> >>> >> >>> Hi >> >>> >> >>> I just faced this strange situation, and I'm mostly sure Shiro should >> >>> behave differently... at least I hope it can. >> >>> >> >>> My application is Spring based. A parent application context contains >> >>> all >> >>> business and DAO objects, with Shiro role annotations on the business >> >>> methods. Linked to this parent there is a WAR context with my secured >> >>> application; it uses Spring MVC, Shiro URL filter, JDBC based >> >>> authentication >> >>> and authorization, and works perfectly (protects URLs, require login >> >>> when >> >>> not authc, blocks unauthorized access, both URL and business methods). >> >>> Now I needed to access the same parent context from another WAR >> >>> context. >> >>> This context is Servlet based (no Spring MVC), and I only needed a >> >>> couple of >> >>> beans in only one Servlet, so I didn't used IoC and retrieved the >> >>> beans >> >>> manually. Think of it as a public website, using some beans to list >> >>> non-critical and/or public data, or store contact requests submitted >> >>> through >> >>> a contact form. >> >>> I used the sample in the following site for this parent context: >> >>> >> >>> >> >>> http://blog.springsource.com/2007/06/11/using-a-shared-parent-application-context-in-a-multi-war-spring-application/ >> >>> >> >>> My code to access the parent container is this (just got it working, >> >>> and >> >>> don't know if this is not a nice way to do it): >> >>> BeanFactoryLocator bfl = >> >>> ContextSingletonBeanFactoryLocator.getInstance(); >> >>> BeanFactoryReference bfr = >> >>> bfl.useBeanFactory("myAppParentContext"); >> >>> BeanFactory bf = bfr.getFactory(); >> >>> MyService bean = (MyService)bf.getBean("myBean"); >> >>> Object x = bean.someMethodThatRequireRoles(); >> >>> >> >>> The service: >> >>> public interface MyService { >> >>> ... >> >>> @RequiresRoles(value = "someRole") >> >>> public Object someMethodThatRequireRoles() >> >>> {...} >> >>> } >> >>> >> >>> The issue is that any method accessed in these beans from the second >> >>> (public site) context do not perform any kind of security check. I >> >>> accessed >> >>> role-restricted methods in my business beans, and no exception was >> >>> thrown. I >> >>> also checked, and they are the same bean objects used by my secure >> >>> first >> >>> context, also I was not logged in to provide authorization, and the >> >>> role-checking methods in AuthorizingRealm were never invoked. >> >>> >> >>> I don't know why this is happening but I'd not like to leave it as it >> >>> is. >> >>> Is this a known scenario? How can I enable the security checks? >> >>> If any other info/code is needed to understand this, just ask me and >> >>> I'll >> >>> post it ASAP. >> >>> >> >>> Thanks! >> >> >> >> >> > > >
