Re: Filter behaviour
On Fri, Jun 26, 2015 at 11:09 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Leo,
>
> >
> > If I use a return statement to break out of a filter, what should
> > happen? Will the next filter run?
>
> No. The Filter is responsible for calling the next filter in the
> chain. If you don't, the target servlet will never be called.
>
> > Shouldn't a return statement in a filter, especially one that
> > comes right after a sendError call, send the error and direct the
> > user to the page configured for such errors?
>
> Yes.
>
> > The scenario I'm working on is a web service. The web service has
> > three filters, in order they are: throttle filter, authentication
> > filter, logging filter.
> >
> > If a user is not authenticated, the following code "should" break
> > out of the filter chain and redirect the user to a custom 403. It
> > works nice on Tomcat.
> >
> > HttpServletResponse httpResponse = (HttpServletResponse) response;
> >
> > httpResponse.sendError(HttpServletResponse.HttpServletResponse.SC_FORB
> IDDEN);
> >
> >
> return;
> >
> > What I'm seeing on other containers is that I get a NPE where the
> > Service class is trying to do something with the authenticated
> > user, which is null. I realize this is not an "other containers"
> > forum, but I was just curious what the expected behaviour *should*
> > be.
>
> If you have other stuff going on -- like custom error pages -- you
> might find that more of your own code is running than you expect. See
> Konstantin's response. It's terse, but I think he's likely getting to
> the root of your problem.
>
> - -chris
>
Gentlemen,
Thank you for the assistance.
I still don't know what was causing my issue on said other container with
respect to sendError and custom error-page elements, but...
This works fine and was really what I was after, a simple custom 403
message, no html:
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException
{
boolean iAmNotAuthorized = true;
if (iAmNotAuthorized)
{
// generate the HTTP Servlet Response for a 403 status code
HttpServletResponse httpResponse = (HttpServletResponse)
response;
//httpResponse.sendError(HttpServletResponse.SC_FORBIDDEN);
httpResponse.setStatus(HttpServletResponse.SC_FORBIDDEN);
httpResponse.setHeader("WWW-Authenticate", "Basic");
httpResponse.getOutputStream().print("blah, blah, blah");
// return from the doFilter method
return;
}
chain.doFilter(request, response);
}
leo
Re: SSL configuration using PFX as keystore
On 22/06/2015 11:56, Mark Thomas wrote: > On 22/06/2015 09:39, Mark Thomas wrote: > Prompting for authentication in response to an untrusted certificate is > bizarre to say the least. > > Microsoft generously provide MSDN subscriptions for Apache committers > which is why I have the various OS's to hand to test this. The > subscription also comes with tech support. I'll open an incident. It > will be interesting to see if things have improved since I last tried > raising bugs with Microsoft (I filed so many bugs with MS Office and it > took so long for MS to fix them that I hit the limit of issues MS would > let me have open in parallel). Support incident raised. I await the response with interest... Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0.63 release date known?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Maarten, On 6/10/15 7:43 AM, Maarten van Hulsentop wrote: > Dear Tomcat users, > > We are using Apache Tomcat 7 to run our product on, using a number > of features of the Tomcat product, such as the SPNego mechanism. > For security reasons we keep up with the latest supported versions > of both Tomcat and the Oracle JRE. Lately, we have found out that > the regression bug introduced in the Oracle JRE now causes the > SPNego authentication to fail. > > We see that this is fixed with a work around (the new attribute > applyJava8u40Fix controls this) in Tomcat 8.0.23 release (yay!) and > after some investigation i see this is on the changelog for 7.0.63 > as well. Good news for us! :) > > My question would be if there is a release date available for the > Tomcat 7 product? > > Thanks and keep up the great work (even fixing /workarounding > Oracles bugs ;) ) Soonish ;) http://tomcat.markmail.org/thread/juktzcism34cwnw2 - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVjYT/AAoJEBzwKT+lPKRYcTQP+QFyr1DKUD1XvVgyHNI4WC/E gCKpeYbBU3vbR5LewkzE2khDF5HouDxEzf81On0JpbOgCgV6baYt0/w8AJ3qbUQh /67wW9f5oso6rZqAMuJ9UWKCyZ6r74bfggQPMOBRG6UMBKsk9JAOC7Ow/ZV+8qiE pxDma//K2YmbA5DPS7FKI+2kqg35Q2eR28X5Jp8Y/aHF2A5OqMKjSXyMRaKvPGcj 3DTuuYxX3Ml3V0MsDNu3cRIkrxq4U7TOOq+YYOIa5aYsf6I//XA2fpg41u9osThZ kjQQNggyTrX60kRYvRnwqQupy0EZz02Y+nik7EYG/o2sO/+BM9jzbk3xy2Op/u7y 4+8/9NrqyilHHk/tL+ItNEyIe2HhiL03LNEEAIVhBygjUeLoM+9u5MmUrVaAktDa 7GiFZt62TfXzF45EsCmJAEglc57FAfkA1t/GfUHeDqZP/Y8CAOq7YNy1B84KioDf u6jr/6foxqieCDnzPtB4NUB31mNosgUduhsEIfpPDBtCot2DFH6PUbpKoREXJLpf r5VnJe1vvmPWalKfoQXpyTP5rnUKV+XxyF3U9/uDCo3kEhm8gdPvNd8kVocEvp5b JBUvYHhRVihA2011qHIFtXCmMJIvBZq+KIjXXZrp2WdApKgsKfRwrw35lZUjtZfK 18djWixlhtid53nP596N =JyBs -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Forcing SSL Renotiation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
George,
On 6/26/15 12:34 PM, George Stanchev wrote:
> Agree on point 2 & 3. Since we are in control of the application
> server, we have the luxury of managing the SSL engine and the
> Security Manager settings. I guess I should've provided a link to
> the ssl-howto doc [1] that describes that solution. I went the
> reflection way to avoid having to link with Tomcat in our build
> scripts. There is discussion [2] on this issue referenced by [1].
Yeah, I think reflection is the way to go, given the current
requirements for accessing that object and working with it.
It might make sense to have a setting in Tomcat that invalidates the
SSL session when a CLIENT-CERT-based user session is invalidated (i.e.
HttpSession.invalidate() -> SSLSessionManager.invalidate()).
> Regarding 1 - I also found it odd but I guess that’s not mandated
> by the standard so they have to return something.
Well, it seems reasonable to make an object of this type available,
even if it can only really invalidate the session, currently.
> It is better to return abstraction than concrete JSSE object in
> case the underlying implementation changes.
+1
Really, my only objection was to using the javax.servlet namespace. I
don't recall the Servlet spec prohibiting such practices, but because
the object is stored under that namespace, it may suggest to the user
that it's a Servlet spec-defined object/behavior/etc. when it clearly
isn't.
> BTW why is this not working with OpenSSL/native? Is there a
> technical reason or just not implemented?
I didn't even try it; I just opened the SSLSessionManager interface
and asked Eclipse where it was used in the rest of the project. The
only result was a class in the jsse package, which led me to believe
that there is no analog for APR. I may be wrong, but I'd be surprised
if a JSSE-related class is being used along with the APR/native connecto
r.
(Of course, there's a new OpenSSL-based JSSE provider in trunk right
now. Who knows what will be possible in the future. I for one will be
quite happy to use OpenSSL crypto along with an NIO or NIO2 connector
within Tomcat.)
- -chris
> -Original Message- From: Christopher Schultz
> [mailto:ch...@christopherschultz.net] Sent: Friday, June 26, 2015
> 10:06 AM To: Tomcat Users List Subject: Re: Forcing SSL
> Renotiation
>
> George,
>
> On 6/26/15 10:04 AM, George Stanchev wrote:
>> You didn't specify your Tomcat version. In Tomcat 7 or 8 or 9 we
>> use the following code. Not sure if it will work on 6. For a
>> long time until very recently we were stuck on 5.5 and the
>> attribute below is not available. So I had to write a reflection
>> introspection to drill down to the SSLSessionManager held by the
>> Tomcat objects under the server request.
>
>> Keep in mind the client cert implementation on the browsers is
>> not uniform in behavior (in respect of resetting a session and
>> letting the user chose another cert on relogin). We support FF,
>> Chrome and IE and by far so far IE has been the most consistent.
>> Later releases of Chrome cache the smartcard connection and
>> resubmit the same cert on reconnect and nothing you can do on the
>> server can change this (as far as I know). The JS-side crypto
>> support (to reset the state) is poor, FF-specific and unreliable.
>> Firefox has it's own set of issues.
>
> A couple of things:
>
> 1. I find it odd that Tomcat is using the javax.servlet namespace
> for an implementation-specific class. I would argue this doesn't
> belong under the key that's currently being used.
>
> 2. The SSLSessionManager seems to be unique to JSSE-based
> implementations of TLS in Tomcat, which means that this technique
> isn't going to work if you are using tcnative and OpenSSL-based
> crypto.
>
> 3. This code isn't going to work under a SecurityManager unless
> you make arrangements to configure the privileges for your code
> properly.
>
> -chris
>
>> // Invalidate the SSL Session
>> (org.apache.tomcat.util.net.SSLSessionManager) Method
>> invalidateSessionMethod = null; Object mgr =
>> httpRequest.getAttribute("javax.servlet.request.ssl_session_mgr");
>> if (mgr != null) { try { invalidateSessionMethod =
>> mgr.getClass().getMethod("invalidateSession"); if
>> (invalidateSessionMethod == null) { log.error("Failed to reset
>> SSL session: Method invalidateSessionMethod =
>> mgr.getClass().getMethod(\"invalidateSession\") failed to return
>> method"); } invalidateSessionMethod.setAccessible(true); } catch
>> (Throwable t) { log.error("Failed to reset SSL session: " +
>> t.getMessage(), t); }
>
>> // Invalidate the session try {
>> invalidateSessionMethod.invoke(mgr); log.trace("SSL session reset
>> successfully"); return true; } catch (Throwable t) {
>> log.error("Failed to reset SSL session: invalidateSession() threw
>> exception: " + t.getMessage(), t); }
>
>> -Original Message- From: Steffen Heil (Mailinglisten)
>> [mailto:l
RE: Forcing SSL Renotiation
Hi Chris,
Agree on point 2 & 3. Since we are in control of the application server, we
have the luxury of managing the SSL engine and the Security Manager settings. I
guess I should've provided a link to the ssl-howto doc [1] that describes that
solution. I went the reflection way to avoid having to link with Tomcat in our
build scripts. There is discussion [2] on this issue referenced by [1].
Regarding 1 - I also found it odd but I guess that’s not mandated by the
standard so they have to return something. It is better to return abstraction
than concrete JSSE object in case the underlying implementation changes. BTW
why is this not working with OpenSSL/native? Is there a technical reason or
just not implemented?
George
[1] https://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html
[2] https://bz.apache.org/bugzilla/show_bug.cgi?id=22679
-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Friday, June 26, 2015 10:06 AM
To: Tomcat Users List
Subject: Re: Forcing SSL Renotiation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
George,
On 6/26/15 10:04 AM, George Stanchev wrote:
> You didn't specify your Tomcat version. In Tomcat 7 or 8 or 9 we use
> the following code. Not sure if it will work on 6. For a long time
> until very recently we were stuck on 5.5 and the attribute below is
> not available. So I had to write a reflection introspection to drill
> down to the SSLSessionManager held by the Tomcat objects under the
> server request.
>
> Keep in mind the client cert implementation on the browsers is not
> uniform in behavior (in respect of resetting a session and letting the
> user chose another cert on relogin). We support FF, Chrome and IE and
> by far so far IE has been the most consistent. Later releases of
> Chrome cache the smartcard connection and resubmit the same cert on
> reconnect and nothing you can do on the server can change this (as far
> as I know). The JS-side crypto support (to reset the state) is poor,
> FF-specific and unreliable. Firefox has it's own set of issues.
A couple of things:
1. I find it odd that Tomcat is using the javax.servlet namespace for an
implementation-specific class. I would argue this doesn't belong under the key
that's currently being used.
2. The SSLSessionManager seems to be unique to JSSE-based implementations of
TLS in Tomcat, which means that this technique isn't going to work if you are
using tcnative and OpenSSL-based crypto.
3. This code isn't going to work under a SecurityManager unless you make
arrangements to configure the privileges for your code properly.
- -chris
> // Invalidate the SSL Session
> (org.apache.tomcat.util.net.SSLSessionManager) Method
> invalidateSessionMethod = null; Object mgr =
> httpRequest.getAttribute("javax.servlet.request.ssl_session_mgr");
> if (mgr != null) { try { invalidateSessionMethod =
> mgr.getClass().getMethod("invalidateSession"); if
> (invalidateSessionMethod == null) { log.error("Failed to reset SSL
> session: Method invalidateSessionMethod =
> mgr.getClass().getMethod(\"invalidateSession\") failed to return
> method"); } invalidateSessionMethod.setAccessible(true); } catch
> (Throwable t) { log.error("Failed to reset SSL session: " +
> t.getMessage(), t); }
>
> // Invalidate the session try {
> invalidateSessionMethod.invoke(mgr); log.trace("SSL session reset
> successfully"); return true; } catch (Throwable t) { log.error("Failed
> to reset SSL session: invalidateSession() threw
> exception: " + t.getMessage(), t); }
>
> -Original Message- From: Steffen Heil (Mailinglisten)
> [mailto:li...@steffen-heil.de] Sent: Friday, June 26, 2015 2:43 AM
> To: Tomcat Users List Subject: Forcing SSL Renotiation
>
> Hi
>
>
> My tomcat installation offers pages through https only. So when
> accessing these pages, an ssl connection is established. Later on, a
> user may decide to "log in", hence hitting a page, that requires
> client certificates, and the browser pops up a selection dialog for a
> certificate. Once chosen, the server recognized the user by its
> certificate, and everything is fine. So far, so good.
>
> Now I have 2 problems:
>
> 1. When clicking "logout" in the application, the server terminates
> its internal session for that user, but the ssl connection is not
> terminated. That means, as soon as anyone clicks login again, the old
> certificate is reused. So the user cannot login using another
> certificate.
>
> 2. The second problem with that is, that if the certificate was on a
> smartcard and that card was removed, that cannot be detected.
>
> Is there any way to tell tomcat to tell the browser to drop the tls
> session state and "restart"?
>
>
> Regards, Steffen
>
>
> -
>
>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
-BEGIN PGP SIG
Re: Filter behaviour
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Leo, On 6/26/15 10:38 AM, Leo Donahue wrote: > On Fri, Jun 26, 2015 at 1:42 AM, André Warnier > wrote: > >> >> I must admit that your question above was a bit difficult to >> follow, in terms of if/then/else/unless, particularly late at >> night. > > > Yes, you are right. Sorry about that. I was trying to walk the > line between saying too much and not enough and so it came out all > gibberish. > > >> And the last paragraph made me think that perhaps the Tomcat logo >> might lead you to personalise things a bit more than is really >> healthy. (Or else I want to have a look at that code, because the >> Tomcat developers must be even smarter that I thought). >> >> But if your question in the end boils down to : *must* a filter >> necessarily call the next filter/webapp in the chain, then the >> answer is in the Servlet Specification. E.g. Servlet Spec v 3.0 >> final, Chapt 6 Filtering, Section 6.2 Main concepts, item 4 : >> "The filter *may* invoke the next entity in the filter chain".. >> It even adds : "Alternatively, the filter chain can block the >> request by not making the call to invoke the next entity, leaving >> the filter responsible for filling out the response object." >> >> (What you need to do then still, is to insure that you do indeed >> generate a valid response, whether it's an error or not. That's >> maybe the point where different containers may react slightly >> differently.). >> > > If I use a return statement to break out of a filter, what should > happen? Will the next filter run? No. The Filter is responsible for calling the next filter in the chain. If you don't, the target servlet will never be called. > Shouldn't a return statement in a filter, especially one that > comes right after a sendError call, send the error and direct the > user to the page configured for such errors? Yes. > The scenario I'm working on is a web service. The web service has > three filters, in order they are: throttle filter, authentication > filter, logging filter. > > If a user is not authenticated, the following code "should" break > out of the filter chain and redirect the user to a custom 403. It > works nice on Tomcat. > > HttpServletResponse httpResponse = (HttpServletResponse) response; > > httpResponse.sendError(HttpServletResponse.HttpServletResponse.SC_FORB IDDEN); > > return; > > What I'm seeing on other containers is that I get a NPE where the > Service class is trying to do something with the authenticated > user, which is null. I realize this is not an "other containers" > forum, but I was just curious what the expected behaviour *should* > be. If you have other stuff going on -- like custom error pages -- you might find that more of your own code is running than you expect. See Konstantin's response. It's terse, but I think he's likely getting to the root of your problem. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVjXlRAAoJEBzwKT+lPKRYKbIP/1qu3FTeXTe/npc0b8V+A6rQ NQ25s9gd/d1araILYRPViDS56k7hFGHLO82OBuJ+LPAIK4fn0wWM3fSbIw8VRAac nksimpXVYIjW6d7Q5im1osoBO7WBJJBfRRa+RsjvtbxSaWaYbtxW08irdH7gKBud HsitX1w2s252NUFyt6G37sPMtXTlNMyMVPgXJTq8iwnR7BR/bzFw514E1zEd9AX+ 98+MNP90044KqHDy33zWnYPU3aGR54uw6H+BfSDst4lSGWyVPzpo054WKsQuQEFu zglgB97iC78RLUbA2VaGo3K4CTQioAXEo25wn4jw/ls1fCMpCxWJTCivHHVutwnp B7q8qPtBx1mrLr+orGmkAPuNoVyLOGOhbsVY4P50iCXWN8aIGzc0uBE9D4rv919f iQgHHMaJajEmjuLNoJM15Kj2bc/oUvSCWyOEXMZGQuVN8FOAs2SLoeyuHXAfhzum 9MAiMhK1g4s16CqNWYtkG3ePcvAthaNB8ZOI7nNjOxa8Hr4PuET/Ram1MoX23d4g EuENlsj6DaIo0CGAWZv5Il3j6G4jUkjGyQFYU7xZN3ilBppmZN3h2xx6ZOReXNFd iq7KHbjfQSLEyjuCIV02I/VOAwKqJnU30T8aAcx93ftFzUxg6ixZD1zfEUwMlhvg JUn7r/FNXThidonZbGg4 =P26m -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Forcing SSL Renotiation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
George,
On 6/26/15 10:04 AM, George Stanchev wrote:
> You didn't specify your Tomcat version. In Tomcat 7 or 8 or 9 we
> use the following code. Not sure if it will work on 6. For a long
> time until very recently we were stuck on 5.5 and the attribute
> below is not available. So I had to write a reflection
> introspection to drill down to the SSLSessionManager held by the
> Tomcat objects under the server request.
>
> Keep in mind the client cert implementation on the browsers is not
> uniform in behavior (in respect of resetting a session and letting
> the user chose another cert on relogin). We support FF, Chrome and
> IE and by far so far IE has been the most consistent. Later
> releases of Chrome cache the smartcard connection and resubmit the
> same cert on reconnect and nothing you can do on the server can
> change this (as far as I know). The JS-side crypto support (to
> reset the state) is poor, FF-specific and unreliable. Firefox has
> it's own set of issues.
A couple of things:
1. I find it odd that Tomcat is using the javax.servlet namespace for
an implementation-specific class. I would argue this doesn't belong
under the key that's currently being used.
2. The SSLSessionManager seems to be unique to JSSE-based
implementations of TLS in Tomcat, which means that this technique
isn't going to work if you are using tcnative and OpenSSL-based crypto.
3. This code isn't going to work under a SecurityManager unless you
make arrangements to configure the privileges for your code properly.
- -chris
> // Invalidate the SSL Session
> (org.apache.tomcat.util.net.SSLSessionManager) Method
> invalidateSessionMethod = null; Object mgr =
> httpRequest.getAttribute("javax.servlet.request.ssl_session_mgr");
> if (mgr != null) { try { invalidateSessionMethod =
> mgr.getClass().getMethod("invalidateSession"); if
> (invalidateSessionMethod == null) { log.error("Failed to reset SSL
> session: Method invalidateSessionMethod =
> mgr.getClass().getMethod(\"invalidateSession\") failed to return
> method"); } invalidateSessionMethod.setAccessible(true); } catch
> (Throwable t) { log.error("Failed to reset SSL session: " +
> t.getMessage(), t); }
>
> // Invalidate the session try {
> invalidateSessionMethod.invoke(mgr); log.trace("SSL session reset
> successfully"); return true; } catch (Throwable t) {
> log.error("Failed to reset SSL session: invalidateSession() threw
> exception: " + t.getMessage(), t); }
>
> -Original Message- From: Steffen Heil (Mailinglisten)
> [mailto:li...@steffen-heil.de] Sent: Friday, June 26, 2015 2:43 AM
> To: Tomcat Users List Subject: Forcing SSL Renotiation
>
> Hi
>
>
> My tomcat installation offers pages through https only. So when
> accessing these pages, an ssl connection is established. Later on,
> a user may decide to "log in", hence hitting a page, that requires
> client certificates, and the browser pops up a selection dialog for
> a certificate. Once chosen, the server recognized the user by its
> certificate, and everything is fine. So far, so good.
>
> Now I have 2 problems:
>
> 1. When clicking "logout" in the application, the server terminates
> its internal session for that user, but the ssl connection is not
> terminated. That means, as soon as anyone clicks login again, the
> old certificate is reused. So the user cannot login using another
> certificate.
>
> 2. The second problem with that is, that if the certificate was on
> a smartcard and that card was removed, that cannot be detected.
>
> Is there any way to tell tomcat to tell the browser to drop the tls
> session state and "restart"?
>
>
> Regards, Steffen
>
>
> -
>
>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVjXhSAAoJEBzwKT+lPKRYBMYP/is27kGjYPqNxO8krxNxf9iO
0Y2BG9Qw/TJT0UKrT3jiBGo05UCJZ7stnvgybc0ZO3ImDigzOfW86c93lG6AjvXM
9XpwM/zAUvt5wHlftX/71eguhE1pqKLxFxLHcDBovmRV1rPVo2fn5+t9+rFpgX12
SIMCmZp8m9pjLYutryiWTjIwi96QduYAb/wKDFxhJGF/pibLFwUH9YxqUbScWJwe
FbhKjEC8RsfMgh3/UCEJDuRdPGjQlF/o5SInR7NNc92msYMEu2ruftKjG69BPxL4
+57hauBz1qfDtFjAAkb3oPtWrg/oLgqvCxiHifiWxmbp15q2kKWzTkZ5f8WegurB
xa1tJVWVKsosaWvTeRFJwDE2nMco1WYHXcm7kzhXbLvhjv7ElIDdinK8yWeAedL0
2nYQ6dzl41r/xRoPsaHkloxQMzzWSI8sCmETxEpa9GgzIdl+NPiflKA4chVWbJFe
YXOTbSCOS7WJ4JlE2l/tqeV6vzTshgb+z6eQWWKddKdu/pt4T+UuZt7NJMluV5/2
W05fWdIiZ4k3rDk4p+T7xbgGPv1sTwPWGtgNZt2CNq6vBhtwlHjNNQ/Faa56Cque
jomH8gkjjQg7eQ1W0f70aUaykVHkTK57oqjEFKn7o5xc4c3mN0oHmyyMlt23wq8g
mNoKnBMa0Zw9nNTvykcz
=0xVF
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat - OOM Perm gen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Kiran, On 6/25/15 6:32 PM, Kiran Badi wrote: > I have 2 web apps sitting on single tomcat instance, App A( > Classic JSP/Servlet/jstl/velocity App) and App B (Struts2 based > app). > > Now I have added S2 to App A and trying to fix some bad code in it > with it.But after making this change I keep getting out of OOM > issues once user count reaches to 75 The number of users shouldn't impact your PermGen space. Perhaps only once you get to that stage are you hitting enough of your features to load classes into PermGen. (Or maybe you are using String.intern a lot...). > + and App A seems to be bringing App B down with it. PermGen failures will effect the whole JVM. There is no way to protect App B from App A unless they are in different JVMs. > Below is trace I get in catalina out log. I think I can increase > memory Yes, you can. > but it will not solve this What makes you say that? It seems that you have more information than you are giving us. > and I have hard limit of memory with hosting provider. Usually, PermGen doesn't have to be enormous. What's your memory cap with your hosting provider? > Is their anything in tomcat that I need to enable which can give me > some mileage? There is nothing you can do in Tomcat to make your application load fewer classes. > How do I fix this ? You either need more PermGen space, or you need to locate some kind of leak in your application and fix it. IIRC, there are some RMI-related leaks and Proxy-related leaks in PermGen depending upon your exact circumstances. It would be good to know what's in PermGen when it hits its limit. What are your current heap settings, including PermGen? What JVM? Try: $ jmap -heap and $ jmap -permstat - -chris > Jun 24, 2015 6:49:19 PM > org.apache.catalina.core.ApplicationDispatcher invoke SEVERE: > Servlet.service() for servlet jsp threw exception > java.lang.OutOfMemoryError: PermGen space at > com.sun.beans.infos.ComponentBeanInfo.(ComponentBeanInfo.java: 35) > > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructo rAccessorImpl.java:57) > > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCo nstructorAccessorImpl.java:45) > > at java.lang.reflect.Constructor.newInstance(Constructor.java:525) > at java.lang.Class.newInstance0(Class.java:374) at > java.lang.Class.newInstance(Class.java:327) at > com.sun.beans.finder.InstanceFinder.instantiate(InstanceFinder.java:96 ) > > at com.sun.beans.finder.InstanceFinder.instantiate(InstanceFinder.java:1 07) > at > com.sun.beans.finder.BeanInfoFinder.instantiate(BeanInfoFinder.java:63 ) > > at com.sun.beans.finder.BeanInfoFinder.instantiate(BeanInfoFinder.java:4 1) > at > com.sun.beans.finder.InstanceFinder.find(InstanceFinder.java:81) at > java.beans.Introspector.findExplicitBeanInfo(Introspector.java:436) > > at java.beans.Introspector.(Introspector.java:386) > at java.beans.Introspector.getBeanInfo(Introspector.java:161) at > java.beans.Introspector.getBeanInfo(Introspector.java:248) at > java.beans.Introspector.(Introspector.java:395) at > java.beans.Introspector.getBeanInfo(Introspector.java:161) at > java.beans.Introspector.getBeanInfo(Introspector.java:248) at > java.beans.Introspector.(Introspector.java:395) at > java.beans.Introspector.getBeanInfo(Introspector.java:161) at > java.beans.Introspector.getBeanInfo(Introspector.java:248) at > java.beans.Introspector.(Introspector.java:395) at > java.beans.Introspector.getBeanInfo(Introspector.java:161) at > freemarker.ext.beans.BeansWrapper.populateClassMapWithBeanInfo(BeansWr apper.java:1147) > > at > freemarker.ext.beans.BeansWrapper.populateClassMap(BeansWrapper.java:1 072) > > at > freemarker.ext.beans.BeansWrapper.introspectClassInternal(BeansWrapper .java:1010) > > at freemarker.ext.beans.BeansWrapper.introspectClass(BeansWrapper.java:9 69) > at freemarker.ext.beans.BeanModel.(BeanModel.java:140) at > freemarker.ext.beans.StringModel.(StringModel.java:90) at > freemarker.ext.beans.StringModel$1.create(StringModel.java:75) at > freemarker.ext.beans.BeansModelCache.create(BeansModelCache.java:45) > > Jun 24, 2015 6:49:19 PM org.apache.struts2.dispatcher.Dispatcher > error SEVERE: Exception occurred during processing request: > javax.servlet.ServletException: java.lang.OutOfMemoryError: PermGen > space org.apache.jasper.JasperException: > javax.servlet.ServletException: java.lang.OutOfMemoryError: PermGen > space at > org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServ letWrapper.java:549) > > at > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper. java:455) > > at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:3 90) > at > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) at > org.apache.c
Re: Filter behaviour
2015-06-25 23:11 GMT+03:00 Leo Donahue :
> public void doFilter(ServletRequest request, ServletResponse response,
> FilterChain chain) throws IOException, ServletException
>
> Assuming you have only a single Filter configured in web.xml
>
> Assuming you have logic in a doFilter that checks the value of a boolean.
> If the boolean is true, then assume you send a http status code back and
> use a "return" in the if condition.
>
> example:
>
> if (someConditionIsTrue)
> {
> HttpServletResponse httpResponse = (HttpServletResponse)
> response;
> httpResponse.sendError(HttpServletResponse.WHATEVER_YOU_CHOOSE);
> return;
> }
>
> chain.doFilter(request, response);
>
>
> My question is:
>
> If the chain is placed inside an else, which would not run if the condition
> is true, does that violate the Filter in any way? In other words, if one
> does not call chain.doFilter within a doFilter method, should one expect
> something bad?
>
> What I'm really saying without saying it is, whether I call chain.doFilter
> in or out of an "else", on Tomcat I get the sendError status that I expect,
> but not from other containers. I realize that statement is moot on this
> list, but I thought I would share it.
>
> Are there any conditions in which Tomcat will decide what to do on its own,
> related to sendError, when it can't figure it out from code?
>
> Leo
>
>
> Using CATALINA_BASE: "C:\apache-tomcat\apache-tomcat-7.0.62"
> Using CATALINA_HOME: "C:\apache-tomcat\apache-tomcat-7.0.62"
> Using CATALINA_TMPDIR: "C:\apache-tomcat\apache-tomcat-7.0.62\temp"
> Using JRE_HOME:"C:\Program Files (x86)\Java\jdk1.7.0_67"
> Using CLASSPATH:
> "C:\apache-tomcat\apache-tomcat-7.0.62\bin\bootstrap.jar;C:\apache-tomcat\apache-tomcat-7.0.62\bin\tomcat-juli.jar"
> Server version: Apache Tomcat/7.0.62
> Server built: May 7 2015 17:14:55 UTC
> Server number: 7.0.62.0
> OS Name:Windows 7
> OS Version: 6.1
> Architecture: x86
> JVM Version:1.7.0_67-b01
> JVM Vendor: Oracle Corporation
1. A Filter can generate the response by itself. There is no need to
call the chain.
An example in Tomcat:
org.apache.catalina.filters.RemoteAddrFilter
org.apache.catalina.filters.RequestFilter#process(...)
2. There are several types of dispatch defined in Servlet specification.
See e.g. javax.servlet.DispatcherType enumeration.
Usually a Filter is configured to serve 'REQUEST' dispatches. Thus an
'ERROR' dispatch (triggered by sendError()) bypasses the filter.
Read about filters in the Servlet specification.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Filter behaviour
On Fri, Jun 26, 2015 at 1:42 AM, André Warnier wrote: > > I must admit that your question above was a bit difficult to follow, in > terms of if/then/else/unless, particularly late at night. Yes, you are right. Sorry about that. I was trying to walk the line between saying too much and not enough and so it came out all gibberish. > And the last paragraph made me think that perhaps the Tomcat logo might > lead you to personalise things a bit more than is really healthy. > (Or else I want to have a look at that code, because the Tomcat developers > must be even smarter that I thought). > > But if your question in the end boils down to : *must* a filter > necessarily call the next filter/webapp in the chain, then the answer is in > the Servlet Specification. > E.g. Servlet Spec v 3.0 final, Chapt 6 Filtering, Section 6.2 Main > concepts, item 4 : > "The filter *may* invoke the next entity in the filter chain".. > It even adds : "Alternatively, the filter chain can block the request by > not making the call to invoke the next entity, leaving the filter > responsible for filling out the response object." > > (What you need to do then still, is to insure that you do indeed generate > a valid response, whether it's an error or not. That's maybe the point > where different containers may react slightly differently.). > If I use a return statement to break out of a filter, what should happen? Will the next filter run? Shouldn't a return statement in a filter, especially one that comes right after a sendError call, send the error and direct the user to the page configured for such errors? The scenario I'm working on is a web service. The web service has three filters, in order they are: throttle filter, authentication filter, logging filter. If a user is not authenticated, the following code "should" break out of the filter chain and redirect the user to a custom 403. It works nice on Tomcat. HttpServletResponse httpResponse = (HttpServletResponse) response; httpResponse.sendError(HttpServletResponse.HttpServletResponse.SC_FORBIDDEN); return; What I'm seeing on other containers is that I get a NPE where the Service class is trying to do something with the authenticated user, which is null. I realize this is not an "other containers" forum, but I was just curious what the expected behaviour *should* be. Leo
RE: Forcing SSL Renotiation
Hi Steffen
You didn't specify your Tomcat version. In Tomcat 7 or 8 or 9 we use the
following code. Not sure if it will work on 6. For a long time until very
recently we were stuck on 5.5 and the attribute below is not available. So I
had to write a reflection introspection to drill down to the SSLSessionManager
held by the Tomcat objects under the server request.
Keep in mind the client cert implementation on the browsers is not uniform in
behavior (in respect of resetting a session and letting the user chose another
cert on relogin). We support FF, Chrome and IE and by far so far IE has been
the most consistent. Later releases of Chrome cache the smartcard connection
and resubmit the same cert on reconnect and nothing you can do on the server
can change this (as far as I know). The JS-side crypto support (to reset the
state) is poor, FF-specific and unreliable. Firefox has it's own set of issues.
George
[1]
// Invalidate the SSL Session
(org.apache.tomcat.util.net.SSLSessionManager)
Method invalidateSessionMethod = null;
Object mgr =
httpRequest.getAttribute("javax.servlet.request.ssl_session_mgr");
if (mgr != null) {
try {
invalidateSessionMethod =
mgr.getClass().getMethod("invalidateSession");
if (invalidateSessionMethod == null) {
log.error("Failed to reset SSL
session: Method invalidateSessionMethod =
mgr.getClass().getMethod(\"invalidateSession\") failed to return method");
}
invalidateSessionMethod.setAccessible(true);
} catch (Throwable t) {
log.error("Failed to reset SSL session:
" + t.getMessage(), t);
}
// Invalidate the session
try {
invalidateSessionMethod.invoke(mgr);
log.trace("SSL session reset
successfully");
return true;
} catch (Throwable t) {
log.error("Failed to reset SSL session:
invalidateSession() threw exception: " + t.getMessage(), t);
}
-Original Message-
From: Steffen Heil (Mailinglisten) [mailto:li...@steffen-heil.de]
Sent: Friday, June 26, 2015 2:43 AM
To: Tomcat Users List
Subject: Forcing SSL Renotiation
Hi
My tomcat installation offers pages through https only. So when accessing these
pages, an ssl connection is established.
Later on, a user may decide to "log in", hence hitting a page, that requires
client certificates, and the browser pops up a selection dialog for a
certificate.
Once chosen, the server recognized the user by its certificate, and everything
is fine.
So far, so good.
Now I have 2 problems:
1. When clicking "logout" in the application, the server terminates its
internal session for that user, but the ssl connection is not terminated.
That means, as soon as anyone clicks login again, the old certificate is reused.
So the user cannot login using another certificate.
2. The second problem with that is, that if the certificate was on a smartcard
and that card was removed, that cannot be detected.
Is there any way to tell tomcat to tell the browser to drop the tls session
state and "restart"?
Regards,
Steffen
Forcing SSL Renotiation
Hi My tomcat installation offers pages through https only. So when accessing these pages, an ssl connection is established. Later on, a user may decide to "log in", hence hitting a page, that requires client certificates, and the browser pops up a selection dialog for a certificate. Once chosen, the server recognized the user by its certificate, and everything is fine. So far, so good. Now I have 2 problems: 1. When clicking "logout" in the application, the server terminates its internal session for that user, but the ssl connection is not terminated. That means, as soon as anyone clicks login again, the old certificate is reused. So the user cannot login using another certificate. 2. The second problem with that is, that if the certificate was on a smartcard and that card was removed, that cannot be detected. Is there any way to tell tomcat to tell the browser to drop the tls session state and "restart"? Regards, Steffen smime.p7s Description: S/MIME cryptographic signature
