Do you know any webframework that allows that? We recently had the same requirement but finally went the route to use an extra id in a https only cookie that was set during login. Not as nice as using the container supported session id but it works fine.
Markus On Mon, Oct 25, 2010 at 5:18 PM, Kalle Korhonen <[email protected]> wrote: > But typically, you'd just invalidate the session which of course > forces a new session id. > > Kalle > > > On Mon, Oct 25, 2010 at 12:21 AM, Mike Oestereter > <[email protected]> wrote: >> Hi >> >> In my mind it is not a peculiar requirement but a basic security 101 >> requirement. >> Session ID should change after login, after logoff and after reauth >> (for sensitive operations). >> >> >> On Wed, Oct 20, 2010 at 1:51 AM, Kalle Korhonen >> <[email protected]> wrote: >>> That's a rather peculiar requirement. Sessions are semi-managed by the >>> container and I don't know of a container that would allow you to do >>> that. If you used Shiro in native session mode, you could probably >>> change the id but even then, you'd need to cast and use the >>> implementation classes directly. >>> >>> Kalle >>> >>> >>> On Tue, Oct 19, 2010 at 2:40 PM, Mike Oestereter >>> <[email protected]> wrote: >>>> The problem is that I don't want to invalidate the session from an >>>> application point of view. >>>> >>>> After successful login I want to store details about the authenticated >>>> user in the user session. >>>> >>>> I just want to kill the existing cookie and associate a new (and >>>> different cookie) with the current session. >>>> >>>> >>>> On Mon, Oct 18, 2010 at 3:13 PM, Thiago H. de Paula Figueiredo >>>> <[email protected]> wrote: >>>>>> Grabbing the session and invalidating directly does the trick but >>>>>> you have to be sure this occurs at the end of the request - otherwise >>>>>> Tapestry may try to reuse the session and because that has been >>>>>> invalidated you'd get exceptions. >>>>> >>>>> As long as you invalidate it through Tapestry (Session.invalidate()) >>>>> instead >>>>> of directly through HttpSession.invalidate(), I don't think exceptions >>>>> will >>>>> be thrown. >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
