I moved 1.3-SNAPSHOT and still the same problem. I now see that it is the WicketURLDecoder that is causing the problem. It is prematurely decoding my **parameter**
Here is the URL: /jspfs/legacyUrl/peerReview%2Fpr_start.jsp where jspfs is the Wicket mount legacyUrl is the parm name peerReview%2Fpr_start.jsp is the parm VALUE, it needs to stay encoded! instead, it becomes /jspfs/legacyUrl/peerReview/pr_start.jsp which fails to match the serveltPath on line 184 of ServletWebRequest. I'm not sure how to proceed, should I open a JIRA for this? Johan Compagner wrote: > > cant you patch wicket for that specific problem? > > Is maybe trunk of 1.3 better for you? > > > On Fri, Aug 15, 2008 at 6:59 PM, ChuckDeal <[EMAIL PROTECTED]> wrote: > >> >> OK, I upgraded to 1.3.4 and now I remember what was broken for me. Some >> of >> my pages are having the wrong relative path prepended to them. Upon >> further >> inspection, line 184 of ServletWebRequest is not matching due to an >> encoding >> issue where >> >> path = jspfs/legacyUrl/peerReview/pr_start.jsp >> serveltPath = /jspfs/legacyUrl/peerReview%2Fpr_start.jsp >> >> I read up on WICKET-1624 and WICKET-1627 because it was referenced in the >> code, but I am not sure where to go from here. >> >> >> Johan Compagner wrote: >> > >> > 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] >> >> >> >> >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/session-%22jumping%22--tp18999615p19002132.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--tp18999615p19143569.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]
