You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by "gaganis@yahoo.com" <ga...@yahoo.com> on 2011/05/18 13:00:37 UTC
Problem when integrating shiro in webapp deployed on IBM websphere.
Hello all,
I am trying to use shiro in a webapp using the
org.apache.shiro.web.servlet.IniShiroFilter. Our application is deployed on
Websphere. The configuration seems to be OK and I can get the subject with
SecurityUtils.getSubject(). Also subject.getSession() returns a
DelegatingSubject$StoppingAwareProxiedSession. But when I try to run login()
I get the attached error.
Even though the problem seems to break in websphere code I am very
frustrated since I really liked shiro's features, approach and architecture
making this error a blocker for me.
Thank you very much for your time,
Giorgos
org.apache.shiro.session.InvalidSessionException:
java.lang.IllegalStateException
at
org.apache.shiro.web.session.HttpServletSession.removeAttribute(HttpServletSession.java:167)
at
org.apache.shiro.session.ProxiedSession.removeAttribute(ProxiedSession.java:135)
at
org.apache.shiro.subject.support.DelegatingSubject.clearRunAsIdentities(DelegatingSubject.java:424)
at
org.apache.shiro.subject.support.DelegatingSubject.login(DelegatingSubject.java:246)
at com.onetree.remax.action.LoginAction.login(LoginAction.java:74)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:600)
at
com.opensymphony.xwork2.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:452)
at
com.opensymphony.xwork2.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:291)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:254)
at
com.opensymphony.xwork2.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:176)
at
com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98)
at
com.google.inject.struts2.Struts2Factory$ProvidedInterceptor.intercept(Struts2Factory.java:216)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:248)
at
com.opensymphony.xwork2.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:263)
at
org.apache.struts2.interceptor.validation.AnnotationValidationInterceptor.doIntercept(AnnotationValidationInterceptor.java:68)
at
com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98)
at
com.google.inject.struts2.Struts2Factory$ProvidedInterceptor.intercept(Struts2Factory.java:216)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:248)
at
com.opensymphony.xwork2.interceptor.ConversionErrorInterceptor.intercept(ConversionErrorInterceptor.java:133)
at
com.google.inject.struts2.Struts2Factory$ProvidedInterceptor.intercept(Struts2Factory.java:216)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:248)
at
com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:207)
at
com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98)
at
com.google.inject.struts2.Struts2Factory$ProvidedInterceptor.intercept(Struts2Factory.java:216)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:248)
at
com.opensymphony.xwork2.interceptor.StaticParametersInterceptor.intercept(StaticParametersInterceptor.java:190)
at
com.google.inject.struts2.Struts2Factory$ProvidedInterceptor.intercept(Struts2Factory.java:216)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:248)
at
org.apache.struts2.interceptor.CheckboxInterceptor.intercept(CheckboxInterceptor.java:94)
at
com.google.inject.struts2.Struts2Factory$ProvidedInterceptor.intercept(Struts2Factory.java:216)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:248)
at
org.apache.struts2.interceptor.FileUploadInterceptor.intercept(FileUploadInterceptor.java:243)
at
com.google.inject.struts2.Struts2Factory$ProvidedInterceptor.intercept(Struts2Factory.java:216)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:248)
at
com.opensymphony.xwork2.interceptor.ModelDrivenInterceptor.intercept(ModelDrivenInterceptor.java:100)
at
com.google.inject.struts2.Struts2Factory$ProvidedInterceptor.intercept(Struts2Factory.java:216)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:248)
at
com.opensymphony.xwork2.interceptor.ScopedModelDrivenInterceptor.intercept(ScopedModelDrivenInterceptor.java:141)
at
com.google.inject.struts2.Struts2Factory$ProvidedInterceptor.intercept(Struts2Factory.java:216)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:248)
at
org.apache.struts2.interceptor.ProfilingActivationInterceptor.intercept(ProfilingActivationInterceptor.java:104)
at
com.google.inject.struts2.Struts2Factory$ProvidedInterceptor.intercept(Struts2Factory.java:216)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:248)
at
org.apache.struts2.interceptor.debugging.DebuggingInterceptor.intercept(DebuggingInterceptor.java:267)
at
com.google.inject.struts2.Struts2Factory$ProvidedInterceptor.intercept(Struts2Factory.java:216)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:248)
at
com.opensymphony.xwork2.interceptor.ChainingInterceptor.intercept(ChainingInterceptor.java:142)
at
com.google.inject.struts2.Struts2Factory$ProvidedInterceptor.intercept(Struts2Factory.java:216)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:248)
at
com.onetree.remax.interceptor.I18nInterceptor.intercept(I18nInterceptor.java:194)
at
com.google.inject.struts2.Struts2Factory$ProvidedInterceptor.intercept(Struts2Factory.java:216)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:248)
at
com.opensymphony.xwork2.interceptor.PrepareInterceptor.doIntercept(PrepareInterceptor.java:166)
at
com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98)
at
com.google.inject.struts2.Struts2Factory$ProvidedInterceptor.intercept(Struts2Factory.java:216)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:248)
at
org.apache.struts2.interceptor.ServletConfigInterceptor.intercept(ServletConfigInterceptor.java:164)
at
com.google.inject.struts2.Struts2Factory$ProvidedInterceptor.intercept(Struts2Factory.java:216)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:248)
at
com.opensymphony.xwork2.interceptor.AliasInterceptor.intercept(AliasInterceptor.java:190)
at
com.google.inject.struts2.Struts2Factory$ProvidedInterceptor.intercept(Struts2Factory.java:216)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:248)
at
com.opensymphony.xwork2.interceptor.ExceptionMappingInterceptor.intercept(ExceptionMappingInterceptor.java:187)
at
com.google.inject.struts2.Struts2Factory$ProvidedInterceptor.intercept(Struts2Factory.java:216)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:248)
at
com.onetree.remax.interceptor.AuthorizationInterceptor.intercept(AuthorizationInterceptor.java:72)
at
com.google.inject.struts2.Struts2Factory$ProvidedInterceptor.intercept(Struts2Factory.java:216)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:248)
at
org.apache.struts2.impl.StrutsActionProxy.execute(StrutsActionProxy.java:52)
at
org.apache.struts2.dispatcher.Dispatcher.serviceAction(Dispatcher.java:485)
at
org.apache.struts2.dispatcher.ng.ExecuteOperations.executeAction(ExecuteOperations.java:77)
at
org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.doFilter(StrutsPrepareAndExecuteFilter.java:91)
at
com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:188)
at
com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:116)
at
org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:359)
at
org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:275)
at
org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
at
org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
at
org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:344)
at
org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:272)
at
org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:81)
at
com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:188)
at
com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:116)
at
com.ibm.ws.webcontainer.filter.WebAppFilterChain._doFilter(WebAppFilterChain.java:77)
at
com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:908)
at
com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:997)
at
com.ibm.ws.webcontainer.extension.DefaultExtensionProcessor.invokeFilters(DefaultExtensionProcessor.java:985)
at
com.ibm.ws.webcontainer.extension.DefaultExtensionProcessor.handleRequest(DefaultExtensionProcessor.java:905)
at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3826)
at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:276)
at
com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:931)
at
com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1583)
at
com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:186)
at
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:445)
at
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:504)
at
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:301)
at
com.ibm.ws.http.channel.inbound.impl.HttpICLReadCallback.complete(HttpICLReadCallback.java:83)
at
com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165)
at
com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
at
com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138)
at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204)
at
com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775)
at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1563)
Caused by: java.lang.IllegalStateException
at
com.ibm.ws.session.http.HttpSessionImpl.getAttribute(HttpSessionImpl.java:191)
at com.ibm.ws.session.SessionData.getSessionValue(SessionData.java:306)
at com.ibm.ws.session.SessionData.getAttribute(SessionData.java:162)
at
com.ibm.ws.session.HttpSessionFacade.getAttribute(HttpSessionFacade.java:139)
at
org.apache.shiro.web.session.HttpServletSession.removeAttribute(HttpServletSession.java:163)
... 107 more
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Problem-when-integrating-shiro-in-webapp-deployed-on-IBM-websphere-tp6377316p6377316.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Problem when integrating shiro in webapp deployed on IBM websphere.
Posted by Les Hazlewood <lh...@apache.org>.
On Thu, May 19, 2011 at 12:30 AM, gaganis@yahoo.com <ga...@yahoo.com> wrote:
>>
>> In the meantime, I suppose that in the clearRunAsIdentities() method,
>> we could catch any resulting InvalidSessionException and ignore it.
>> Please open a Jira issue if you feel that this should be the case.
>>
> I believe that there is no meaning to removing an attribute in an
> invalidated session since de facto it does not contain any values.
How do you determine if a session is invalid before using it today (in
a standard servlet container application)?
>> However, I contend that it is more correct to address the underlying
>> issue of this - that you're explicitly invalidating the session before
>> calling login.
>>
> Invalidating a session is something that a user can do in a servlet
> application. I consider it to be problematic if shiro is failing and this
> failure is presented to the use with an intimidating and so esoteric error
> message. I do not know whether invalidating a session is bad programming
> practice and I would really be greatfull if you could elaborate a little
> bit more on that.
I wasn't indicating that your behavior is incorrect - only stating
that the root cause of Shiro's failure was that you called
httpSession.invalidate() on a servlet container session and Shiro
didn't 'know' about it. I consider this a Shiro bug - could you
please create a Jira issue indicating your problem so we can address
it?
> Well at the moment our application is written without shiro using native
> http sessions and I tried to start integrating it and I got this error at my
> first call at subject.login().
Although I still believe this is a bug for this particular scenario,
the quick fix is to call subject.logout() instead of
httpSession.invalidate() - Shiro will invalidate the session
automatically for you. That should get you going again until the bug
can be addressed. Can you please create an issue so this isn't lost?
Best regards,
Les
Re: Problem when integrating shiro in webapp deployed on IBM
websphere.
Posted by "gaganis@yahoo.com" <ga...@yahoo.com>.
Les Hazlewood-2 wrote:
>
> On Wed, May 18, 2011 at 6:23 AM, gaganis@yahoo.com
> <gaganis@yahoo.com> wrote:
>> Update
>>
>> The error message was rather intimidating and it made me more eager to
>> post
>> it to the list. After some thought I decided to dig it a little bit more
>> myself so I have downloaded the shiro source code and did some debugging.
>>
>> What I came across is that the error was a side-effect from our existing
>> login code where we invalidated the session before our login code to
>> protect
>> from session stealing attacks.
>>
>> So the shiro code that tried to remove key
>> org.apache.shiro.subject.support.DelegatingSubject.RUN_AS_PRINCIPALS_SESSION_KEY
>> is failing.
>>
>> Just some thoughts: Is shiro trying to clean the session from previous
>> logins?
>
> No, there is no need that I can see - a new login will overwrite any
> state in the session from a previous login.
>
>> Should this key be always present?
>
> The key is only set if performing runAs functionality. However,
> during login or logout(), if a session exists, we attempt to remove it
> to guarantee cleanup.
>
>
>> Shouldn't shiro check if a Session is not invalidated before trying to
>> remove that key?
>
> There isn't a Session.isValid() method at the moment. The reason is
> that the HttpSession has no such method and people have been fine with
> using that for over a decade. Also, if that method was present, I
> fear that people would be calling isValid() _every_ time they wanted
> to interact with a session, which might encourage an ugly programming
> practice IMO.
>
> In the meantime, I suppose that in the clearRunAsIdentities() method,
> we could catch any resulting InvalidSessionException and ignore it.
> Please open a Jira issue if you feel that this should be the case.
>
I believe that there is no meaning to removing an attribute in an
invalidated session since de facto it does not contain any values.
Les Hazlewood-2 wrote:
>
>
> However, I contend that it is more correct to address the underlying
> issue of this - that you're explicitly invalidating the session before
> calling login.
>
Invalidating a session is something that a user can do in a servlet
application. I consider it to be problematic if shiro is failing and this
failure is presented to the use with an intimidating and so esoteric error
message. I do not know whether invalidating a session is bad programming
practice and I would really be greatfull if you could elaborate a little
bit more on that.
Les Hazlewood-2 wrote:
>
>
> It sounds as if you are using the servlet container sessions and not
> Shiro's native sessions - is that correct? I'm fairly certain this
> behavior does not happen with native sessions because calling
> HttpSession.invalidate when using native sessions will null the
> DelegatingSubject's internal session reference (so there wouldn't be
> one at all to use in the clearRunAsIdentities() method).
>
>
Well at the moment our application is written without shiro using native
http sessions and I tried to start integrating it and I got this error at my
first call at subject.login().
Les Hazlewood-2 wrote:
>
>
> If you are using servlet container sessions, this would be a bug -
> please open a Jira issue for it and we can get it in to the next
> release.
>
> HTH!
>
> Best,
>
> --
> Les Hazlewood
> Founder, Katasoft, Inc.
> Application Security Products & Professional Apache Shiro Support and
> Training:
> http://www.katasoft.com
>
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Problem-when-integrating-shiro-in-webapp-deployed-on-IBM-websphere-tp6377316p6380956.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Problem when integrating shiro in webapp deployed on IBM websphere.
Posted by Les Hazlewood <lh...@apache.org>.
On Wed, May 18, 2011 at 6:23 AM, gaganis@yahoo.com <ga...@yahoo.com> wrote:
> Update
>
> The error message was rather intimidating and it made me more eager to post
> it to the list. After some thought I decided to dig it a little bit more
> myself so I have downloaded the shiro source code and did some debugging.
>
> What I came across is that the error was a side-effect from our existing
> login code where we invalidated the session before our login code to protect
> from session stealing attacks.
>
> So the shiro code that tried to remove key
> org.apache.shiro.subject.support.DelegatingSubject.RUN_AS_PRINCIPALS_SESSION_KEY
> is failing.
>
> Just some thoughts: Is shiro trying to clean the session from previous
> logins?
No, there is no need that I can see - a new login will overwrite any
state in the session from a previous login.
> Should this key be always present?
The key is only set if performing runAs functionality. However,
during login or logout(), if a session exists, we attempt to remove it
to guarantee cleanup.
> Shouldn't shiro check if a Session is not invalidated before trying to remove that key?
There isn't a Session.isValid() method at the moment. The reason is
that the HttpSession has no such method and people have been fine with
using that for over a decade. Also, if that method was present, I
fear that people would be calling isValid() _every_ time they wanted
to interact with a session, which might encourage an ugly programming
practice IMO.
In the meantime, I suppose that in the clearRunAsIdentities() method,
we could catch any resulting InvalidSessionException and ignore it.
Please open a Jira issue if you feel that this should be the case.
However, I contend that it is more correct to address the underlying
issue of this - that you're explicitly invalidating the session before
calling login.
It sounds as if you are using the servlet container sessions and not
Shiro's native sessions - is that correct? I'm fairly certain this
behavior does not happen with native sessions because calling
HttpSession.invalidate when using native sessions will null the
DelegatingSubject's internal session reference (so there wouldn't be
one at all to use in the clearRunAsIdentities() method).
If you are using servlet container sessions, this would be a bug -
please open a Jira issue for it and we can get it in to the next
release.
HTH!
Best,
--
Les Hazlewood
Founder, Katasoft, Inc.
Application Security Products & Professional Apache Shiro Support and Training:
http://www.katasoft.com
Re: Problem when integrating shiro in webapp deployed on IBM
websphere.
Posted by "gaganis@yahoo.com" <ga...@yahoo.com>.
Update
The error message was rather intimidating and it made me more eager to post
it to the list. After some thought I decided to dig it a little bit more
myself so I have downloaded the shiro source code and did some debugging.
What I came across is that the error was a side-effect from our existing
login code where we invalidated the session before our login code to protect
from session stealing attacks.
So the shiro code that tried to remove key
org.apache.shiro.subject.support.DelegatingSubject.RUN_AS_PRINCIPALS_SESSION_KEY
is failing.
Just some thoughts: Is shiro trying to clean the session from previous
logins? Should this key be always present? Shouldn't shiro check if a
Session is not invalidated before trying to remove that key?
Giorgos
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Problem-when-integrating-shiro-in-webapp-deployed-on-IBM-websphere-tp6377316p6377784.html
Sent from the Shiro User mailing list archive at Nabble.com.