Ok now it makes sense. I completely forgot about the filter! Will go to
sleep now (late night in my part of the world) and update when I figure this
out.
Thanks a lot for the help Les :)
- Animesh
On Mon, Sep 8, 2008 at 2:02 AM, Les Hazlewood <[EMAIL PROTECTED]> wrote:
> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
