You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2015/04/28 09:58:17 UTC
[Bug 57865] New: session.invalidate does not work when during
startup war file is deployed
https://bz.apache.org/bugzilla/show_bug.cgi?id=57865
Bug ID: 57865
Summary: session.invalidate does not work when during startup
war file is deployed
Product: Tomcat 7
Version: 7.0.61
Hardware: PC
OS: Linux
Status: NEW
Severity: critical
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: alessandro.trolli@gmail.com
We have a webapp using org.apache.catalina.authenticator.SingleSignOn Valve and
defining security constraints and Form based authentication.
calling session.invalidate doesn't properly destroy the session and Principal
remains set only when war file is deployed during tomcat startup.
Proceeding with a restart without any war unpacking/deploy works properly.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57865] session.invalidate does not work when during startup war
file is deployed
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57865
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |WORKSFORME
--- Comment #7 from Mark Thomas <ma...@apache.org> ---
This works as expected for me with trunk. I also don't see any changes between
7.0.59 and 7.0.61 that might explain any odd behavoir.
If this issue is re-opened then the *exact* steps to reproduce the issue with
the latest stable 7.0.x release need to be provided. A clear description of the
observed behabiour, the expected behaviour and what the differences are is also
required.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57865] session.invalidate does not work when during startup war
file is deployed
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57865
--- Comment #1 from Alessandro Trolli <al...@gmail.com> ---
same webapp and configuration is working properly with version 7.0.59
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57865] session.invalidate does not work when during startup war
file is deployed
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57865
--- Comment #5 from Alessandro Trolli <al...@gmail.com> ---
I'm actually not able to reproduce using a simple webapp (please find in
attachements war and config files)
but even with complete webapp result is not deterministic.
The thing I've observed during first debug session is that Principal was
available after logout (calling session.invalidate and issuing a client
redirect to root context) without being redirect to authentication form by
SingleSignOn valve
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57865] session.invalidate does not work when during startup war
file is deployed
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57865
Violeta Georgieva <vi...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution|--- |WORKSFORME
--- Comment #11 from Violeta Georgieva <vi...@apache.org> ---
Hi,
I can confirm that the scenario is working with the current Tomcat 7 trunk.
Regards,
Violeta
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57865] session.invalidate does not work when during startup war
file is deployed
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57865
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution|--- |INVALID
--- Comment #9 from Mark Thomas <ma...@apache.org> ---
Re-closing as INVALID since the requested information was not provided.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57865] session.invalidate does not work when during startup war
file is deployed
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57865
Alessandro Trolli <al...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |---
--- Comment #10 from Alessandro Trolli <al...@gmail.com> ---
given provided web app and configuration files
steps to reproduce in 7.0.61 are:
* deploy the webapp twice in different contexts (e.g. /sso1 and /sso2)
* open http://localhost:8080/sso1/: it redirects to login form
* log in as tomcat user
* open http://localhost:8080/sso2/: user gets automatically authenticated
through sso feature
* click on logout on any of the two sessions
* user gets immediately reauthenticated because ssoid hasn't been deregistered
same steps in 7.0.59 allow the user to logout from both contexts
I've seen that code has changed again to accomodate
https://issues.apache.org/bugzilla/show_bug.cgi?id=57338
I haven't tested on trunk
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57865] session.invalidate does not work when during startup war
file is deployed
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57865
--- Comment #4 from Alessandro Trolli <al...@gmail.com> ---
Created attachment 32701
--> https://bz.apache.org/bugzilla/attachment.cgi?id=32701&action=edit
config files
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57865] session.invalidate does not work when during startup war
file is deployed
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57865
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--- Comment #2 from Mark Thomas <ma...@apache.org> ---
Define "doesn't properly destroy the session".
Please also provide the steps to recreate this from a clean install of Tomcat
7.0.61.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57865] session.invalidate does not work when during startup war
file is deployed
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57865
--- Comment #3 from Alessandro Trolli <al...@gmail.com> ---
Created attachment 32700
--> https://bz.apache.org/bugzilla/attachment.cgi?id=32700&action=edit
Sample Webapp
sample webapp used for debug (working on 7.0.61)
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57865] session.invalidate does not work when during startup war
file is deployed
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57865
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
--- Comment #6 from Mark Thomas <ma...@apache.org> ---
The detail on this issue is still sketchy but I'll take a look at the provided
web applicaion and see if that clarifies things.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57865] session.invalidate does not work when during startup war
file is deployed
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57865
Alessandro Trolli <al...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|WORKSFORME |---
--- Comment #8 from Alessandro Trolli <al...@gmail.com> ---
(In reply to Mark Thomas from comment #7)
> This works as expected for me with trunk. I also don't see any changes
> between 7.0.59 and 7.0.61 that might explain any odd behavoir.
>
> If this issue is re-opened then the *exact* steps to reproduce the issue
> with the latest stable 7.0.x release need to be provided. A clear
> description of the observed behabiour, the expected behaviour and what the
> differences are is also required.
I've tried to debug further: in my case it doesn't enter in deregister method
called by SingleSignOn.removeSession(String ssoId, Session session)
because following condition is not met
// If there are not sessions left in the SingleSignOnEntry,
// deregister the entry.
if (entry.findSessions().length == 0) {
deregister(ssoId);
}
Analyzing code changes I've noticed that sessionEvent(SessionEvent event)
method has the following part changed
long idle;
if (LAST_ACCESS_AT_START) {
idle = session.getLastAccessedTimeInternal();
} else {
idle = session.getThisAccessedTimeInternal();
}
if (((session.getMaxInactiveInterval() > 0)
&& idle >= session.getMaxInactiveInterval() * 1000)
|| (Session.SESSION_PASSIVATED_EVENT.equals(event.getType()))
|| (!session.getManager().getContainer().getState().isAvailable()))
{
removeSession(ssoId, session);
} else {
// The session was logged out.
// Deregister this single session id, invalidating
// associated sessions
deregister(ssoId);
}
while in 7.0.59 removeSession was called looking at (System.currentTimeMillis()
- session.getThisAccessedTimeInternal()
if (((session.getMaxInactiveInterval() > 0)
&& (System.currentTimeMillis() -
session.getThisAccessedTimeInternal() >=
session.getMaxInactiveInterval() * 1000))
|| (Session.SESSION_PASSIVATED_EVENT.equals(event.getType()))
|| (!session.getManager().getContainer().getState().isAvailable()))
{
removeSession(ssoId, session);
} else {
// The session was logged out.
// Deregister this single session id, invalidating
// associated sessions
deregister(ssoId);
}
can you please check if above change can interfer
how can I force to call deregister method?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org