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]

Reply via email to