I'll make another attempt at upgrading. The last time I tried to upgrade to 1.3.4, I had problem with the relative path adjustments that Wicket was making. I had planned to hold off until our next release because we are at the end of this cycle. But this is a showstopper, so here we go...
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--tp18999615p18999914.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]
