Are you creating a new session after invalidating the original one? If you do that, the server should send a new JSESSIONID cookie to the client on the response. Otherwise I don't know how your server will work, but I assume it will not sent any cookie back to the client, and therefore the browser will still have the old JSESSIONID and sent it to the server on every request(until a new session is created or the browser is closed).
JL 2013/4/3 Peter Lin <peterli...@gmail.com> > Thanks, Martins. CreateSessionInterceptor is not the answer for my case. My > authentication action class already implements SessionAware, the SessionMap > is available for use. My problem is after authentication, I would like to > clear existing user session, and create a new one, in which I would store > some data for other action classes to use. But my application server still > pick the old JSESSIONID as the identifier of the new session - it is a > security hole. > > Before an user invokes my authentication action class, he needs to enter > username/password to the form. I tried to set JSESSIONID cookie to expired > in displaying login page. I can see the cookie get sent back to browser > with expired attribute, but the browser still sends the same JSESSIONID > cookie in the following request, which is to invoke authentication class. > > Then I was thinking whether I am able to create an Interceptor to block the > JSESSIONID cookie from sending to authentication action class or not? Not > sure how to do that. > > Thanks, > Peter > > > On Wed, Apr 3, 2013 at 7:39 PM, Martin Gainty <mgai...@hotmail.com> wrote: > > > Put the create-session interceptor into your action <action > > name="someAction" class="com.examples.SomeAction"> > > <interceptor-ref name="createSession"/> > > <interceptor-ref name="defaultStack"/> > > <result name="input">input_with_token_tag.ftl</result> > > </action> > > > > > http://struts.apache.org/development/2.x/docs/create-session-interceptor.htmlMartin > > > > ______________________________________________ > > Verzicht und Vertraulichkeitanmerkung > > > > Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene > > Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede > unbefugte > > Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht > > dient lediglich dem Austausch von Informationen und entfaltet keine > > rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von > > E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. > > > > > > > Date: Wed, 3 Apr 2013 15:23:09 -0500 > > > Subject: Update Cookie JSESSIONID > > > From: peterli...@gmail.com > > > To: user@struts.apache.org > > > > > > Due to our server always picks up the old JSESSIONID for creating a new > > > user session if a cookie JSESSIONID has been passed - Waiting for Basis > > > team to solve it. > > > > > > I tried to set the cookie JSESSIONID to expired before display the > login > > > screen, but failed. I just wonder can I block the JSESSIONID cookie in > > > Interceptor, so this cookie would not get to authentication action - > the > > > server would create a new sessionId for the new user session. > > > > > > If that is impossible, could some one point me to the light? > > > > > > Issue I face: Even I use the following code in Authentication action > > class > > > after credential check, the application server still uses the old > > > JSESSIONID for the new session. > > > > > > //invalidate the existing session and create a new one > > > ((org.apache.struts2.dispatcher.SessionMap<String,Object>) > > > session).invalidate(); > > > session = ActionContext.getContext().getSession(); > > > > > > Thanks, > > > Peter > > > > >
