Here are two compromises that might work for you: 1) Reduce the session timeout to something less than 30 minutes, 10-15 minutes might provide a sufficient user experience. 2) Code your pages so that a user is prevented from viewing no restricted pages unless they log out. This will give the user incentive to explicitely logout. Or if they leave without logging out, render their session invalid, therebye implicitly logging them out. Of course, this will probably require you to set the user's expectations beforehand. Implement SessionBinding so that you can monitor when someone's session has ended. Put references to sessions in the ServletContext with a key comprised of the user's session id and any other string that might help identify the action or applications they were using. Then create tools that monitor/manage all active session using the key names. The faceless applet method is by far the most superior. I've done the applet method and it is reliable, as long as your user's can put up with the time it takes to load. It would be a minimilistic applet so it should load relatively fast. On an intranet it shouldn't even be an issue. -ernie "K.V. Chandrinos" wrote: > Dear all, > > I would like to ask assistance at the design level of logout tracking. I > am aware of the stateless nature of HTTP, etc. but I am involved in a > project with partial control of the general design. I am sure it has > happened to the best of you, at least once. > > The problem I need to solve: > > A web based information system with registered users is to be monitored > for user-modelling purposes. The nature of the service (financial news) > allows for inactive browsing. The information complexity might require the > user to open a second instance of the browser. The user-modelling team is > NOT satisfied with session time-out solutions because the user might have > stranded 25 of the 30 mins time-out limit to other sites (they have to > live with the fact that he/she might be for coffee). > > The aim is to signal back to the server if the poor user tries to escape. > A servlet's doPost() could tidy up things, and the user might be prompted > for certain actions if appropriate. > > I guess it is not the first time this scenario is aired in the list, but I > have not been able to find a 'proper' solution in the archives. > > I have been looking into JavaScript's onUnload() capability but cannot > figure out how to configure this with multiple instances of browsers when > the user decides to kill just one of them or type a URL in one of them. > There's an onBeforeUnload() available only to IE 5.0 > > I have also been looking into 'invisible' applets, to utilise their > destroy() method for talking back to the servlet and this seems quite more > reasonable, because an instance 'registry' can be kept at the server for > each user. If this drops to zero, the user is out. The question is, is > this reliable? Has anybody tried it in a real project? Are there any other > more robust, more elegant or more correct solutions that I am missing? > > Thank you, > Kostas > > ___________________________________________________________________________ > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > of the message "signoff SERVLET-INTEREST". > > Archives: http://archives.java.sun.com/archives/servlet-interest.html > Resources: http://java.sun.com/products/servlet/external-resources.html > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
begin:vcard n:Varitimos;Ernie tel;cell:781-929-3856 tel;home:781-784-1997 tel;work:781-784-3900 x-mozilla-html:TRUE url:http://www.skyserver.com org:Skyserver Consulting, Inc. adr:;;144 Upland Rd;Sharon;MA;02067; version:2.1 email;internet:[EMAIL PROTECTED] title:President fn:Ernie Varitimos end:vcard
