The realm needs to be injected into the security manager only once:
securityManager.setRealm(realm);
This will ensure the lazily-created PropertiesRealm (the fallback/failsafe
one) is not created.
In a web app, the JSecurityFilter ensures SecurityUtils is set up properly.
In a standalone application, you need to call
SecurityUtils.setSecurityManager explicitly _if_ you are not using a DI
framework like Spring or Guice.
On Sun, Sep 7, 2008 at 4:18 PM, Animesh Jain <[EMAIL PROTECTED]> wrote:
> Well how does subject get its securityManager / realm. That may throw some
> light onto whether the realm needs to be injected elsewhere too.
>
> - Animesh
>
>
> On Mon, Sep 8, 2008 at 1:46 AM, Animesh Jain <[EMAIL PROTECTED]> wrote:
>
>> Yup this is a web-app. I'm using Guice for dependency injection so you can
>> think of that as a replacement for Spring. I could send you the whole app
>> too so you'd see what I see. I'm pretty sure there's nothing wrong with the
>> dependency injection here. Because as I said after the login action I'm able
>> to obtain an instance of the subject in a separate action class by calling
>>
>> Subject subject = getSecurityManager().getSubject()
>>
>> Here getSecurityManager() gets me an injected SecurityManager correctly
>> with my realm properly configured and all. Right after this line if I call
>>
>> subject.hasRole("XYZ")
>>
>> the error gets thrown up.
>>
>> - Animesh
>>
>>
>>
>> On Mon, Sep 8, 2008 at 1:38 AM, Les Hazlewood <[EMAIL PROTECTED]> wrote:
>>
>>> Is this a web app? I.e. is there a web.xml file somewhere?
>>>
>>> Also, is this a spring application?
>>>
>>>
>>> On Sun, Sep 7, 2008 at 3:44 PM, Animesh Jain <[EMAIL PROTECTED]>wrote:
>>>
>>>> Ok here's the deal..
>>>>
>>>> I'm injecting a DefaultWebSecurityManager into my action classes, which
>>>> has my HibernateSecurityRealm set correctly. So calling
>>>>
>>>> Subject subject = getSecurityManager().getSubject();
>>>>
>>>> is giving me the correct currently logged in user. But strangely when I
>>>> debug the subject instance after getting it, the securityManager it shows
>>>> is
>>>> not the same - it has a real called
>>>> org.jsecurity.realm.text.PropertiesRealm. Now how is that possible?
>>>>
>>>> I was not using the SecurityUtils class and had not explicitly set a
>>>> SecurityManager using SecurityUtils.setSecurityManager(). Is that required.
>>>> Anyway I now added it too but that has had no effect. Still the same error.
>>>>
>>>> So where's the subject instance getting the different implementation
>>>> from
>>>>
>>>> Animesh
>>>>
>>>>
>>>> On Mon, Sep 8, 2008 at 12:52 AM, Les Hazlewood <[EMAIL PROTECTED]>wrote:
>>>>
>>>>> The SimpleAccountRealm is a fallback/failsafe realm that is used if you
>>>>> haven't correctly configured a realm yourself. What does your JSecurity
>>>>> configuration look like?
>>>>>
>>>>>
>>>>> On Sun, Sep 7, 2008 at 3:04 PM, Animesh Jain <[EMAIL PROTECTED]>wrote:
>>>>>
>>>>>> Les,
>>>>>>
>>>>>> On second thoughts.. I'm still not sure. Why is it that there's
>>>>>> SimpleAccountRealm.java in the stacktrace and no HibernateSecurityRealm
>>>>>> (the
>>>>>> one I implemented).
>>>>>>
>>>>>> Any thoughts.
>>>>>>
>>>>>> Animesh
>>>>>>
>>>>>>
>>>>>> On Mon, Sep 8, 2008 at 12:24 AM, Animesh Jain <[EMAIL PROTECTED]>wrote:
>>>>>>
>>>>>>> Oops! I should have looked at the stacktrace closer. This is
>>>>>>> unrelated to Jsecurity. I've been working on an integration of
>>>>>>> Stripes+Guice+Warp persist+Jsecurity. Jsecurity is the last remaining
>>>>>>> thing
>>>>>>> and when I got the error I assumed it was because of that :P. So I'll
>>>>>>> close
>>>>>>> it here.. maybe I'll drop you an email if I feel I need your help.
>>>>>>>
>>>>>>> Stacktrace:
>>>>>>>
>>>>>>> exception
>>>>>>>
>>>>>>> net.sourceforge.stripes.exception.StripesServletException: Unhandled
>>>>>>> exception in exception handler.
>>>>>>>
>>>>>>> net.sourceforge.stripes.exception.DefaultExceptionHandler.handle(DefaultExceptionHandler.java:158)
>>>>>>>
>>>>>>> net.sourceforge.stripes.controller.StripesFilter.doFilter(StripesFilter.java:249)
>>>>>>>
>>>>>>> org.jsecurity.web.servlet.JSecurityFilter.doFilterInternal(JSecurityFilter.java:382)
>>>>>>>
>>>>>>> org.jsecurity.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:180)
>>>>>>>
>>>>>>> com.wideplay.warp.hibernate.SessionPerRequestFilter.doFilter(SessionPerRequestFilter.java:53)
>>>>>>>
>>>>>>> root cause
>>>>>>>
>>>>>>> java.util.NoSuchElementException
>>>>>>> java.util.Collections$EmptySet$1.next(Collections.java:2910)
>>>>>>>
>>>>>>> java.util.Collections$UnmodifiableCollection$1.next(Collections.java:1010)
>>>>>>>
>>>>>>> org.jsecurity.realm.SimpleAccountRealm.getAuthorizationCacheKey(SimpleAccountRealm.java:157)
>>>>>>>
>>>>>>> org.jsecurity.realm.AuthorizingRealm.getAuthorizationInfo(AuthorizingRealm.java:265)
>>>>>>>
>>>>>>> org.jsecurity.realm.AuthorizingRealm.hasRole(AuthorizingRealm.java:500)
>>>>>>>
>>>>>>> org.jsecurity.authz.ModularRealmAuthorizer.hasRole(ModularRealmAuthorizer.java:178)
>>>>>>>
>>>>>>> org.jsecurity.mgt.AuthorizingSecurityManager.hasRole(AuthorizingSecurityManager.java:213)
>>>>>>>
>>>>>>> org.jsecurity.subject.DelegatingSubject.hasRole(DelegatingSubject.java:211)
>>>>>>> bookmark.web.action.HomeAction.preAction(HomeAction.java:14)
>>>>>>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>>>
>>>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>>>>>
>>>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>>>>> java.lang.reflect.Method.invoke(Method.java:585)
>>>>>>>
>>>>>>> net.sourceforge.stripes.controller.DispatcherHelper$6.intercept(DispatcherHelper.java:442)
>>>>>>>
>>>>>>> net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext.java:158)
>>>>>>>
>>>>>>> net.sourceforge.stripes.controller.BeforeAfterMethodInterceptor.intercept(BeforeAfterMethodInterceptor.java:113)
>>>>>>>
>>>>>>> net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext.java:155)
>>>>>>>
>>>>>>> net.sourceforge.stripes.controller.BeforeAfterMethodInterceptor.intercept(BeforeAfterMethodInterceptor.java:113)
>>>>>>>
>>>>>>> net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext.java:155)
>>>>>>>
>>>>>>> net.sourceforge.stripes.controller.ExecutionContext.wrap(ExecutionContext.java:74)
>>>>>>>
>>>>>>> net.sourceforge.stripes.controller.DispatcherHelper.invokeEventHandler(DispatcherHelper.java:440)
>>>>>>>
>>>>>>> net.sourceforge.stripes.controller.DispatcherServlet.invokeEventHandler(DispatcherServlet.java:285)
>>>>>>>
>>>>>>> net.sourceforge.stripes.controller.DispatcherServlet.doPost(DispatcherServlet.java:167)
>>>>>>>
>>>>>>> net.sourceforge.stripes.controller.DispatcherServlet.doGet(DispatcherServlet.java:67)
>>>>>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
>>>>>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
>>>>>>>
>>>>>>> net.sourceforge.stripes.controller.StripesFilter.doFilter(StripesFilter.java:246)
>>>>>>>
>>>>>>> org.jsecurity.web.servlet.JSecurityFilter.doFilterInternal(JSecurityFilter.java:382)
>>>>>>>
>>>>>>> org.jsecurity.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:180)
>>>>>>>
>>>>>>> com.wideplay.warp.hibernate.SessionPerRequestFilter.doFilter(SessionPerRequestFilter.java:53)
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Sep 8, 2008 at 12:13 AM, Les Hazlewood <
>>>>>>> [EMAIL PROTECTED]> wrote:
>>>>>>>
>>>>>>>> Hi Animesh,
>>>>>>>>
>>>>>>>> Your realm implementation looks fine. But, JSecurity doesn't throw
>>>>>>>> a NoSuchElementException anywhere in its code. I'm assuming this has
>>>>>>>> to do
>>>>>>>> with how a collection is being used, either iterated by JSecurity, or
>>>>>>>> something happening in your DAO layer.
>>>>>>>>
>>>>>>>> Please include the stacktrace - it is very hard to debug without it
>>>>>>>> ;)
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Les
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
