You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Peter Lin <pe...@gmail.com> on 2013/04/03 22:23:09 UTC
Update Cookie JSESSIONID
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
Re: Update Cookie JSESSIONID
Posted by Antonios Gkogkakis <gk...@tcd.ie>.
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 <pe...@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 <gk...@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 <pe...@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 <gk...@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 <pe...@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 <
> > > jlmagc@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 <pe...@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 <
> > mgainty@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: peterlin77@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
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Update Cookie JSESSIONID
Posted by Peter Lin <pe...@gmail.com>.
SAP Netweaver Java AS. We have up to date version 7.30
On Thu, Apr 4, 2013 at 9:45 AM, Antonios Gkogkakis <gk...@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 <pe...@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 <gk...@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 <pe...@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 <
> > jlmagc@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 <pe...@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 <
> mgainty@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: peterlin77@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
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Update Cookie JSESSIONID
Posted by Antonios Gkogkakis <gk...@tcd.ie>.
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 <pe...@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 <gk...@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 <pe...@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 <
> jlmagc@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 <pe...@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 <mgainty@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: peterlin77@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
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Update Cookie JSESSIONID
Posted by Peter Lin <pe...@gmail.com>.
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 <gk...@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 <pe...@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 <jlmagc@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 <pe...@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 <mg...@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: peterlin77@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
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Update Cookie JSESSIONID
Posted by Antonios Gkogkakis <gk...@tcd.ie>.
> > ((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 <pe...@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 <jlmagc@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 <pe...@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 <mg...@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: peterlin77@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
> > > >
> > > >
> > >
> >
>
Re: Update Cookie JSESSIONID
Posted by Peter Lin <pe...@gmail.com>.
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 <jl...@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 <pe...@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 <mg...@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: peterlin77@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
> > >
> > >
> >
>
Re: Update Cookie JSESSIONID
Posted by JOSE L MARTINEZ-AVIAL <jl...@gmail.com>.
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 <pe...@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 <mg...@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: peterlin77@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
> >
> >
>
Re: Update Cookie JSESSIONID
Posted by Peter Lin <pe...@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 <mg...@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: peterlin77@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
>
>
RE: Update Cookie JSESSIONID
Posted by Martin Gainty <mg...@hotmail.com>.
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.html Martin
______________________________________________
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: peterlin77@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