[
https://issues.apache.org/jira/browse/WW-4873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16247720#comment-16247720
]
Yasser Zamani commented on WW-4873:
-----------------------------------
{quote}
I assume it needs to stay in there for as long as it takes for the interceptor
to run across every potential request using the same session.
{quote}
No, not at all! I found all usages of {{InvocationSessionStore}} and is only
used in {{TokenSessionStoreInterceptor}} and it's {{loadInvocation()}} method
is only used in {{handleInvalidToken()}} method. So,
{{ActionContext.getContext().getSession().get("org.apache.struts2.util.InvocationSessionStore.invocationMap")}}
is only used when user posted token is not valid (e.g. someone else tries a
CSRF attack) and Struts returns previous result. When you delete it, Struts
simply returns {{invalid.token}}.
So the conclusion is, the difference only occurs when user posts a not valid
token (usually does not occur except on security attacks or duplicated posts)
and the difference is Struts returns {{invalid.token}} instead of previous
executed result. It seems no any very bad thing occurs.
> NotSerializableException - org.apache.struts2.dispatcher.StrutsRequestWrapper
> -----------------------------------------------------------------------------
>
> Key: WW-4873
> URL: https://issues.apache.org/jira/browse/WW-4873
> Project: Struts 2
> Issue Type: Bug
> Affects Versions: 2.5.13
> Reporter: Michael Hum
> Fix For: 2.5.x
>
>
> We are attempting to test session replication on our websphere servers but
> run into the given error when websphere tries to serialize the session.
> {code}
> [10/18/17 10:33:38:094 EDT] 00000335 WASSession E MTMBuffWrapper getBytes
> write object exception. e= java.io.NotSerializableException:
> org.apache.struts2.dispatcher.StrutsRequestWrapper
> {code}
> It appears the ActionInvocation stores the ActionContext which stores the
> offending property: com.opensymphony.xwork2.dispatcher.HttpServletRequest -->
> StrutsRequestWrapper
> After a little digging we narrowed it down to our use of the
> TokenSessionStoreInterceptor which stores the value in the session and uses
> it to redirect the failed request to the original one. Is this
> intended/expected? Or is there no requirement that the contents in the
> session be serializable - in which case we would have to look to our own
> solution.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
