On Tue, 26 Oct 2010 12:14:43 -0200, Muhammad Mohsen
wrote:
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 ?
Ge
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 i
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, Ka
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
wrote:
> Hi
>
> In my mind it is not a peculiar requirement but a basic security 101
> requirement.
> Session ID should change after login, after log
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
wrote:
> That's a rather peculiar requirement. Sessions are semi-m
Hi,
I thought it would be a nice security update to add this fix to my
application, but I seem to be having a hard time finding out exactly
where to invalidate the Tapestry session without getting exceptions.
I have a Dispatcher that controllers page access and manages my internal
session im
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.
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 sessio
On Mon, Oct 18, 2010 at 1:45 PM, Thiago H. de Paula Figueiredo
> Are you sure? This doesn't make a lot of sense.
As you can have more than
> one session state object, changing the session id would be the same as
> invalidating the session. This would be a serious bug.
>
I'm pretty sure - will try
On Mon, 18 Oct 2010 10:26:00 -0200, Andreas Andreou
wrote:
Yea, that's session fixation...
see http://www.owasp.org/index.php/Session_Fixation
Thanks for the link! :)
Grabbing the session and invalidating directly does the trick but
you have to be sure this occurs at the end of the reques
Yea, that's session fixation...
see http://www.owasp.org/index.php/Session_Fixation
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
yo
On Mon, 18 Oct 2010 08:47:05 -0200, Mike Oestereter
wrote:
Hi
Hi!
How can I change the value of the JSESSIONID cookie after
succcessfull login - failure to do this will result in a session
hijacking vulnerability.
The session cookie is created and removed by the servlet container
(se
Hi
How can I change the value of the JSESSIONID cookie after
succcessfull login - failure to do this will result in a session
hijacking vulnerability.
I'm not using Spring or AECGI (sp?) and am not interested in it at the moment.
In tapestry 5.0 the value of the cookie (somewhat magically and
un
13 matches
Mail list logo
