What are you using to "login"? Is it Acegi/Spring Security? Are you using the appropriate "strategy" (thread-local) for keeping track of the currently logged in user?
On Fri, Aug 22, 2008 at 9:14 PM, rmorrisey <[EMAIL PROTECTED]> wrote: > > I'm working on the same project as Chuck, trying to help debug the session > jumping. Here's a little more information: > -Upgrading to 1.3.4 did not fix the issue > -The session ID seems to be constant according to whichever PC initiated the > request > -A few example cases where we've seen the error: > 1) > Server is started > A logs in > B logs in (while A is logging in/loading homepage) > B sees A's homepage > > 2) > Server is started > A logs in > B logs in > A and B hit a couple different pages simultaneously > B logs out (while A is loading a slow lazy-loading page) > A clicks "Logout" //logout link fires setResponsePage(Page, parameters) > A gets a page expired error instead of logging out normally and returning to > login screen > > It's not easy to reproduce the problem consistently, but it seems to happen > relatively often with multiple concurrent users from different PCs. > > We will keep trying! > Thanks, > Russell > > > 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--tp18999615p19117723.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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
