Excuse me, I understand that I should not invalidate the session from the directly from the httpsession object. But how can I access the httpsession object through tapestry in the first place ? Or the mentioned "Session" object ?
A link to the page discussing this topic would be great. Thank you in advance. On Tue, Oct 26, 2010 at 9:10 AM, Markus Joschko <markus.josc...@gmail.com>wrote: > 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 > > -- *Regards,* *Muhammad Gelbana Java Software Programmer*
