wicket-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Grigorov <mgrigo...@apache.org>
Subject Re: Wicket 6 Session issue
Date Wed, 05 Nov 2014 13:49:10 GMT
Thanks ! It is more clear now !


On Wed, Nov 5, 2014 at 3:44 PM, Wayne W <waynemailinglists@gmail.com> wrote:

> Sorry Martin its not clear enough. This any better?
>
>
>    1. Tomcat1 / Session A / Thread 1: User goes to : my.example.com/login
>     (LoginPage.java)
>    2. Tomcat1 / Session A / Thread 2: They log in
>    3. Tomcat 1 / Session A / Thread 2 : We invalidate the session and do a
>    redirect to : foo.example.com/login passing some parameters
>    4. Tomcat 2 / Session B / Thread 1: In the constructor of LoginPage we
>    verify the parameters and if valid setup up the new current session with
>    the user's details (Session.setUser(user))
>    5. Tomcat 2/ Session B / Thread 1: LoginPage then does
>    a setResponsePage(Application.get().getHomePage());
>

try by adding getSession().bind(); at step 5


>    6. Tomcat 2/Session B / Thread
>    1:  MetaDataRoleAuthorizationStrategy.isInstantiationAuthorized() finds
>    null in the Session (Session.getUser() )
>
>
>
>
> On Wed, Nov 5, 2014 at 11:22 AM, Martin Grigorov <mgrigorov@apache.org>
> wrote:
>
> > Then your first mail misleads.
> > Would you please explain again the steps with more details which step on
> > which node happens.
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
> >
> > On Wed, Nov 5, 2014 at 1:01 PM, Wayne W <waynemailinglists@gmail.com>
> > wrote:
> >
> > > Hi Martin,
> > >
> > > I don't think this is anything to do with session replication, as we
> > > invalidate the session at step 3 and its not about trying to pick the
> > > session up on a different instance. Its about creating a new session
> > from a
> > > redirect where the issue seems. We do use sticky session load balancing
> > via
> > > the JSESSION cookie on apache.
> > >
> > >
> > >
> > > On Wed, Nov 5, 2014 at 10:56 AM, Martin Grigorov <mgrigorov@apache.org
> >
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > As far as I know the session replication supporting code is the same
> > > since
> > > > Wicket 1.4.1 (or 1.4.2).
> > > >
> > > > The Wicket Session object is saved as an attribute in the
> HttpSession.
> > > The
> > > > HttpSession is replicated by Tomcat itself. What is your Tomcat
> config
> > > > related to replication ?
> > > > Do you use sticky sessions ? It seems you don't but I have to ask.
> > > >
> > > > Martin Grigorov
> > > > Wicket Training and Consulting
> > > > https://twitter.com/mtgrigorov
> > > >
> > > > On Wed, Nov 5, 2014 at 12:43 PM, Wayne W <
> waynemailinglists@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > we recently migrated to 6.17 from 4.x. Something we are now
> > > experiencing
> > > > is
> > > > > an odd session problem in production.
> > > > >
> > > > > We have 2 tomcats load balance running the front end wicket code.
> We
> > > > have a
> > > > > certain flow that goes like this:
> > > > >
> > > > >
> > > > >    1. User goes to : my.example.com/login (LoginPage.java)
> > > > >    2. They log in
> > > > >    3. We invalidate the session and do a redirect to :
> > > > > foo.example.com/login
> > > > >    passing some parameters
> > > > >    4. In the constructor of LoginPage we verify the parameters and
> if
> > > > valid
> > > > >    setup up the new current session with the user's details
> > > > >    5. LoginPage then does
> > > > >    a setResponsePage(Application.get().getHomePage());
> > > > >
> > > > > This on a single node/machine/instance of tomcat works great and
> with
> > > > > Wicket 4 it also worked great in a 2 node/instance load balanced
> > > > situation
> > > > > however we have a problem.
> > > > >
> > > > > Problem:
> > > > > If at step 3 the redirect gets load balances to a different
> instance
> > of
> > > > > tomcat, step 4 works fine (the request is read the the new session
> is
> > > got
> > > > > and the user info set on it). But this is when it gets really odd.
> > > Step 5
> > > > > is executed fine, but when the home page is constructed
> > > > > our MetaDataRoleAuthorizationStrategy.isInstantiationAuthorized()
> is
> > > > > called as normal, and when we check the session to see if the users
> > > > details
> > > > > are ok, there is no user in the session at all and we have a
> > different
> > > > > session !
> > > > >
> > > > > Any ideas at all what is happening here? Did something change
> around
> > > the
> > > > > session handling? I'm wondering if its something to do with the 302
> > > > > redirect to the new URL with parameters?
> > > > >
> > > > > many thanks
> > > > >
> > > >
> > >
> >
>

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