This is version . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]
TitleIPlanet HTTP session incompatibility
Date30-Oct-2006 13:44:38 EET
Version2.4.21
SubmitterTimBass
Bug criticalityBadBug
Browser version
Bug statusNewBug
PageProvider used
Servlet ContaineriPlanet
Operating SystemSolaris
URL
Java version

(Moved from JSPWikiSupport, as it seems to be a bug of some sorts.)

07-Sep-2006

Here's my situation. I am running jspWiki v2.4.21 and everything works great on my local machine using Tomcat. I moved it over to our production unix servers running iplanet/sunone version 6.1 (FYI... I don't have any control over this server either or its configuration), and the authorization and login no longer seemed to worked. I tried numerous thing and added a lot of debugging statements to figure out what was going on. It seemed like the user would be logged in correctly, but then the user principal just vanished and everything would revert back to the guest account.

I was eventually able to track down what was going on, but i still don't understand why.

I traced the problem to the WikiSession class and the getWikiSession method. I discovered here that each time the HttpSession was retrieved from the HttpServletRequest object it was a new instance of StandardSessionFacade rather than the same instance like Tomcat provided locally. I dug a little deeper into the SessionMonitor (and the find method) next to discover that the HttpSession object itself is used as the key of a httpSessions map (m_sessions) whose value was the associated WikiSession. After some more debugging I realized that every time the getWikiSession was called it was never finding a match in the map because the HttpSession was a new instance. Therefore, it would return a new guest WikiSession each time. Not Good.

To fix the issue I ended up adding in a chunk of code to the SessionMonitor's find method that, after the normal map lookup failed to find a match, it would loop through all the map keys(sessions) and compare the session Ids and find a match that way. Those session ids always remained the same on each call. Once that was added everything started working.

Hopefully this makes some sense the way I explained it...

My real question is why was I getting back a new HttpSession instance each time? I am guessing this has something to do with how Iplanet/SunOne works, but I haven't found any explanation yet. Has anyone else seen this? Can anyone shed some light on this? If not... hopefully someone else will find this useful down the road and help solve their problem.

Any info/help/explanation you can provide is appreciated.

-- Tim Bass

This makes perfect sense. A foreign object should not be used as a key to the WikiSession map. There is no guarantee that the HttpSession object provided by the container will be the same between HTTP requests. An examples of this is the JDBC Session Store that can be used with Tomcat.

My question is why the WikiSession isn't stored in the HttpSession. That would seem to be the natural way to do things. Then if you need to take some action on session creation/expiration you use HttpSessionListener's.

-- Glenn Nielsen


I uploaded two patch files which fix this bug.

SessionMonitor.java was modified to use the container for storing WikiSession's. With this change it no longer needs to run as a background thread. This simplifies the management of WikiSession's and allows it to work no matter how a container might manage HttpSession's internally. This also will allow WikiSessions to survive container or web application restarts. WikiSession was modified to remove the code to start the SessionMonitor background thread.

You need to add the following to the web.xml after the filter-mappings.

   <!--
       HttpSessionListener used for managing WikiSession's.
     -->
   <listener>
      <listener-class>com.ecyrd.jspwiki.auth.SessionMonitor</listener-class>
   </listener>
One additional change is needed. WikiSession should implement java.io.Serializable so that it can be marshalled out with the HttpSession by the container to persistent storage during a container or web application restart or if HttpSession's are clustered between multiple application servers or stored in a database.

--Glenn Nielsen, 01-Nov-2006


One final note. I subscribed using mailman to both the JSPWiki dev and user lists. I never received an subscription e-mails. It sure would be easier to discuss these types of bugs and patches on a mailing list.

--Glenn Nielsen, 01-Nov-2006

Yes, they would be. I'm a bit worried that you didn't receive the subscription emails. Can you try again? If it still does not work, send me private email.

Andrew, do you have a comment on these?

-- JanneJalkanen, 01-Nov-2006

Add new attachment

Only authorized users are allowed to upload new attachments.

List of attachments

Kind Attachment Name Size Version Date Modified Author Change note
patch
SessionMonitor.patch 8.6 kB 1 01-Nov-2006 07:55 206.152.117.245
patch
WikiSession.patch 0.4 kB 1 01-Nov-2006 07:54 206.152.117.245
« This particular version was published on 01-Nov-2006 10:27 by JanneJalkanen.