I don't have any experience with that. Your logic seems correct though and we have something similar working in tomcat. So I'd imagine it's the AS as you said.
Antonios On 4 April 2013 15:47, Peter Lin <peterli...@gmail.com> wrote: > SAP Netweaver Java AS. We have up to date version 7.30 > > > On Thu, Apr 4, 2013 at 9:45 AM, Antonios Gkogkakis <gkogk...@tcd.ie> > wrote: > > > What application server are you using? I remember some people having > issues > > with session ids with spring security in jboss. > > > > On 4 April 2013 15:36, Peter Lin <peterli...@gmail.com> wrote: > > > > > Yes. I do put data into session after line of code: session = > > > ActionContext.getContext().getSession(); > > > > > > I can see a new session is created but with the original JSESSIONID > > > associated. I need it to be associated with a brand new JSESSIONID. I > > > believe this is a bug in our Application server and looking for a > > > workaround. > > > > > > Thanks, > > > Peter > > > > > > > > > On Thu, Apr 4, 2013 at 9:27 AM, Antonios Gkogkakis <gkogk...@tcd.ie> > > > wrote: > > > > > > > > > ((org.apache.struts2.dispatcher.SessionMap<String,Object>) > > > > > > session).invalidate(); > > > > > > session = ActionContext.getContext().getSession(); > > > > > > > > That code invalidates the existing session but does not create a new > > one. > > > > > > > > To create a new session you have to call request.getSession(true); on > > the > > > > HttpServletRequest, Struts will do that for you if you attempt to put > > > > something in the invalidated session using > ActionContext.getContext(). > > > > getSession().put > > > > > > > > > > > > > > > > > > > > On 4 April 2013 14:44, Peter Lin <peterli...@gmail.com> wrote: > > > > > > > > > That is exactly my problem. The application server does not send a > > new > > > > > JSESSIONID back to browser as long as a JSESSIONID cookie came with > > the > > > > > original request, even I specifically invalidate session and > create a > > > new > > > > > one. > > > > > > > > > > What is work-around? Do we have a way to block JSESSIONID cookie > > come > > > to > > > > > my specific URL/action? > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Peter > > > > > > > > > > > > > > > On Wed, Apr 3, 2013 at 11:14 PM, JOSE L MARTINEZ-AVIAL < > > > jlm...@gmail.com > > > > > >wrote: > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
