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 wrote:
> SAP Netweaver Java AS. We have up to date version 7.30
>
>
> On Thu, Apr 4, 2013 at
SAP Netweaver Java AS. We have up to date version 7.30
On Thu, Apr 4, 2013 at 9:45 AM, Antonios Gkogkakis 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 wrote:
>
> > Yes
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 wrote:
> Yes. I do put data into session after line of code: session =
> ActionContext.getContext().getSession();
>
> I can see a new sessi
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 looki
> > ((org.apache.struts2.dispatcher.SessionMap)
> > 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
HttpServletReque
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
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
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
Put the create-session interceptor into your action
input_with_token_tag.ftl
http://struts.apache.org/development/2.x/docs/create-session-interceptor.html
Martin
__
Verzicht und Vertraulichkeitanmerkung
Diese Nachricht ist vertraulich
9 matches
Mail list logo