On Tue, Mar 4, 2008 at 11:38 PM, Warren <[EMAIL PROTECTED]> wrote: > I was thinking that leaving the session validated may cause problems > elsewhere. I am now thinking I should invalidate the session when I auto > logoff and then store a message for that device in some kind of device > specific message queue in my application. I already track each device's > unique id with a cookie, so I could look up any message for the device's > login page by device id from its cookie. That would work too. If you do not invalidate it might be possible on a shared pc to retrace the steps of the previous user, you would not be able to make changes but you could see whatever they did (backwards that is) using the browser history. So it is indeed better to invalidate, and given the story below i think your solution is better. > > Also, does it matter to wicket or the session how and from where a session > gets invalidated. I mean, is ok for one session to invalidate another?
That is a good question, i am guessing it is ok to do so but maybe some containers like glassfish prevent this if your app does not have enough permissions (jaas permissions). Anyway i am taking a wild guess here, maybe someone else knows. > > I know that some of the things I am talking about may sound like overkill or > useless, but this app runs on wireless pda scanning devices that are used in > grocery stores. They get left on grocery shelves and can be picked up and > used by anybody. The security requirements for this type of device is much > different than that of a pc in an office somewhere. > Very interesting, i am guessing you have a very short session timeout? or otherwise require your users to re-authenticate themselfs after a period of inactivity? after all any one could pick up such a devise and continue where an authenticated user left. Perhaps you are even using somekind of proximity hardware (bluethoot?) that locks the pda when a user wanders off to far? Maurice --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
