struts-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yasser Zamani (JIRA)" <>
Subject [jira] [Commented] (WW-4873) NotSerializableException - org.apache.struts2.dispatcher.StrutsRequestWrapper
Date Fri, 10 Nov 2017 16:13:00 GMT


Yasser Zamani commented on WW-4873:

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.

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

> NotSerializableException - org.apache.struts2.dispatcher.StrutsRequestWrapper
> -----------------------------------------------------------------------------
>                 Key: WW-4873
>                 URL:
>             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= 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

View raw message