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! > >> > >> > > >
