nother poster used ServletContext.getRealPath(), but that won't work if
> you have an unexpanded WAR file at work. This one should work all the
time.
>
> Don't forget to read the documentation on this method and to
AFAIK Tomcat does not call System.exit() - at least did not in version
4.1.*, when we solved the very same problem.
T.
Christopher
Schultz
At JVM shutdown, the JVM is terminated only if all remaining running
threads are daemon threads.
Therefore, if the application starts own threads, it is necessary to ensure
that
1) either all these threads are destroyed before JVM shutdown by calling
the stop() method for each of the threads,
2)
quest IP be spoofed?
Long
- Original Message -
From: "Tomas Hulek" <[EMAIL PROTECTED]>
To: "Tomcat Users List"
Sent: Thursday, August 10, 2006 12:06 PM
Subject: Re: Session hijacking with Tomcat/Myfaces - unable to fix it
>
> We have tried it, but the internal s
Unfortunately, filters are skipped (ie. not called at all) when form-based
login page is processed as a result of client requesting a secure area.
We tried that too...
By the way, the original URL that the client requested is hidden in the
session in a way which prevents the web app from copying
st throwing out an idea for you...
--David
Tomas Hulek wrote:
>Unfortunately, the fundamentally bad security scheme is how the JS API
>specification is implemented in Tomcat (when using form-based
>authentication).
>
>When processing a form-based authetication request under HTTPS
"Kim Albee" <[EMAIL PROTECTED]> wrote on 10.08.2006 03:06:53:
> It's a fundamentally bad security scheme to use the session-ID as the
> identifier for your users. Might be straight forward, but
architecturally a
> bad choice if you *really* want a secure area.
>
&
making Tomcat regenerate the
session ID once user swichtes to HTTPS. We tried many approaches, and all
of them break some part of the JSF application.
Thank you for your help,
Tomas Hulek
-
To start a new topic, e-mail: users
