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 <kalle.o.korho...@gmail.com> 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 > <mike.oestere...@gmail.com> 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 >> <kalle.o.korho...@gmail.com> 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 >>> <mike.oestere...@gmail.com> 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 >>>> <thiag...@gmail.com> 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: users-unsubscr...@tapestry.apache.org >>>> For additional commands, e-mail: users-h...@tapestry.apache.org >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: users-h...@tapestry.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
