struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonios Gkogkakis <gkogk...@tcd.ie>
Subject Re: Update Cookie JSESSIONID
Date Thu, 04 Apr 2013 14:57:03 GMT
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 <peterlin77@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 <gkogkaka@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 <peterlin77@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 <gkogkaka@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 <peterlin77@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 <peterlin77@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
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message