onBeginRequest of your RequestCycle or something like that

but first try to upgrade

On Fri, Aug 15, 2008 at 4:50 PM, ChuckDeal <[EMAIL PROTECTED]> wrote:

>
> Sorry, you had asked some questions too:
>
> I had not verified that it was the same httpsession. it just seemed to be
> the same wicket session.  Where would you recommend to print the session id
> (i'm guessing httpsession id?)?
>
>
> Johan Compagner wrote:
> >
> > do you really see the same httpsession instance?
> > or just the wicket session instance?
> >
> > Can you print out the session ids?
> >
> > But first upgrade to 1.3.4:
> >
> > The Apache Wicket team is proud to announce the availability of the
> fourth
> > maintenance release: Apache Wicket 1.3.4. A lot of bugs have been
> squashed
> > and
> > several improvements implemented. Two noteworthy bugs have been squashed:
> >
> >    - cross session leakage due to a dangling thread local in exceptional
> >    circumstances
> >    - memory leak in localizer (WICKET-1667)
> >
> > johan
> >
> >
> >
> > On Fri, Aug 15, 2008 at 4:29 PM, ChuckDeal <[EMAIL PROTECTED]> wrote:
> >
> >>
> >> Wicket 1.3.3
> >>
> >> I am going to attempt to describe what I have experienced in the hopes
> >> that
> >> a core dev can point me in the right direction.
> >>
> >> The background:  We previously had a complete JSP system in place.  We
> >> decided to use the Wicket framework, but could not convert the entire
> >> system
> >> at once, so the foundation is now wicket with a few of its pieces in
> >> Wicket,
> >> but much of the legacy system is accessed thorugh a technique the Al Maw
> >> posted whereby the legacy url is captured then redirected into a Wicket
> >> page
> >> hosting an IFrame, which then loads the original URL.  All of the pure
> >> Wicket pages are mounted using the HybridUrlCodingStrategy, except for
> >> the
> >> Wicket page that acts as the legacy interface, which is the standard
> >> BookmarkablePageRequestTargetUCS.  We use the wicket-auth module for
> >> authentication (with Databinder), so the user (user_id) is stored in the
> >> WebSession.
> >>
> >> The problem:  It seems that when two users enter the system, there is a
> >> scenario where the second user "becomes" the first user.  Both users
> >> login
> >> through a Wicket Page, which deposits them on a wicket page.  If user1
> go
> >> to
> >> a legacy URL, then the next wicket page that user2 visits changes to
> >> user1's
> >> session.  This can be observed because we display the logged in user on
> >> each
> >> page and the name changes.
> >>
> >> My working theory is that it has something to do with loading a
> >> serialized
> >> page from disk.  We are using JDK serialization and the std
> >> SecondLevelCache/DiskPageStore session store.  Can a dev verify that the
> >> Session is serialized with a Page?  How on earth is one user loading
> >> another's serialized Page from disk?  Has anyone experienced this?  How
> >> can
> >> I prevent this?  Obviously, this is a serious issue for us because this
> >> defeats user security.
> >>
> >> Chuck
> >> --
> >> View this message in context:
> >> http://www.nabble.com/session-%22jumping%22--tp18999615p18999615.html
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/session-%22jumping%22--tp18999615p18999966.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Reply via email to