Re: Form based auth does not provide the option to show error reason in the error page
Werner, On 10/15/21 09:10, Werner Dähn wrote: Thanks Mark. Why do you believe the refactoring is difficult? All we actually need is access to the response object. ... which requires a lot of refactoring. Have a look at all the code that handles authentication in Tomcat. This would allow to add session data, URL parameters, whatever. And this response object is available everywhere except in the actual RealmBase. By my analysis the change would be rather simple and provide a feedback channel. If that feedback channel is used and for what, is a separate discussion and decided by the real implementer. What you really want is the request object, not the response. You can't set attributes on the response, but the request has that, plus it has all kinds of other juicy information such as the user's IP address (to be used for per-user IP-based access-checks), secondary authentication information in the form of (previously-set) request attributes and/or request parameters. I'm 100% in favor of adding the request to the whole authentication ecosystem. Correct me if I'm wrong, markt, but I think the whole idea of JASPIC was to allow essentially arbitrary, pluggable front-ends *and* back-ends into the authentication system. If that's the case, I'd love to know how to take a vanilla FORM username+password configuration using FormAuthenticator + DataSourceRealm and make it work using whatever JASPIC magic needs to be configured just to do the same work. Presumably, it's not terribly difficult from there to introduce things like "also pass the request" through all that from front-end to back-end. https://bz.apache.org/bugzilla/show_bug.cgi?id=65635 -chris On Fri, Oct 15, 2021 at 2:01 PM Mark Thomas wrote: On 15/10/2021 07:05, Werner Dähn wrote: So why has this not been done? What am I missing? Accepted security good practice is not to provide any information to a user as to the reason for a failed authentication. The idea is that it could help an attacker by, for example, letting them know they have a valid user name but an invalid password. I'm not entirely convinced by the arguments used to support the above position. They generally seem to be based on the assumption that a brute force attack is possible. I'd argue that any system susceptible to a brute force attack has problems irrespective of whether it provides feedback on authentication failures. I do think there is an argument to be made that trading reduced usability (no feedback on authentication failures) for allegedly better security (brute force attacks are harder) is not a sensible trade-off. That said, I appear to be in the minority. Again. Does an enhancement request exist?? No. I do think there is an argument for providing information on the reason for the authentication failure via a mechanism that allows system administrators to decide if they want to pass it on to the users or not. Something like a request attribute that could be included in a custom error page for example. However, the current Tomcat code for authentication is structured in such a way that exposing the reason for an authentication failure would require a reasonable amount of refactoring. I don't think an enhancement request along these lines will be rejected, but neither do I think it will be implemented quickly. I'd expect a fair amount of discussion about how to refactor the Realm interface to expose this information. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form based auth does not provide the option to show error reason in the error page
Thanks Mark. Why do you believe the refactoring is difficult? All we actually need is access to the response object. This would allow to add session data, URL parameters, whatever. And this response object is available everywhere except in the actual RealmBase. By my analysis the change would be rather simple and provide a feedback channel. If that feedback channel is used and for what, is a separate discussion and decided by the real implementer. Thanks for your warnings regarding "this might be a security concern" - it allowed me to word the enhancement request accordingly. https://bz.apache.org/bugzilla/show_bug.cgi?id=65635 On Fri, Oct 15, 2021 at 2:01 PM Mark Thomas wrote: > On 15/10/2021 07:05, Werner Dähn wrote: > > > > > So why has this not been done? What am I missing? > > Accepted security good practice is not to provide any information to a > user as to the reason for a failed authentication. The idea is that it > could help an attacker by, for example, letting them know they have a > valid user name but an invalid password. > > I'm not entirely convinced by the arguments used to support the above > position. They generally seem to be based on the assumption that a brute > force attack is possible. I'd argue that any system susceptible to a > brute force attack has problems irrespective of whether it provides > feedback on authentication failures. > > I do think there is an argument to be made that trading reduced > usability (no feedback on authentication failures) for allegedly better > security (brute force attacks are harder) is not a sensible trade-off. > That said, I appear to be in the minority. Again. > > > Does an enhancement request exist?? > > No. > > I do think there is an argument for providing information on the reason > for the authentication failure via a mechanism that allows system > administrators to decide if they want to pass it on to the users or not. > Something like a request attribute that could be included in a custom > error page for example. > > However, the current Tomcat code for authentication is structured in > such a way that exposing the reason for an authentication failure would > require a reasonable amount of refactoring. I don't think an enhancement > request along these lines will be rejected, but neither do I think it > will be implemented quickly. I'd expect a fair amount of discussion > about how to refactor the Realm interface to expose this information. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Form based auth does not provide the option to show error reason in the error page
On 15/10/2021 07:05, Werner Dähn wrote: So why has this not been done? What am I missing? Accepted security good practice is not to provide any information to a user as to the reason for a failed authentication. The idea is that it could help an attacker by, for example, letting them know they have a valid user name but an invalid password. I'm not entirely convinced by the arguments used to support the above position. They generally seem to be based on the assumption that a brute force attack is possible. I'd argue that any system susceptible to a brute force attack has problems irrespective of whether it provides feedback on authentication failures. I do think there is an argument to be made that trading reduced usability (no feedback on authentication failures) for allegedly better security (brute force attacks are harder) is not a sensible trade-off. That said, I appear to be in the minority. Again. Does an enhancement request exist?? No. I do think there is an argument for providing information on the reason for the authentication failure via a mechanism that allows system administrators to decide if they want to pass it on to the users or not. Something like a request attribute that could be included in a custom error page for example. However, the current Tomcat code for authentication is structured in such a way that exposing the reason for an authentication failure would require a reasonable amount of refactoring. I don't think an enhancement request along these lines will be rejected, but neither do I think it will be implemented quickly. I'd expect a fair amount of discussion about how to refactor the Realm interface to expose this information. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Form based auth does not provide the option to show error reason in the error page
I know it has been asked dozens of times but the response is always "Cannot be done in a standard way". But why can't we change Tomcat to provide further details to the error page of why the login failed? I would have thought tomcat can support that easily without any backward compatibility issue: Everywhere the authenticate method is called, e.g. FormAuthenticator.doAuthenticate() catch throwables and add the exception details as parameter, as session variable, as ... to the redirect call, such that the error page has a place to read the actual issue. There are tons of reasons a login might fail and without providing the user with the reason he has no option to fix the problem. Only option is to call up the web server admin to scan the webserver logs. Examples: * password wrong * cannot connect to the user database due to network or database not up * login is fine but password expired, must be changed * connection to the user database is fine but SQL statement failed for whatever reason So why has this not been done? What am I missing? Does an enhancement request exist?? Thanks in advance
Re: Custom error page
On 24/09/2021 11:56, Jan Pernica wrote: Hi how can I easly create error page for the whole server? Curretly if I add to conf/web.xml 500 /error/error.html 404 /error/error.html And put into webapps/ROOT/error/error.html page it works only for ROOT context. Other contexts shows empty page. I have to propagate error page into all contexts. How to do it in one step? http://tomcat.apache.org/tomcat-10.0-doc/config/valve.html#Error_Report_Valve/Attributes Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Custom error page
Hi how can I easly create error page for the whole server? Curretly if I add to conf/web.xml 500 /error/error.html 404 /error/error.html And put into webapps/ROOT/error/error.html page it works only for ROOT context. Other contexts shows empty page. I have to propagate error page into all contexts. How to do it in one step? Thnx Jan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
答复: [Tomcat] Error page not work for 400 error.
Thanks Mark,
1. The web.xml is defind in the {$TOMCAT_HOME} /conf ， not in application.
2. I add some walk around code in the ErrorPageSupport.java
3. public ErrorPage find(int statusCode) {
4. log.info("before find, the length of statusPages
is:"+statusPages.size());
5.
6. log.info("in addErrorPage find by status Code code
is:"+statusCode );
7. log.info(Integer.valueOf(statusCode));
8. if ( statusPages.get(Integer.valueOf(statusCode)) == null )
9. log.info("cannot find for "+statusCode);
10. else
11.
log.info("find:"+statusPages.get(Integer.valueOf(statusCode)).getLocation() );
12.
13. if ( statusCode == 400 ) {
14. log.info("%% use custom errorpage");
15. ErrorPage ep =new ErrorPage();
16. ep.setErrorCode(400);
17. ep.setLocation("\400.html");
18. return ep;
19. }else
20. return statusPages.get(Integer.valueOf(statusCode));
21. }
This code was reached but the return was not worked.
发送自 Windows 10 版邮件应用
发件人: Mark Thomas
发送时间: 2018年8月6日 3:32
收件人: users@tomcat.apache.org
主题: Re: [Tomcat] Error page not work for 400 error.
On 05/08/2018 04:13, Leonard Afeng wrote:
> Dear all,
>
> I custom the error page in web.xml as below:
> And I added some log action in org.apache.catalina.util.ErrorPageSupport
> and found out that in some case the 400 error page not working but the
> default error page.
> 20:02:59.674 INFO [http-nio-8080-exec-1]
> org.apache.coyote.http11.Http11Processor.service
> Error parsing HTTP request header
> Is it a known bug
No.
> or I can get some patch for it ?
No.
What you are asking for is logically impossible.
The request parsing has failed. Therefore Tomcat can't (reliably)
identify the web application the request should be routed to. Therefore
you can't have an application error page generate a response.
If you are using 9.0.6 onwards, the ErrorReportValve can be configured
to return a custom *static* page for any specific error code and/or
Exception.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [Tomcat] Error page not work for 400 error.
On 05/08/2018 04:13, Leonard Afeng wrote: Dear all, I custom the error page in web.xml as below: And I added some log action in org.apache.catalina.util.ErrorPageSupport and found out that in some case the 400 error page not working but the default error page. 20:02:59.674 INFO [http-nio-8080-exec-1] org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request header Is it a known bug No. or I can get some patch for it ? No. What you are asking for is logically impossible. The request parsing has failed. Therefore Tomcat can't (reliably) identify the web application the request should be routed to. Therefore you can't have an application error page generate a response. If you are using 9.0.6 onwards, the ErrorReportValve can be configured to return a custom *static* page for any specific error code and/or Exception. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[Tomcat] Error page not work for 400 error.
Dear all,
I custom the error page in web.xml as below:
400
/error400.html
404
/error404.html
java.lang.IllegalArgumentException
/error404.html
And I added some log action in org.apache.catalina.util.ErrorPageSupport
and found out that in some case the 400 error page not working but the
default error page.
the log action is:
public ErrorPage find(int statusCode) {
log.info("before find, the length of statusPages
is:"+statusPages.size());
log.info("in addErrorPage find by status Code code
is:"+statusCode );
log.info(Integer.valueOf(statusCode));
if ( statusPages.get(Integer.valueOf(statusCode)) == null )
log.info("cannot find for "+statusCode);
else
log.info("find:"+statusPages.get(Integer.valueOf(statusCode)).getLocation()
);
return statusPages.get(Integer.valueOf(statusCode));
}
the log print out is:
20:02:59.674 INFO [http-nio-8080-exec-1]
org.apache.coyote.http11.Http11Processor.service
Error parsing HTTP request header
Note: further occurrences of HTTP request parsing errors will be logged at
DEBUG level.
java.lang.IllegalArgumentException: Invalid character found in the request
target. The valid characters are defined in RFC 7230 and RFC 3986
at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(
Http11InputBuffer.java:463)
at org.apache.coyote.http11.Http11Processor.service(
Http11Processor.java:298)
at org.apache.coyote.AbstractProcessorLight.process(
AbstractProcessorLight.java:66)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(
AbstractProtocol.java:754)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.
doRun(NioEndpoint.java:1385)
at org.apache.tomcat.util.net.SocketProcessorBase.run(
SocketProcessorBase.java:49)
at java.util.concurrent.ThreadPoolExecutor.runWorker(
ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(
ThreadPoolExecutor.java:624)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(
TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)
20:02:59.690 INFO [http-nio-8080-exec-1]
org.apache.catalina.util.ErrorPageSupport.find
before find, the length of statusPages is:0
20:02:59.690 INFO [http-nio-8080-exec-1]
org.apache.catalina.util.ErrorPageSupport.find
in addErrorPage find by status Code code is:400
20:02:59.690 INFO [http-nio-8080-exec-1]
org.apache.catalina.util.ErrorPageSupport.find
400
20:02:59.690 INFO [http-nio-8080-exec-1]
org.apache.catalina.util.ErrorPageSupport.find
cannot find for 400
20:02:59.690 INFO [http-nio-8080-exec-1]
org.apache.catalina.util.ErrorPageSupport.find
before find, the length of statusPages is:0
20:02:59.691 INFO [http-nio-8080-exec-1]
org.apache.catalina.util.ErrorPageSupport.find
in addErrorPage find by status Code code is:0
20:02:59.691 INFO [http-nio-8080-exec-1]
org.apache.catalina.util.ErrorPageSupport.find
0
20:02:59.691 INFO [http-nio-8080-exec-1]
org.apache.catalina.util.ErrorPageSupport.find
cannot find for 0
20:02:59.999 INFO [http-nio-8080-exec-2]
org.apache.catalina.util.ErrorPageSupport.find
before find, the length of statusPages is:2
20:03:00.000 INFO [http-nio-8080-exec-2]
org.apache.catalina.util.ErrorPageSupport.find
in addErrorPage find by status Code code is:404
20:03:00.000 INFO [http-nio-8080-exec-2]
org.apache.catalina.util.ErrorPageSupport.find
404
20:03:00.000 INFO [http-nio-8080-exec-2]
org.apache.catalina.util.ErrorPageSupport.find
find:/error404.html
Is it a known bug or I can get some patch for it ? Thanks advanced.
Sincerely
Leo
Re: Re: FW: HttpServletResponse.sendError - missing message in error page
> [...]
> > “It is implied but it could be clearer.”
>
> [...]
>
> I agree that default ErrorReportValve is not something that has to be
> backward compatible as the apps should have provided their own. Yet,
> we were using the default as it was working very well and was covering
> our needs.
>
> Honestly I don’t see the purpose of this change. Here is the changed code:
>
> 7.0.88 > sb.append(smClient.getString("errorReportValve.statusHeader",
> String.valueOf(statusCode), message)).append("");
>
> 7.0.90 > sb.append(smClient.getString("errorReportValve.statusHeader",
> String.valueOf(statusCode), reason)).append("");
>
> What is the reason to show ‘reason’ which is technical (like Internal
> Server Error), instead of ‘message’ which is end-user text?
The reasoning behind this is that message was duplicated and users shall
know that status code XXX means. Most people don't know.
> Can you rethink this change and if possible bring the old behavior?
If you are really about proper messages, you should employ a custom
error message change in the look and feel of your application.
The current valve shows you consicely status -- reason phrease, message,
status description and the stacktrace if given.
Michael
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: FW: HttpServletResponse.sendError - missing message in error page
>
> -Original Message-
> From: Mark Thomas
> Sent: 26 юли 2018 г. 19:04
> To: Tomcat Users List
> Subject: Re: HttpServletResponse.sendError - missing message in error page
>
> On 26/07/2018 13:46, Assia Djambazova wrote:
> > Hello,
> >
> > I noticed that when using HttpServletResponse.sendError in Tomcat 7.0.90
> > with string message the message is no longer shown as the response is
> > displayed.
> >
> > I reproduce this with request to simple servlet:
> >
> >
> >
> > *public void doGet(HttpServletRequest request, HttpServletResponse
> > response) throws ServletException, IOException {
> > response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR, "TEST
> > ERROR MESSAGE");}*
> >
> > The result in the browser is different:
> >
> > In Tomcat 7.0.90 HTTP Status 500 ? Internal Server Error
>
> That question mark doesn't look right. I don't see it when I test this
> locally.
>
> > In Tomcat 7.0.88 HTTP Status 500 - TEST ERROR MESSAGE
> >
> > I think that this change is the cause [1]
>
> Correct.
>
> > However, this change looks incompatible with servlet spec and breaks our
> > integration tests. It seems to me from the spec [2] that the message should
> > be displayed: *The server defaults to creating the response to look like an
> > HTML-formatted server error page containing the specified message, setting
> > the content type to "text/html"*
>
> This is not a spec compliance issue. The ErrorReportValve is an optional
> component that is not enabled by default.
>
> (And the default settings of the ErrorReportValve) are spec compliant.)
>
> > I use the ErrorReportValve and showReport is set to false.
>
> Set showReport to true.
>
> > Reading [3]
> > doesn't clarify if error message is part of the error report or not and if
> > it should be displayed.
>
> It is implied but it could be clearer.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
Hi Mark,
> “It is implied but it could be clearer.”
Actually at least my logic leans to the other direction. The error
message is something that is provided to the end-users. It is meant to
be internationalized and be user-friendly. And you pass it via
sendError. However, error stack trace shouldn’t be visible and the
logic to hide it with showReport=false is good one. From one hand you
hide unnecessary and confusing info for end-users, plus you lower
security attacking vector to your app. And I can add that till version
7.0.88 it was working like that.
I agree that default ErrorReportValve is not something that has to be
backward compatible as the apps should have provided their own. Yet,
we were using the default as it was working very well and was covering
our needs.
Honestly I don’t see the purpose of this change. Here is the changed code:
7.0.88 > sb.append(smClient.getString("errorReportValve.statusHeader",
String.valueOf(statusCode), message)).append("");
7.0.90 > sb.append(smClient.getString("errorReportValve.statusHeader",
String.valueOf(statusCode), reason)).append("");
What is the reason to show ‘reason’ which is technical (like Internal
Server Error), instead of ‘message’ which is end-user text?
Can you rethink this change and if possible bring the old behavior?
Kind Regards,
Emil
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HttpServletResponse.sendError - missing message in error page
On 26/07/2018 13:46, Assia Djambazova wrote:
Hello,
I noticed that when using HttpServletResponse.sendError in Tomcat 7.0.90
with string message the message is no longer shown as the response is
displayed.
I reproduce this with request to simple servlet:
*public void doGet(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR, "TEST
ERROR MESSAGE");}*
The result in the browser is different:
In Tomcat 7.0.90 HTTP Status 500 ? Internal Server Error
That question mark doesn't look right. I don't see it when I test this
locally.
In Tomcat 7.0.88 HTTP Status 500 - TEST ERROR MESSAGE
I think that this change is the cause [1]
Correct.
However, this change looks incompatible with servlet spec and breaks our
integration tests. It seems to me from the spec [2] that the message should
be displayed: *The server defaults to creating the response to look like an
HTML-formatted server error page containing the specified message, setting
the content type to "text/html"*
This is not a spec compliance issue. The ErrorReportValve is an optional
component that is not enabled by default.
(And the default settings of the ErrorReportValve) are spec compliant.)
I use the ErrorReportValve and showReport is set to false.
Set showReport to true.
Reading [3]
doesn't clarify if error message is part of the error report or not and if
it should be displayed.
It is implied but it could be clearer.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HttpServletResponse.sendError - missing message in error page
> Hello,
>
> I noticed that when using HttpServletResponse.sendError in Tomcat 7.0.90
> with string message the message is no longer shown as the response is
> displayed.
>
> I reproduce this with request to simple servlet:
>
>
>
> *public void doGet(HttpServletRequest request, HttpServletResponse
> response) throws ServletException, IOException {
> response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR, "TEST
> ERROR MESSAGE");}*
>
> The result in the browser is different:
>
> In Tomcat 7.0.90 HTTP Status 500 ? Internal Server Error
>
> In Tomcat 7.0.88 HTTP Status 500 - TEST ERROR MESSAGE
>
> I think that this change is the cause [1]
>
> However, this change looks incompatible with servlet spec and breaks our
> integration tests. It seems to me from the spec [2] that the message should
> be displayed: *The server defaults to creating the response to look like an
> HTML-formatted server error page containing the specified message, setting
> the content type to "text/html"*
>
> I use the ErrorReportValve and showReport is set to false. Reading [3]
> doesn't clarify if error message is part of the error report or not and if
> it should be displayed.
>
> Thanks,
> Assia
>
>
> [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=60490
> [2]
> https://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletResponse.html#sendError-int-java.lang.String-
> [3]
> https://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Error_Report_Valve
I wrote the new code and I do think that this change just triggered this bug in
Tomcat.
Frankly, I see the same error here in production for quite some time, but wasn't
able to fully isolate the issue to a simple test case. Can you?
What you see is that some Tomcat-internal code resets the response back to
normal
which you see that the en dash is not properly rendered because the character
encoding is dropped.
The Servlet Spec does not specify how the report shall look like, it is at the
discretion of the container, you should rely on that at all.
Though, I'd be very greatful if you can isolate the case, I'd really want to fix
this.
Michael
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
HttpServletResponse.sendError - missing message in error page
Hello,
I noticed that when using HttpServletResponse.sendError in Tomcat 7.0.90
with string message the message is no longer shown as the response is
displayed.
I reproduce this with request to simple servlet:
*public void doGet(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR, "TEST
ERROR MESSAGE");}*
The result in the browser is different:
In Tomcat 7.0.90 HTTP Status 500 ? Internal Server Error
In Tomcat 7.0.88 HTTP Status 500 - TEST ERROR MESSAGE
I think that this change is the cause [1]
However, this change looks incompatible with servlet spec and breaks our
integration tests. It seems to me from the spec [2] that the message should
be displayed: *The server defaults to creating the response to look like an
HTML-formatted server error page containing the specified message, setting
the content type to "text/html"*
I use the ErrorReportValve and showReport is set to false. Reading [3]
doesn't clarify if error message is part of the error report or not and if
it should be displayed.
Thanks,
Assia
[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=60490
[2]
https://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletResponse.html#sendError-int-java.lang.String-
[3]
https://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Error_Report_Valve
RE: tomcat 6 vulnerability scan default error page help
Mark Thanks for taking the time to help. Again, I appreciate it. cjb> We are getting dinged by a vulnerability scan for the default cjb> not-found error page being returned by Tomcat for a Status 404. cjb> [...] cjb> And we're using Tomcat 6.0.37 (ahem). MT> And you are worried about returning the version number? Have you MT> seen how many real security issues (as opposed to this version MT> number non-issue) there are in 6.0.37? I can't help but think MT> your priorities are all wrong. While I agree that we need to upgrade Tomcat, and it is long overdue, I disagree that my priorities are *all* wrong. (tongue-in-cheek) The compliance deadline looms a bit close to allow time for staging and regression testing. (panicked) Ironically, the scan said nothing about the Tomcat version itself: "The remote web server contains default files. The default error page, default index page, example JSPs, and/or example servlets are installed on the remote Apache Tomcat server. These files should be removed as they may help an attacker uncover information about the remote Tomcat install or host itself. Delete the default index page and remove the example JSP and servlets. Follow the Tomcat or OWASP instructions to replace or modify the default error page." -- Cris Berneburg CACI Lead Software Engineer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: tomcat 6 vulnerability scan default error page help
Leon, Mark, and Alejandro Thanks for your time and suggestions. I appreciate it. cjb> We are getting dinged by a vulnerability scan for the default cjb> not-found error page being returned by Tomcat for a Status 404. cjb> [...] cjb> However, I can't find where the error-page for 404 is defined. cjb> [...] How do I get rid of or override the default error cjb> / 404 / not-found page LR> try to add following to your web.xml MT> $CATALINA_HOME/lib/org/apache/catalina/util MT> Download this file: [...] ServerInfo.properties MT> [...] modify the three properties to whatever value you like AV> unpack catalina.jar in tomcat lib directory, AV> then go to org\apache\catalina\util\, AV> open ServerInfo.properties and edit it I'm thinking of opting for the simplest and quickest possible solution, which is to add an section to the main Tomcat conf/web.xml file but *not* supply the static page specified in the . Experimenting with that arrangement returns a 404 but no page contents, which conforms to the security finding of not returning the default 404 error page. The least complex solution is most likely to succeed because it has the greatest chance of being deployed correctly within our tight deadline. -- Cris Berneburg CACI Lead Software Engineer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: tomcat 6 vulnerability scan default error page help
-Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, May 2, 2018 4:01 PM To: users@tomcat.apache.org Subject: Re: tomcat 6 vulnerability scan default error page help > On 02/05/18 20:51, Leon Rosenberg wrote: > > Hi Mark, > > > > I agree with you that the complaint about version number is rather a > > minor one, however, I've had the same situation as one of our projects > > had to pass through a PCI Compliance test, and this is what they really > > test for. > > Don't get me started on PCI compliance... > > Oh, and Cris - take a look at the ErrorReportValve. > That is where the default error page is coming from. > > Mark Thanks Mark, will do - once all this compliance stuff dies down. -- Cris Berneburg CACI Lead Software Engineer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 6 vulnerability scan default error page help
You need to unpack catalina.jar in tomcat lib directory, then go to org\apache\catalina\util\, open ServerInfo.properties and edit it server.info=Apache Tomcat server.number= server.built= You need to set to empty these variables, as shown above. Save the file. Pack as jar again Put in the tomcat\lib directory again. Hope this could help you, I'm using Tomcat 8.0.27 "Berneburg, Cris J. - US" <cberneb...@caci.com> escribió: We are getting dinged by a vulnerability scan for the default not-found error page being returned by Tomcat for a Status 404. On my dev server when requesting an invalid URL, Tomcat returns a Status 404 page that displays the Tomcat version. Right, I need to do something about that. However, I can't find where the error-page for 404 is defined. It's not defined in: - webapps/ROOT/WEB-INF/web.xml - conf/web.xml - conf/server.xml - conf/context.xml Also, I can't find a notFound or error page either. How do I get rid of or override the default error / 404 / not-found page if I can't find it or where it is currently defined? Also, how is Tomcat returning the default 404 error page if it does not exist? I hope it's not hardcoded in a servlet response. FYI, we're going to remove the ROOT, docs, and examples folders to mitigate other scan findings. And we're using Tomcat 6.0.37 (ahem). -- Cris Berneburg CACI Lead Software Engineer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 6 vulnerability scan default error page help
On 02/05/18 20:51, Leon Rosenberg wrote: > Hi Mark, > > I agree with you that the complaint about version number is rather a minor > one, however, I've had the same situation as one of our projects had to > pass through a PCI Compliance test, and this is what they really test for. Don't get me started on PCI compliance... Oh, and Cris - take a look at the ErrorReportValve. That is where the default error page is coming from. Mark > > regards > Leon > > On Wed, May 2, 2018 at 9:42 PM, Mark Thomas <ma...@apache.org> wrote: > >> On 02/05/18 20:27, Berneburg, Cris J. - US wrote: >>> We are getting dinged by a vulnerability scan for the default not-found >> error page being returned by Tomcat for a Status 404. >>> >>> On my dev server when requesting an invalid URL, Tomcat returns a Status >> 404 page that displays the Tomcat version. Right, I need to do something >> about that. >>> >>> However, I can't find where the error-page for 404 is defined. It's not >> defined in: >>> - webapps/ROOT/WEB-INF/web.xml >>> - conf/web.xml >>> - conf/server.xml >>> - conf/context.xml >>> >>> Also, I can't find a notFound or error page either. >>> >>> How do I get rid of or override the default error / 404 / not-found page >> if I can't find it or where it is currently defined? Also, how is Tomcat >> returning the default 404 error page if it does not exist? I hope it's not >> hardcoded in a servlet response. >>> >>> FYI, we're going to remove the ROOT, docs, and examples folders to >> mitigate other scan findings. >>> >>> And we're using Tomcat 6.0.37 (ahem). >> >> And you are worried about returning the version number? Have you seen >> how many real security issues (as opposed to this version number >> non-issue) there are in 6.0.37? I can't help but think your priorities >> are all wrong. >> >> Hiding the version info is trivial >> Create the following directory structure: >> $CATALINA_HOME/lib/org/apache/catalina/util >> >> Download this file: >> https://svn.apache.org/viewvc/tomcat/archive/tc6.0.x/trunk/ >> java/org/apache/catalina/util/ServerInfo.properties? >> revision=1803960=co >> >> Place it in that directory and modify the three properties to whatever >> value you like. >> >> Restart Tomcat. >> >> Mark >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 6 vulnerability scan default error page help
Hi Mark, I agree with you that the complaint about version number is rather a minor one, however, I've had the same situation as one of our projects had to pass through a PCI Compliance test, and this is what they really test for. regards Leon On Wed, May 2, 2018 at 9:42 PM, Mark Thomas <ma...@apache.org> wrote: > On 02/05/18 20:27, Berneburg, Cris J. - US wrote: > > We are getting dinged by a vulnerability scan for the default not-found > error page being returned by Tomcat for a Status 404. > > > > On my dev server when requesting an invalid URL, Tomcat returns a Status > 404 page that displays the Tomcat version. Right, I need to do something > about that. > > > > However, I can't find where the error-page for 404 is defined. It's not > defined in: > > - webapps/ROOT/WEB-INF/web.xml > > - conf/web.xml > > - conf/server.xml > > - conf/context.xml > > > > Also, I can't find a notFound or error page either. > > > > How do I get rid of or override the default error / 404 / not-found page > if I can't find it or where it is currently defined? Also, how is Tomcat > returning the default 404 error page if it does not exist? I hope it's not > hardcoded in a servlet response. > > > > FYI, we're going to remove the ROOT, docs, and examples folders to > mitigate other scan findings. > > > > And we're using Tomcat 6.0.37 (ahem). > > And you are worried about returning the version number? Have you seen > how many real security issues (as opposed to this version number > non-issue) there are in 6.0.37? I can't help but think your priorities > are all wrong. > > Hiding the version info is trivial > Create the following directory structure: > $CATALINA_HOME/lib/org/apache/catalina/util > > Download this file: > https://svn.apache.org/viewvc/tomcat/archive/tc6.0.x/trunk/ > java/org/apache/catalina/util/ServerInfo.properties? > revision=1803960=co > > Place it in that directory and modify the three properties to whatever > value you like. > > Restart Tomcat. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: tomcat 6 vulnerability scan default error page help
On 02/05/18 20:27, Berneburg, Cris J. - US wrote: > We are getting dinged by a vulnerability scan for the default not-found error > page being returned by Tomcat for a Status 404. > > On my dev server when requesting an invalid URL, Tomcat returns a Status 404 > page that displays the Tomcat version. Right, I need to do something about > that. > > However, I can't find where the error-page for 404 is defined. It's not > defined in: > - webapps/ROOT/WEB-INF/web.xml > - conf/web.xml > - conf/server.xml > - conf/context.xml > > Also, I can't find a notFound or error page either. > > How do I get rid of or override the default error / 404 / not-found page if I > can't find it or where it is currently defined? Also, how is Tomcat > returning the default 404 error page if it does not exist? I hope it's not > hardcoded in a servlet response. > > FYI, we're going to remove the ROOT, docs, and examples folders to mitigate > other scan findings. > > And we're using Tomcat 6.0.37 (ahem). And you are worried about returning the version number? Have you seen how many real security issues (as opposed to this version number non-issue) there are in 6.0.37? I can't help but think your priorities are all wrong. Hiding the version info is trivial Create the following directory structure: $CATALINA_HOME/lib/org/apache/catalina/util Download this file: https://svn.apache.org/viewvc/tomcat/archive/tc6.0.x/trunk/java/org/apache/catalina/util/ServerInfo.properties?revision=1803960=co Place it in that directory and modify the three properties to whatever value you like. Restart Tomcat. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 6 vulnerability scan default error page help
Hi Cris, try to add following to your web.xml 404 /error404.html regards Leon On Wed, May 2, 2018 at 9:27 PM, Berneburg, Cris J. - US <cberneb...@caci.com > wrote: > We are getting dinged by a vulnerability scan for the default not-found > error page being returned by Tomcat for a Status 404. > > On my dev server when requesting an invalid URL, Tomcat returns a Status > 404 page that displays the Tomcat version. Right, I need to do something > about that. > > However, I can't find where the error-page for 404 is defined. It's not > defined in: > - webapps/ROOT/WEB-INF/web.xml > - conf/web.xml > - conf/server.xml > - conf/context.xml > > Also, I can't find a notFound or error page either. > > How do I get rid of or override the default error / 404 / not-found page > if I can't find it or where it is currently defined? Also, how is Tomcat > returning the default 404 error page if it does not exist? I hope it's not > hardcoded in a servlet response. > > FYI, we're going to remove the ROOT, docs, and examples folders to > mitigate other scan findings. > > And we're using Tomcat 6.0.37 (ahem). > > -- > Cris Berneburg > CACI Lead Software Engineer > >
tomcat 6 vulnerability scan default error page help
We are getting dinged by a vulnerability scan for the default not-found error page being returned by Tomcat for a Status 404. On my dev server when requesting an invalid URL, Tomcat returns a Status 404 page that displays the Tomcat version. Right, I need to do something about that. However, I can't find where the error-page for 404 is defined. It's not defined in: - webapps/ROOT/WEB-INF/web.xml - conf/web.xml - conf/server.xml - conf/context.xml Also, I can't find a notFound or error page either. How do I get rid of or override the default error / 404 / not-found page if I can't find it or where it is currently defined? Also, how is Tomcat returning the default 404 error page if it does not exist? I hope it's not hardcoded in a servlet response. FYI, we're going to remove the ROOT, docs, and examples folders to mitigate other scan findings. And we're using Tomcat 6.0.37 (ahem). -- Cris Berneburg CACI Lead Software Engineer
tomcat jaas custom error message in error page
Hi I have a web application deployed on tomcat. I have used custom login module of JAAS for authentication and provided login and error page in web.xml. I want to access message of login exception which I threw in login module into error page - so that custom message can be displayed to user. How to achieve this? Thanks!
Re: RE: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
good question.lol l...@bsoft.com.cn From: Kim Ming Yap Date: 2015-05-19 06:23 To: Tomcat Users List Subject: RE: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve I think Tomcat should provide interfaces for different scenarios .. that's my opinion. So coming back to my web form-based authentication problem, is there a solution to it? I still want to solve my problem Please advice.Thanks. Date: Mon, 18 May 2015 18:01:31 -0400 From: ch...@christopherschultz.net To: users@tomcat.apache.org Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ming Yap, On 5/18/15 4:56 PM, Kim Ming Yap wrote: Now here's comes to crucial point and question when comes to JAAS. I know the benefit of JAAS - a pluggable authentication and authorization module. Why and in JavaEE's name have a JAAS realm (eg in Tomcat) where the loginmodule has no access to those most important objects - sessions, request etc? ... because JAAS does not require you to be running within a web context. You can use JAAS in a think client. Or from a command-line client. Or whatever. In those cases, what would you use for the request or session? I did a bit of research .. hence other web container like JBoss, Oracle WebLogic has to build an extended version of their authentication module to capture those important objects .. I just don't comprehend this.This is mind boggling. Pluggable authentication and authorization is kind of an unattainable goal when you want it to work across any use case. You just happen to be thinking of the web-based authentication use case, here, and it's not matching up with your expectations. What if you wanted to use some information about a TLS certificate for authentication? Does the JAAS module now need to have access to the X.509 certificate as well? What about a Smart Card? Where does that fit into your web-based view of JAAS? It's just more complicated than you think, unfortunately. I have spent almost 4 weeks on trying to solve this basic problem when comes to form based authentication using JAAS. 1. Valid credential - no issue2. Credential disabled due to gt 3 retry - This message propagate to the error page3. Invalid user id - This message propagate to error page4. Invalid password - This message propagate to error page You should do some reading about user-enumeration vulnerabilities and similar things. You probably don't want to give this kind of information to a user. Hint: the user might be an adversary, and any information you give them them is something they can use to gain access to your system. For example: if I enter ob...@whitehouse.gov as my username and you tell me user does not exist, I can keep trying usernames until I get one that does exist. Great, now I know the user exists and I can keep trying passwords until I get in. If you tell me credentials disabled, then I will know when I've tripped some kind of maximum login-attempt trigger that will (likely) disable the user for a while. So, I'll adjust my attack strategy so that I only try each user 3 times because I know that after that, they will be disabled. If you have a hard business requirement to tell the user why they aren't being permitted to login, you might want to go back to whoever wrote those requirements and ask them to review them from a security perspective. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVWmE7AAoJEBzwKT+lPKRYLHsP/0SjF8xJlXoZUPLRZVKAvJ9U Lf4c5eokEFOjQdbMx4e3vLnTfYK2dWnq0d1Te3n+Zk6fWahy4ijiHHZsdvsQxHCt VDFmXZe6FcBu1bFzcU9JNnr2RqRDEBd3St7wWlReB49LpgQaXh3jvKQgPK67ChR9 K0kBAgzV9BRXzKRLjkEHhC+Q3jFgzmd2J3HerDCgKB6jSFw6dn8NdZJqCfAIAG6R xtbYvryRrQEVaMNs0Z0eDRsRy3iTAZAA1FZOUGSxVfAWapcj12RtnbKfB6tX+wc1 ghy6ZZW3efQSirvZ4BbYqsptBYzsA3oU25zbJG5jdz170okYLphx9vbtbP7wFQFJ CPANIDWLj/aTKCch+SCOMLlOXCBAR69HobDG3Tzi0riaeZAxNuBV61SZjIUhA+Bl tVfihOoLxZQcPk7s4VoR4w1SD7nBqMSkzbwTJujbjM7UKi311lRr6LqO6DvYEsg1 eX4qpKELndniJ035wrZXjbGtMS6JWDRjmeIJkVc0+6XsdMJ7c1bzaImfJg9dv6x9 ZlKpiTbW4n5jC6jrvu5elRuAudf0Me467y9JDZq6ujMmcPVr3BcQQKb4cHXnPRzh BpHqXcn19LZGatyx0wpz8nf5ZjHQiyeaWOgSjLyk8yJXXz6EyA4SZ8Ndi8O5Z/tb kgPkqUPohzH02HWcg6E2 =q5gu -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ming Yap, (Please let me know if I'm using your given name properly... you haven't identified yourself in the body of your messages, so I only have your email address for identification purposes. I wouldn't want to be calling you by the wrong name.) On 5/18/15 6:23 PM, Kim Ming Yap wrote: I think Tomcat should provide interfaces for different scenarios .. that's my opinion. Tomcat can't dictate the JAAS interfaces. It can only implement and/or call them. You are right that Tomcat might be able to provide some convenience items for you, but you'd have to be a bit more specific about what you'd like. So coming back to my web form-based authentication problem, is there a solution to it? Mark suggested a custom Authenticator. I'd start by looking at one of the existing authenticators -- depending upon the authenticator you are currently using (likely FormAuthenticator, based upon your initial post). Note that FormAuthenticator.authenticate is probably much more complicated that you imagined. - -chris Date: Mon, 18 May 2015 18:01:31 -0400 From: ch...@christopherschultz.net To: users@tomcat.apache.org Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve Ming Yap, On 5/18/15 4:56 PM, Kim Ming Yap wrote: Now here's comes to crucial point and question when comes to JAAS. I know the benefit of JAAS - a pluggable authentication and authorization module. Why and in JavaEE's name have a JAAS realm (eg in Tomcat) where the loginmodule has no access to those most important objects - sessions, request etc? ... because JAAS does not require you to be running within a web context. You can use JAAS in a think client. Or from a command-line client. Or whatever. In those cases, what would you use for the request or session? I did a bit of research .. hence other web container like JBoss, Oracle WebLogic has to build an extended version of their authentication module to capture those important objects .. I just don't comprehend this.This is mind boggling. Pluggable authentication and authorization is kind of an unattainable goal when you want it to work across any use case. You just happen to be thinking of the web-based authentication use case, here, and it's not matching up with your expectations. What if you wanted to use some information about a TLS certificate for authentication? Does the JAAS module now need to have access to the X.509 certificate as well? What about a Smart Card? Where does that fit into your web-based view of JAAS? It's just more complicated than you think, unfortunately. I have spent almost 4 weeks on trying to solve this basic problem when comes to form based authentication using JAAS. 1. Valid credential - no issue2. Credential disabled due to gt 3 retry - This message propagate to the error page3. Invalid user id - This message propagate to error page4. Invalid password - This message propagate to error page You should do some reading about user-enumeration vulnerabilities and similar things. You probably don't want to give this kind of information to a user. Hint: the user might be an adversary, and any information you give them them is something they can use to gain access to your system. For example: if I enter ob...@whitehouse.gov as my username and you tell me user does not exist, I can keep trying usernames until I get one that does exist. Great, now I know the user exists and I can keep trying passwords until I get in. If you tell me credentials disabled, then I will know when I've tripped some kind of maximum login-attempt trigger that will (likely) disable the user for a while. So, I'll adjust my attack strategy so that I only try each user 3 times because I know that after that, they will be disabled. If you have a hard business requirement to tell the user why they aren't being permitted to login, you might want to go back to whoever wrote those requirements and ask them to review them from a security perspective. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVWzZhAAoJEBzwKT+lPKRYTFMQAIPiKQEbsLInQNq+UI94Odb/ CRuw40xsGuxkoNQHkb/rMCZm2hiQT9KJFb//H2tzLQjHMzjF3CmyWyTtghv+p3LN Flo6x4yb6fCdc220Bh9SrW/kOkimEXjfcpRL0AygEHEOSabkRJBzUvJZwN2dSWhm wyEukEW3fRw6+LMOZiL1jPgaqfuwR8CRRmBBDWHlnN6BuR+0I5m3pEA1oLENHcUn evHbP6YQOwbxoVa7zlTDGEUZLp6a1q518b6HuEZY5iip1M0pqiMgDZReao3xkWCW sLB6DYee3Xz/VE9e6/QX/5RVGmB6TkBulxZiygbuthuZsUEXdUzuf4wNbB2B+uuB q3DPKeGHftqquDbirimrTnfEA/6xfkiz+pMx4Ts/w7ibXMEcDPKSrT945iOuV8/A lJFtHofQicfJhNdxq58W1nRmQPawZh8PQi8MxF/YybMwZ5k3udy7x3mxmub0xGEj KOJ6Ibs7KORwyHKb3t2x6MdkKYGbhfTQFz4NuG4i5nKOZa1vwMbnnHW+yNY16
RE: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
You said .. Actually, the better analogy is that there is an application that can tell you whether or not 1+1=2, and you're asking it to explain why the numbers they entered don't total up to 2 when a user account is disabled after exceeded limits retry .. i couldn't display account disabled but rather email / password invalid (due to the issue below) the right analogy is .. 1 (User) +1 (password) = 10 (10 being the incorrect message being displayed due to lack of the needed feature). Sure .. if if i'm the client .. i will ask 1+1 = 10? That's the issue. Date: Tue, 19 May 2015 10:34:48 -0400 From: dcker...@verizon.net To: users@tomcat.apache.org Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve On 5/19/2015 10:26 AM, Kim Ming Yap wrote: Sorry .. you can call me Kim. Yes. I know Mark suggested a custom authenticator .. but how would it help me? The basic thing which i need is simple. In the login module, i need access to session, request objects .. How can having a custom authenticator help me? What i need is a simple API in the login module to get these objects. Think of it this way. There's a callback for username and password. A simple solution is to have a callback for those session, request objects. Now i know that the standard API security doesn't have this. Maybe Tomcat can provide this API .. a callback to get this object. By the way, you mentioned about it's more complicated than that. Sure. But here's the point. The need here is basic and is the most fundamental thing used in any web application to do authentication and is used by all world wide application to do authentication. But what you're asking it to do goes way beyond authentication. All authentication does is tell you if a user should be allowed to access certain resources. Nothing more. Asking it to tell you why they are not allowed to access it is an additional function that can hurt your security. Sure, issue of security etc. But your are forgoing the fundamental on account of that. Think of it this way. You've build some really good math algorithm to solve some advanced issue while all i need is 1+1 = 2 and that is not achievable. Actually, the better analogy is that there is an application that can tell you whether or not 1+1=2, and you're asking it to explain why the numbers they entered don't total up to 2. I would get the fundamental rights first before moving on to more advanced needs like TLS certificate etc. That's why when i started looking at this issue, well lots of complaints on this. Just google it. Just my thoughts. Date: Tue, 19 May 2015 09:10:57 -0400 From: ch...@christopherschultz.net To: users@tomcat.apache.org Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ming Yap, (Please let me know if I'm using your given name properly... you haven't identified yourself in the body of your messages, so I only have your email address for identification purposes. I wouldn't want to be calling you by the wrong name.) On 5/18/15 6:23 PM, Kim Ming Yap wrote: I think Tomcat should provide interfaces for different scenarios .. that's my opinion. Tomcat can't dictate the JAAS interfaces. It can only implement and/or call them. You are right that Tomcat might be able to provide some convenience items for you, but you'd have to be a bit more specific about what you'd like. So coming back to my web form-based authentication problem, is there a solution to it? Mark suggested a custom Authenticator. I'd start by looking at one of the existing authenticators -- depending upon the authenticator you are currently using (likely FormAuthenticator, based upon your initial post). Note that FormAuthenticator.authenticate is probably much more complicated that you imagined. - -chris Date: Mon, 18 May 2015 18:01:31 -0400 From: ch...@christopherschultz.net To: users@tomcat.apache.org Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve Ming Yap, On 5/18/15 4:56 PM, Kim Ming Yap wrote: Now here's comes to crucial point and question when comes to JAAS. I know the benefit of JAAS - a pluggable authentication and authorization module. Why and in JavaEE's name have a JAAS realm (eg in Tomcat) where the loginmodule has no access to those most important objects - sessions, request etc? ... because JAAS does not require you to be running within a web context. You can use JAAS in a think client. Or from a command-line client. Or whatever. In those cases, what would you use for the request or session? I did a bit of research .. hence other web container like JBoss, Oracle
Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
On 5/19/2015 10:26 AM, Kim Ming Yap wrote: Sorry .. you can call me Kim. Yes. I know Mark suggested a custom authenticator .. but how would it help me? The basic thing which i need is simple. In the login module, i need access to session, request objects .. How can having a custom authenticator help me? What i need is a simple API in the login module to get these objects. Think of it this way. There's a callback for username and password. A simple solution is to have a callback for those session, request objects. Now i know that the standard API security doesn't have this. Maybe Tomcat can provide this API .. a callback to get this object. By the way, you mentioned about it's more complicated than that. Sure. But here's the point. The need here is basic and is the most fundamental thing used in any web application to do authentication and is used by all world wide application to do authentication. But what you're asking it to do goes way beyond authentication. All authentication does is tell you if a user should be allowed to access certain resources. Nothing more. Asking it to tell you why they are not allowed to access it is an additional function that can hurt your security. Sure, issue of security etc. But your are forgoing the fundamental on account of that. Think of it this way. You've build some really good math algorithm to solve some advanced issue while all i need is 1+1 = 2 and that is not achievable. Actually, the better analogy is that there is an application that can tell you whether or not 1+1=2, and you're asking it to explain why the numbers they entered don't total up to 2. I would get the fundamental rights first before moving on to more advanced needs like TLS certificate etc. That's why when i started looking at this issue, well lots of complaints on this. Just google it. Just my thoughts. Date: Tue, 19 May 2015 09:10:57 -0400 From: ch...@christopherschultz.net To: users@tomcat.apache.org Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ming Yap, (Please let me know if I'm using your given name properly... you haven't identified yourself in the body of your messages, so I only have your email address for identification purposes. I wouldn't want to be calling you by the wrong name.) On 5/18/15 6:23 PM, Kim Ming Yap wrote: I think Tomcat should provide interfaces for different scenarios .. that's my opinion. Tomcat can't dictate the JAAS interfaces. It can only implement and/or call them. You are right that Tomcat might be able to provide some convenience items for you, but you'd have to be a bit more specific about what you'd like. So coming back to my web form-based authentication problem, is there a solution to it? Mark suggested a custom Authenticator. I'd start by looking at one of the existing authenticators -- depending upon the authenticator you are currently using (likely FormAuthenticator, based upon your initial post). Note that FormAuthenticator.authenticate is probably much more complicated that you imagined. - -chris Date: Mon, 18 May 2015 18:01:31 -0400 From: ch...@christopherschultz.net To: users@tomcat.apache.org Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve Ming Yap, On 5/18/15 4:56 PM, Kim Ming Yap wrote: Now here's comes to crucial point and question when comes to JAAS. I know the benefit of JAAS - a pluggable authentication and authorization module. Why and in JavaEE's name have a JAAS realm (eg in Tomcat) where the loginmodule has no access to those most important objects - sessions, request etc? ... because JAAS does not require you to be running within a web context. You can use JAAS in a think client. Or from a command-line client. Or whatever. In those cases, what would you use for the request or session? I did a bit of research .. hence other web container like JBoss, Oracle WebLogic has to build an extended version of their authentication module to capture those important objects .. I just don't comprehend this.This is mind boggling. Pluggable authentication and authorization is kind of an unattainable goal when you want it to work across any use case. You just happen to be thinking of the web-based authentication use case, here, and it's not matching up with your expectations. What if you wanted to use some information about a TLS certificate for authentication? Does the JAAS module now need to have access to the X.509 certificate as well? What about a Smart Card? Where does that fit into your web-based view of JAAS? It's just more complicated than you think, unfortunately. I have spent almost 4 weeks on trying to solve this basic problem when comes to form based authentication using JAAS. 1. Valid credential - no issue2. Credential disabled due to gt 3 retry - This message propagate to the error page3. Invalid
Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
On 19/05/2015 15:51, David kerber wrote: On 5/19/2015 10:46 AM, Kim Ming Yap wrote: You said .. Actually, the better analogy is that there is an application that can tell you whether or not 1+1=2, and you're asking it to explain why the numbers they entered don't total up to 2 when a user account is disabled after exceeded limits retry .. i couldn't display account disabled but rather email / password invalid (due to the issue below) the right analogy is .. 1 (User) +1 (password) = 10 (10 being the incorrect message being displayed due to lack of the needed feature). Sure .. if if i'm the client .. i will ask 1+1 = 10? That's the issue. The point we're making is that if a user's authentication is not valid, you should NOT be telling them why, just tell them it's invalid and maybe tell them to contact the administrator. Giving them any more information is just setting yourself up to be a victim of much quicker brute-force attacks, because you're giving them lots of help. +1. And the chances of any such features making it into Tomcat are slim to none. I for one would veto any such proposal (for the exact reasons David outlines above). It is possible that, if the GSoC project to implement JASPIC succeeds (and that isn't looking very likely right now), a side-effect may be that JASPIC makes it easier to implement custom authenticators but even then if you want to go down the route of detailed explanations for authentication failures you will be on your own. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
Sorry .. you can call me Kim. Yes. I know Mark suggested a custom authenticator .. but how would it help me? The basic thing which i need is simple. In the login module, i need access to session, request objects .. How can having a custom authenticator help me? What i need is a simple API in the login module to get these objects. Think of it this way. There's a callback for username and password. A simple solution is to have a callback for those session, request objects. Now i know that the standard API security doesn't have this. Maybe Tomcat can provide this API .. a callback to get this object. By the way, you mentioned about it's more complicated than that. Sure. But here's the point. The need here is basic and is the most fundamental thing used in any web application to do authentication and is used by all world wide application to do authentication. Sure, issue of security etc. But your are forgoing the fundamental on account of that. Think of it this way. You've build some really good math algorithm to solve some advanced issue while all i need is 1+1 = 2 and that is not achievable. I would get the fundamental rights first before moving on to more advanced needs like TLS certificate etc. That's why when i started looking at this issue, well lots of complaints on this. Just google it. Just my thoughts. Date: Tue, 19 May 2015 09:10:57 -0400 From: ch...@christopherschultz.net To: users@tomcat.apache.org Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ming Yap, (Please let me know if I'm using your given name properly... you haven't identified yourself in the body of your messages, so I only have your email address for identification purposes. I wouldn't want to be calling you by the wrong name.) On 5/18/15 6:23 PM, Kim Ming Yap wrote: I think Tomcat should provide interfaces for different scenarios .. that's my opinion. Tomcat can't dictate the JAAS interfaces. It can only implement and/or call them. You are right that Tomcat might be able to provide some convenience items for you, but you'd have to be a bit more specific about what you'd like. So coming back to my web form-based authentication problem, is there a solution to it? Mark suggested a custom Authenticator. I'd start by looking at one of the existing authenticators -- depending upon the authenticator you are currently using (likely FormAuthenticator, based upon your initial post). Note that FormAuthenticator.authenticate is probably much more complicated that you imagined. - -chris Date: Mon, 18 May 2015 18:01:31 -0400 From: ch...@christopherschultz.net To: users@tomcat.apache.org Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve Ming Yap, On 5/18/15 4:56 PM, Kim Ming Yap wrote: Now here's comes to crucial point and question when comes to JAAS. I know the benefit of JAAS - a pluggable authentication and authorization module. Why and in JavaEE's name have a JAAS realm (eg in Tomcat) where the loginmodule has no access to those most important objects - sessions, request etc? ... because JAAS does not require you to be running within a web context. You can use JAAS in a think client. Or from a command-line client. Or whatever. In those cases, what would you use for the request or session? I did a bit of research .. hence other web container like JBoss, Oracle WebLogic has to build an extended version of their authentication module to capture those important objects .. I just don't comprehend this.This is mind boggling. Pluggable authentication and authorization is kind of an unattainable goal when you want it to work across any use case. You just happen to be thinking of the web-based authentication use case, here, and it's not matching up with your expectations. What if you wanted to use some information about a TLS certificate for authentication? Does the JAAS module now need to have access to the X.509 certificate as well? What about a Smart Card? Where does that fit into your web-based view of JAAS? It's just more complicated than you think, unfortunately. I have spent almost 4 weeks on trying to solve this basic problem when comes to form based authentication using JAAS. 1. Valid credential - no issue2. Credential disabled due to gt 3 retry - This message propagate to the error page3. Invalid user id - This message propagate to error page4. Invalid password - This message propagate to error page You should do some reading about user-enumeration vulnerabilities and similar things. You probably don't want to give this kind of information to a user. Hint: the user might be an adversary, and any information you give them them is something they can use to gain access to your
Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
On 5/19/2015 10:46 AM, Kim Ming Yap wrote: You said .. Actually, the better analogy is that there is an application that can tell you whether or not 1+1=2, and you're asking it to explain why the numbers they entered don't total up to 2 when a user account is disabled after exceeded limits retry .. i couldn't display account disabled but rather email / password invalid (due to the issue below) the right analogy is .. 1 (User) +1 (password) = 10 (10 being the incorrect message being displayed due to lack of the needed feature). Sure .. if if i'm the client .. i will ask 1+1 = 10? That's the issue. The point we're making is that if a user's authentication is not valid, you should NOT be telling them why, just tell them it's invalid and maybe tell them to contact the administrator. Giving them any more information is just setting yourself up to be a victim of much quicker brute-force attacks, because you're giving them lots of help. Date: Tue, 19 May 2015 10:34:48 -0400 From: dcker...@verizon.net To: users@tomcat.apache.org Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve On 5/19/2015 10:26 AM, Kim Ming Yap wrote: Sorry .. you can call me Kim. Yes. I know Mark suggested a custom authenticator .. but how would it help me? The basic thing which i need is simple. In the login module, i need access to session, request objects .. How can having a custom authenticator help me? What i need is a simple API in the login module to get these objects. Think of it this way. There's a callback for username and password. A simple solution is to have a callback for those session, request objects. Now i know that the standard API security doesn't have this. Maybe Tomcat can provide this API .. a callback to get this object. By the way, you mentioned about it's more complicated than that. Sure. But here's the point. The need here is basic and is the most fundamental thing used in any web application to do authentication and is used by all world wide application to do authentication. But what you're asking it to do goes way beyond authentication. All authentication does is tell you if a user should be allowed to access certain resources. Nothing more. Asking it to tell you why they are not allowed to access it is an additional function that can hurt your security. Sure, issue of security etc. But your are forgoing the fundamental on account of that. Think of it this way. You've build some really good math algorithm to solve some advanced issue while all i need is 1+1 = 2 and that is not achievable. Actually, the better analogy is that there is an application that can tell you whether or not 1+1=2, and you're asking it to explain why the numbers they entered don't total up to 2. I would get the fundamental rights first before moving on to more advanced needs like TLS certificate etc. That's why when i started looking at this issue, well lots of complaints on this. Just google it. Just my thoughts. Date: Tue, 19 May 2015 09:10:57 -0400 From: ch...@christopherschultz.net To: users@tomcat.apache.org Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ming Yap, (Please let me know if I'm using your given name properly... you haven't identified yourself in the body of your messages, so I only have your email address for identification purposes. I wouldn't want to be calling you by the wrong name.) On 5/18/15 6:23 PM, Kim Ming Yap wrote: I think Tomcat should provide interfaces for different scenarios .. that's my opinion. Tomcat can't dictate the JAAS interfaces. It can only implement and/or call them. You are right that Tomcat might be able to provide some convenience items for you, but you'd have to be a bit more specific about what you'd like. So coming back to my web form-based authentication problem, is there a solution to it? Mark suggested a custom Authenticator. I'd start by looking at one of the existing authenticators -- depending upon the authenticator you are currently using (likely FormAuthenticator, based upon your initial post). Note that FormAuthenticator.authenticate is probably much more complicated that you imagined. - -chris Date: Mon, 18 May 2015 18:01:31 -0400 From: ch...@christopherschultz.net To: users@tomcat.apache.org Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve Ming Yap, On 5/18/15 4:56 PM, Kim Ming Yap wrote: Now here's comes to crucial point and question when comes to JAAS. I know the benefit of JAAS - a pluggable authentication and authorization module. Why and in JavaEE's name have a JAAS realm (eg in Tomcat) where the loginmodule has no access to those most important objects - sessions, request etc? ... because JAAS does not require you to be running within a web context. You can use
RE: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
ok. i see the light .. Thanks a zillion! Date: Tue, 19 May 2015 15:56:47 +0100 From: ma...@apache.org To: users@tomcat.apache.org Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve On 19/05/2015 15:51, David kerber wrote: On 5/19/2015 10:46 AM, Kim Ming Yap wrote: You said .. Actually, the better analogy is that there is an application that can tell you whether or not 1+1=2, and you're asking it to explain why the numbers they entered don't total up to 2 when a user account is disabled after exceeded limits retry .. i couldn't display account disabled but rather email / password invalid (due to the issue below) the right analogy is .. 1 (User) +1 (password) = 10 (10 being the incorrect message being displayed due to lack of the needed feature). Sure .. if if i'm the client .. i will ask 1+1 = 10? That's the issue. The point we're making is that if a user's authentication is not valid, you should NOT be telling them why, just tell them it's invalid and maybe tell them to contact the administrator. Giving them any more information is just setting yourself up to be a victim of much quicker brute-force attacks, because you're giving them lots of help. +1. And the chances of any such features making it into Tomcat are slim to none. I for one would veto any such proposal (for the exact reasons David outlines above). It is possible that, if the GSoC project to implement JASPIC succeeds (and that isn't looking very likely right now), a side-effect may be that JASPIC makes it easier to implement custom authenticators but even then if you want to go down the route of detailed explanations for authentication failures you will be on your own. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
On 18/05/2015 13:31, Kim Ming Yap wrote:
Thanks Mark for your suggestion.
I'm still confused over the last part where you mentioned that 'i am
confusing myself between control and data'.
The response object contains output stream (data) to be displayed. Always the
case.
No.
The response contains a reference to the output stream. The output
stream can be flushed to the client *at any point*. There is no
guarantee that it will contain the [data] to be displayed.
The (incorrect) sequences you list below describe the control flow. The
data flow (when the application reads the request body, when the
application writes the request body and when the request body is written
to the client) is completely separate.
If i enter valid credential .. you'll noticed the flow exactly as indicated
on my email (I've traced is using system.out.println)
request -- valve -- JAAS -- filter -- JSP -- response -- filter --
JAAS -- valve -- browser
Again, no. JAAS does not call the filter. Your valve calls the
Authenticator which calls JAAS and then (via some additional objects)
the Authenticator calls the filter.
Neither the request nor the response are part of the processing chain.
They are objects that are passed up and down the chain.
If invalid credential ..
request -- valve -- JAAS -- response -- valve (break point and stop here)
.. yet JSP error page displayed.
So this is really confusing.
Take a look at the updated diagrams here:
https://bz.apache.org/bugzilla/show_bug.cgi?id=57282
The response always contains data to be displayed on the client browser.
No it does not. See comment above re control flow vs data flow.
How did the JSP error page displayed when on its way back to the client
browser .. i did a break point stop at the valve.
See point above re control flow vs data flow.
Mark
Hm ..
Date: Mon, 18 May 2015 11:14:19 +0100
From: ma...@apache.org
To: users@tomcat.apache.org
Subject: Re: Tomcat valve JAAS : form error page displayed first before
response reaches back to Tomcat valve
On 17/05/2015 23:44, Kim Ming Yap wrote:
Hi,I'm building a website using form based authentication integrating with
JAAS for user based authentication. I don't have issue when a successful
credential is authenticated. Rather I'm having difficulty understanding the
flow of JAAS back to the client should the form based authentication failed.
SOFTWARE:1. Apache Tomee plus 1.7.12. Java 83. Tomcat JAAS Realm
OBJECTIVE:Custom error captured in JAAS login module to propagate to error
page
You are unlikely to get much help from Tomcat with this since
propagating back custom errors is considered poor security practise (an
attacker should not be able to tell why authentication failed).
BASIC UNDERSTANDING:
The Tomcat JAAS layer is not integrated with the web container layer. Hence
the former does not have access to request, session etc.
JAAS is integrated as a Realm - i.e. something that validates
credentials provided by an Authenticator. The Authenticator has full
access to the request and the response. You may want to consider a
custom Authenticator.
SOLUTION:
Using ThreadLocal which capture the custom error message in JAAS layer to
be used when the flow reaches back to the custom valve on the way back to
the browser.
You need to be careful you don't trigger memory leaks when using
ThreadLocals.
PROBELM:Understanding of basic request/response flow involving Tomcat and
JAAS
a. request -- valve -- JAAS -- Filter -- Servlet/JSPb. response --
valve (**) -- JAAS -- Filter -- Servlet/JSP
I suspect that order is wrong.
JAAS is called by the Authenticator (which is a valve). The
Authenticator then calls the Filter (via a few other layers).
You might want to check the ordering of your valve and the Authenticator.
(refer to above clause b)ThreadLocal in the JAAS layer managed to capture
the custom error message and it i managed to print it after the getNext()
method of the custom valve. Thought of adding this custom error as an
attribute in the session object.
However I noticed that the error page is already displayed before i could
add this cusom error (immediately after the getNext method).
The error page will be handled by the webapp or the ErrorReportingValve
- both of whichh may get called before your Valve depending on how the
Valve is configured.
Due to that the ready custom error message cannot be used
SAMPLE CODES:
1. web.xml
login-configauth-methodFORM/auth-method
form-login-config form-login-page/login.jsp/form-login-page
form-error-page/login-redirect-error.jsp?error=true/form-error-page
/form-login-config/login-config
2. Custom valve and defined in META-INF/context.xml
public class SecurityValve extends ValveBase {
public void invoke(Request request, Response response) throws
IOException, ServletException { getNext().invoke(request,
response
RE: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
Thanks Mark for your suggestion.
I'm still confused over the last part where you mentioned that 'i am confusing
myself between control and data'.
The response object contains output stream (data) to be displayed. Always the
case.
If i enter valid credential .. you'll noticed the flow exactly as indicated on
my email (I've traced is using system.out.println)
request -- valve -- JAAS -- filter -- JSP -- response -- filter -- JAAS
-- valve -- browser
If invalid credential ..
request -- valve -- JAAS -- response -- valve (break point and stop here)
.. yet JSP error page displayed.
So this is really confusing.
The response always contains data to be displayed on the client browser.
How did the JSP error page displayed when on its way back to the client browser
.. i did a break point stop at the valve.
Hm ..
Date: Mon, 18 May 2015 11:14:19 +0100
From: ma...@apache.org
To: users@tomcat.apache.org
Subject: Re: Tomcat valve JAAS : form error page displayed first before
response reaches back to Tomcat valve
On 17/05/2015 23:44, Kim Ming Yap wrote:
Hi,I'm building a website using form based authentication integrating with
JAAS for user based authentication. I don't have issue when a successful
credential is authenticated. Rather I'm having difficulty understanding the
flow of JAAS back to the client should the form based authentication failed.
SOFTWARE:1. Apache Tomee plus 1.7.12. Java 83. Tomcat JAAS Realm
OBJECTIVE:Custom error captured in JAAS login module to propagate to error
page
You are unlikely to get much help from Tomcat with this since
propagating back custom errors is considered poor security practise (an
attacker should not be able to tell why authentication failed).
BASIC UNDERSTANDING:
The Tomcat JAAS layer is not integrated with the web container layer. Hence
the former does not have access to request, session etc.
JAAS is integrated as a Realm - i.e. something that validates
credentials provided by an Authenticator. The Authenticator has full
access to the request and the response. You may want to consider a
custom Authenticator.
SOLUTION:
Using ThreadLocal which capture the custom error message in JAAS layer to
be used when the flow reaches back to the custom valve on the way back to
the browser.
You need to be careful you don't trigger memory leaks when using
ThreadLocals.
PROBELM:Understanding of basic request/response flow involving Tomcat and
JAAS
a. request -- valve -- JAAS -- Filter -- Servlet/JSPb. response --
valve (**) -- JAAS -- Filter -- Servlet/JSP
I suspect that order is wrong.
JAAS is called by the Authenticator (which is a valve). The
Authenticator then calls the Filter (via a few other layers).
You might want to check the ordering of your valve and the Authenticator.
(refer to above clause b)ThreadLocal in the JAAS layer managed to capture
the custom error message and it i managed to print it after the getNext()
method of the custom valve. Thought of adding this custom error as an
attribute in the session object.
However I noticed that the error page is already displayed before i could
add this cusom error (immediately after the getNext method).
The error page will be handled by the webapp or the ErrorReportingValve
- both of whichh may get called before your Valve depending on how the
Valve is configured.
Due to that the ready custom error message cannot be used
SAMPLE CODES:
1. web.xml
login-configauth-methodFORM/auth-method
form-login-config form-login-page/login.jsp/form-login-page
form-error-page/login-redirect-error.jsp?error=true/form-error-page
/form-login-config/login-config
2. Custom valve and defined in META-INF/context.xml
public class SecurityValve extends ValveBase {
public void invoke(Request request, Response response) throws
IOException, ServletException { getNext().invoke(request,
response); system.out.println(after getNext()); -- break point
(BP) }
}
1. Did a break point on SecurityValve (indicated at BP) 2. On forms, i
purposely enter wrong credential and submit 3. Break point stops at
BP 4. login-redirect-error.jsp displayed already5. Since it stop at
break point BP in SecurityValve, the response back to client flow has not
reached the browser. Yet the login-redirect-error.jsp is already displayed
QUESTIONS: How can the login-redirect-error.jsp be displayed on the
browser when the response flowing back to client stop at break point BP?
The flow back to the client is not fully done yet.
You are confusing control and data. The data goes back to the client as
soon as the output is flushed (which can happen in the Servlet/JSP).
I would really appreciate any help.Thanks.
Set a break point in a JSP / Servlet and look at the stack trace to see
which Valves the request/response flow
Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
On 18/05/2015 13:57, Kim Ming Yap wrote: Wow .. that really confuses me. I've studied the Java EE component and the basic understanding of flow is as follows (if i do not flush the data) client request -- web container (encapsulate request/response) -- filter (contain request/response object) -- Servlet (JSP) -- filter (request / response object here can be modified here for eventual display on browser) -- client browser On the way back the client browser, if i do a break point just immediately after the dofilter() method and stop there, the JSP page is not displayed. So if i get your right: 1. If the above is done without flushing the data .. then yes. That JSP page is not displayed since i stop at the breakpoint. Correct. The entire response is contained in the output buffer at that point. 2. However if i do a flush before the break point, data will be send to the client eventhough my code stops at the break point? Correct. On the first write to the client, the HTTP Response headers will be written. This is the point at which the response is considered to be committed. The first write may also include some/all of the response body. Flushing can be explicit (the application calls it) or implicit (the container calls flush because - for example - there is no more space in the output buffer). I thought the data flow is part of the control flow .. Gee .. i got this wrong all the while Think i'm seeing the light .. Happy to help. Mark Date: Mon, 18 May 2015 13:43:14 +0100 From: ma...@apache.org To: users@tomcat.apache.org Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve On 18/05/2015 13:31, Kim Ming Yap wrote: Thanks Mark for your suggestion. I'm still confused over the last part where you mentioned that 'i am confusing myself between control and data'. The response object contains output stream (data) to be displayed. Always the case. No. The response contains a reference to the output stream. The output stream can be flushed to the client *at any point*. There is no guarantee that it will contain the [data] to be displayed. The (incorrect) sequences you list below describe the control flow. The data flow (when the application reads the request body, when the application writes the request body and when the request body is written to the client) is completely separate. If i enter valid credential .. you'll noticed the flow exactly as indicated on my email (I've traced is using system.out.println) request -- valve -- JAAS -- filter -- JSP -- response -- filter -- JAAS -- valve -- browser Again, no. JAAS does not call the filter. Your valve calls the Authenticator which calls JAAS and then (via some additional objects) the Authenticator calls the filter. Neither the request nor the response are part of the processing chain. They are objects that are passed up and down the chain. If invalid credential .. request -- valve -- JAAS -- response -- valve (break point and stop here) .. yet JSP error page displayed. So this is really confusing. Take a look at the updated diagrams here: https://bz.apache.org/bugzilla/show_bug.cgi?id=57282 The response always contains data to be displayed on the client browser. No it does not. See comment above re control flow vs data flow. How did the JSP error page displayed when on its way back to the client browser .. i did a break point stop at the valve. See point above re control flow vs data flow. Mark Hm .. Date: Mon, 18 May 2015 11:14:19 +0100 From: ma...@apache.org To: users@tomcat.apache.org Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve On 17/05/2015 23:44, Kim Ming Yap wrote: Hi,I'm building a website using form based authentication integrating with JAAS for user based authentication. I don't have issue when a successful credential is authenticated. Rather I'm having difficulty understanding the flow of JAAS back to the client should the form based authentication failed. SOFTWARE:1. Apache Tomee plus 1.7.12. Java 83. Tomcat JAAS Realm OBJECTIVE:Custom error captured in JAAS login module to propagate to error page You are unlikely to get much help from Tomcat with this since propagating back custom errors is considered poor security practise (an attacker should not be able to tell why authentication failed). BASIC UNDERSTANDING: The Tomcat JAAS layer is not integrated with the web container layer. Hence the former does not have access to request, session etc. JAAS is integrated as a Realm - i.e. something that validates credentials provided by an Authenticator. The Authenticator has full access to the request and the response. You may want to consider a custom Authenticator. SOLUTION: Using ThreadLocal which capture the custom error message in JAAS layer to be used when the flow reaches back
RE: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
Wow .. that really confuses me. I've studied the Java EE component and the basic understanding of flow is as follows (if i do not flush the data) client request -- web container (encapsulate request/response) -- filter (contain request/response object) -- Servlet (JSP) -- filter (request / response object here can be modified here for eventual display on browser) -- client browser On the way back the client browser, if i do a break point just immediately after the dofilter() method and stop there, the JSP page is not displayed. So if i get your right: 1. If the above is done without flushing the data .. then yes. That JSP page is not displayed since i stop at the breakpoint. 2. However if i do a flush before the break point, data will be send to the client eventhough my code stops at the break point? I thought the data flow is part of the control flow .. Gee .. i got this wrong all the while Think i'm seeing the light .. Date: Mon, 18 May 2015 13:43:14 +0100 From: ma...@apache.org To: users@tomcat.apache.org Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve On 18/05/2015 13:31, Kim Ming Yap wrote: Thanks Mark for your suggestion. I'm still confused over the last part where you mentioned that 'i am confusing myself between control and data'. The response object contains output stream (data) to be displayed. Always the case. No. The response contains a reference to the output stream. The output stream can be flushed to the client *at any point*. There is no guarantee that it will contain the [data] to be displayed. The (incorrect) sequences you list below describe the control flow. The data flow (when the application reads the request body, when the application writes the request body and when the request body is written to the client) is completely separate. If i enter valid credential .. you'll noticed the flow exactly as indicated on my email (I've traced is using system.out.println) request -- valve -- JAAS -- filter -- JSP -- response -- filter -- JAAS -- valve -- browser Again, no. JAAS does not call the filter. Your valve calls the Authenticator which calls JAAS and then (via some additional objects) the Authenticator calls the filter. Neither the request nor the response are part of the processing chain. They are objects that are passed up and down the chain. If invalid credential .. request -- valve -- JAAS -- response -- valve (break point and stop here) .. yet JSP error page displayed. So this is really confusing. Take a look at the updated diagrams here: https://bz.apache.org/bugzilla/show_bug.cgi?id=57282 The response always contains data to be displayed on the client browser. No it does not. See comment above re control flow vs data flow. How did the JSP error page displayed when on its way back to the client browser .. i did a break point stop at the valve. See point above re control flow vs data flow. Mark Hm .. Date: Mon, 18 May 2015 11:14:19 +0100 From: ma...@apache.org To: users@tomcat.apache.org Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve On 17/05/2015 23:44, Kim Ming Yap wrote: Hi,I'm building a website using form based authentication integrating with JAAS for user based authentication. I don't have issue when a successful credential is authenticated. Rather I'm having difficulty understanding the flow of JAAS back to the client should the form based authentication failed. SOFTWARE:1. Apache Tomee plus 1.7.12. Java 83. Tomcat JAAS Realm OBJECTIVE:Custom error captured in JAAS login module to propagate to error page You are unlikely to get much help from Tomcat with this since propagating back custom errors is considered poor security practise (an attacker should not be able to tell why authentication failed). BASIC UNDERSTANDING: The Tomcat JAAS layer is not integrated with the web container layer. Hence the former does not have access to request, session etc. JAAS is integrated as a Realm - i.e. something that validates credentials provided by an Authenticator. The Authenticator has full access to the request and the response. You may want to consider a custom Authenticator. SOLUTION: Using ThreadLocal which capture the custom error message in JAAS layer to be used when the flow reaches back to the custom valve on the way back to the browser. You need to be careful you don't trigger memory leaks when using ThreadLocals. PROBELM:Understanding of basic request/response flow involving Tomcat and JAAS a. request -- valve -- JAAS -- Filter -- Servlet/JSPb. response -- valve (**) -- JAAS -- Filter -- Servlet/JSP I suspect that order is wrong. JAAS is called by the Authenticator (which is a valve). The Authenticator then calls
RE: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
You said The error page will be handled by the webapp or the ErrorReportingValve - both of whichh may get called before your Valve depending on how the Valve is configured. How do i ensure that my custom valve is called before the the ErrorReportingValve?Is there some settings i can set? Thanks for your help. From: yapk...@hotmail.com To: users@tomcat.apache.org Subject: RE: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve Date: Mon, 18 May 2015 11:43:02 -0400 so who control the data flow? Does the data flow has stages just like control flow? Or is it just the http web server? As long as there are output stream going out .. the http web server will server those output stream to the client's browser? Basically no control stages when comes to data flow? Date: Mon, 18 May 2015 14:54:24 +0100 From: ma...@apache.org To: users@tomcat.apache.org Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve On 18/05/2015 13:57, Kim Ming Yap wrote: Wow .. that really confuses me. I've studied the Java EE component and the basic understanding of flow is as follows (if i do not flush the data) client request -- web container (encapsulate request/response) -- filter (contain request/response object) -- Servlet (JSP) -- filter (request / response object here can be modified here for eventual display on browser) -- client browser On the way back the client browser, if i do a break point just immediately after the dofilter() method and stop there, the JSP page is not displayed. So if i get your right: 1. If the above is done without flushing the data .. then yes. That JSP page is not displayed since i stop at the breakpoint. Correct. The entire response is contained in the output buffer at that point. 2. However if i do a flush before the break point, data will be send to the client eventhough my code stops at the break point? Correct. On the first write to the client, the HTTP Response headers will be written. This is the point at which the response is considered to be committed. The first write may also include some/all of the response body. Flushing can be explicit (the application calls it) or implicit (the container calls flush because - for example - there is no more space in the output buffer). I thought the data flow is part of the control flow .. Gee .. i got this wrong all the while Think i'm seeing the light .. Happy to help. Mark Date: Mon, 18 May 2015 13:43:14 +0100 From: ma...@apache.org To: users@tomcat.apache.org Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve On 18/05/2015 13:31, Kim Ming Yap wrote: Thanks Mark for your suggestion. I'm still confused over the last part where you mentioned that 'i am confusing myself between control and data'. The response object contains output stream (data) to be displayed. Always the case. No. The response contains a reference to the output stream. The output stream can be flushed to the client *at any point*. There is no guarantee that it will contain the [data] to be displayed. The (incorrect) sequences you list below describe the control flow. The data flow (when the application reads the request body, when the application writes the request body and when the request body is written to the client) is completely separate. If i enter valid credential .. you'll noticed the flow exactly as indicated on my email (I've traced is using system.out.println) request -- valve -- JAAS -- filter -- JSP -- response -- filter -- JAAS -- valve -- browser Again, no. JAAS does not call the filter. Your valve calls the Authenticator which calls JAAS and then (via some additional objects) the Authenticator calls the filter. Neither the request nor the response are part of the processing chain. They are objects that are passed up and down the chain. If invalid credential .. request -- valve -- JAAS -- response -- valve (break point and stop here) .. yet JSP error page displayed. So this is really confusing. Take a look at the updated diagrams here: https://bz.apache.org/bugzilla/show_bug.cgi?id=57282 The response always contains data to be displayed on the client browser. No it does not. See comment above re control flow vs data flow. How did the JSP error page displayed when on its way back to the client browser .. i did a break point stop at the valve. See point above re control flow vs data flow. Mark Hm .. Date: Mon, 18 May 2015 11:14:19 +0100 From: ma...@apache.org To: users@tomcat.apache.org Subject: Re: Tomcat valve JAAS : form error
RE: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
so who control the data flow? Does the data flow has stages just like control flow? Or is it just the http web server? As long as there are output stream going out .. the http web server will server those output stream to the client's browser? Basically no control stages when comes to data flow? Date: Mon, 18 May 2015 14:54:24 +0100 From: ma...@apache.org To: users@tomcat.apache.org Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve On 18/05/2015 13:57, Kim Ming Yap wrote: Wow .. that really confuses me. I've studied the Java EE component and the basic understanding of flow is as follows (if i do not flush the data) client request -- web container (encapsulate request/response) -- filter (contain request/response object) -- Servlet (JSP) -- filter (request / response object here can be modified here for eventual display on browser) -- client browser On the way back the client browser, if i do a break point just immediately after the dofilter() method and stop there, the JSP page is not displayed. So if i get your right: 1. If the above is done without flushing the data .. then yes. That JSP page is not displayed since i stop at the breakpoint. Correct. The entire response is contained in the output buffer at that point. 2. However if i do a flush before the break point, data will be send to the client eventhough my code stops at the break point? Correct. On the first write to the client, the HTTP Response headers will be written. This is the point at which the response is considered to be committed. The first write may also include some/all of the response body. Flushing can be explicit (the application calls it) or implicit (the container calls flush because - for example - there is no more space in the output buffer). I thought the data flow is part of the control flow .. Gee .. i got this wrong all the while Think i'm seeing the light .. Happy to help. Mark Date: Mon, 18 May 2015 13:43:14 +0100 From: ma...@apache.org To: users@tomcat.apache.org Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve On 18/05/2015 13:31, Kim Ming Yap wrote: Thanks Mark for your suggestion. I'm still confused over the last part where you mentioned that 'i am confusing myself between control and data'. The response object contains output stream (data) to be displayed. Always the case. No. The response contains a reference to the output stream. The output stream can be flushed to the client *at any point*. There is no guarantee that it will contain the [data] to be displayed. The (incorrect) sequences you list below describe the control flow. The data flow (when the application reads the request body, when the application writes the request body and when the request body is written to the client) is completely separate. If i enter valid credential .. you'll noticed the flow exactly as indicated on my email (I've traced is using system.out.println) request -- valve -- JAAS -- filter -- JSP -- response -- filter -- JAAS -- valve -- browser Again, no. JAAS does not call the filter. Your valve calls the Authenticator which calls JAAS and then (via some additional objects) the Authenticator calls the filter. Neither the request nor the response are part of the processing chain. They are objects that are passed up and down the chain. If invalid credential .. request -- valve -- JAAS -- response -- valve (break point and stop here) .. yet JSP error page displayed. So this is really confusing. Take a look at the updated diagrams here: https://bz.apache.org/bugzilla/show_bug.cgi?id=57282 The response always contains data to be displayed on the client browser. No it does not. See comment above re control flow vs data flow. How did the JSP error page displayed when on its way back to the client browser .. i did a break point stop at the valve. See point above re control flow vs data flow. Mark Hm .. Date: Mon, 18 May 2015 11:14:19 +0100 From: ma...@apache.org To: users@tomcat.apache.org Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve On 17/05/2015 23:44, Kim Ming Yap wrote: Hi,I'm building a website using form based authentication integrating with JAAS for user based authentication. I don't have issue when a successful credential is authenticated. Rather I'm having difficulty understanding the flow of JAAS back to the client should the form based authentication failed. SOFTWARE:1. Apache Tomee plus 1.7.12. Java 83. Tomcat JAAS Realm OBJECTIVE:Custom error captured in JAAS login module to propagate to error page You are unlikely to get much help from Tomcat with this since propagating
Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ming Yap, On 5/18/15 11:43 AM, Kim Ming Yap wrote: so who control the data flow? The data is really just a data stream. Anyone dumping data into that stream controls the flow. Any component with access to the OutputStream to the client can inject something into it. The method call flow doesn't place any restrictions on what each component is allowed to put into that OutputStream. Does the data flow has stages just like control flow? It's the Wild West: any component can do anything it wants. Or is it just the http web server? As long as there are output stream going out .. the http web server will server those output stream to the client's browser? Exactly. Basically no control stages when comes to data flow? Correct. There are basically two stages: 1. Before the response has been committed 2. After the response has been committed The committment of the response occurs when either of the following things happen: a. The response buffer fills up (container flushes buffer) b. A component explicitly flushes the response buffer Before the response has been committed, you can add/modify/remove response headers, change the response status code (e.g. 200 OK), request the creation of an HttpSession, and a few other things. After the response has been committed, you can do none of those things: only sending bytes to the response stream will work after that. But again, the only things that triggers the commit of the response if the response buffer filling up (or an explicit flush() call). Any component can cause that event to occur, and no other components are notified that it's about to happen. You can check to see if the response has been committed, but you can't do anything effective to stop it. - -chris Date: Mon, 18 May 2015 14:54:24 +0100 From: ma...@apache.org To: users@tomcat.apache.org Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve On 18/05/2015 13:57, Kim Ming Yap wrote: Wow .. that really confuses me. I've studied the Java EE component and the basic understanding of flow is as follows (if i do not flush the data) client request -- web container (encapsulate request/response) -- filter (contain request/response object) -- Servlet (JSP) -- filter (request / response object here can be modified here for eventual display on browser) -- client browser On the way back the client browser, if i do a break point just immediately after the dofilter() method and stop there, the JSP page is not displayed. So if i get your right: 1. If the above is done without flushing the data .. then yes. That JSP page is not displayed since i stop at the breakpoint. Correct. The entire response is contained in the output buffer at that point. 2. However if i do a flush before the break point, data will be send to the client eventhough my code stops at the break point? Correct. On the first write to the client, the HTTP Response headers will be written. This is the point at which the response is considered to be committed. The first write may also include some/all of the response body. Flushing can be explicit (the application calls it) or implicit (the container calls flush because - for example - there is no more space in the output buffer). I thought the data flow is part of the control flow .. Gee .. i got this wrong all the while Think i'm seeing the light .. Happy to help. Mark Date: Mon, 18 May 2015 13:43:14 +0100 From: ma...@apache.org To: users@tomcat.apache.org Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve On 18/05/2015 13:31, Kim Ming Yap wrote: Thanks Mark for your suggestion. I'm still confused over the last part where you mentioned that 'i am confusing myself between control and data'. The response object contains output stream (data) to be displayed. Always the case. No. The response contains a reference to the output stream. The output stream can be flushed to the client *at any point*. There is no guarantee that it will contain the [data] to be displayed. The (incorrect) sequences you list below describe the control flow. The data flow (when the application reads the request body, when the application writes the request body and when the request body is written to the client) is completely separate. If i enter valid credential .. you'll noticed the flow exactly as indicated on my email (I've traced is using system.out.println) request -- valve -- JAAS -- filter -- JSP -- response -- filter -- JAAS -- valve -- browser Again, no. JAAS does not call the filter. Your valve calls the Authenticator which calls JAAS and then (via some additional objects) the Authenticator calls the filter. Neither the request nor the response are part of the processing chain. They are objects that are passed up and down
RE: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
ok. cool :) i understand better. Now here's comes to crucial point and question when comes to JAAS. I know the benefit of JAAS - a pluggable authentication and authorization module. Why and in JavaEE's name have a JAAS realm (eg in Tomcat) where the loginmodule has no access to those most important objects - sessions, request etc? I did a bit of research .. hence other web container like JBoss, Oracle WebLogic has to build an extended version of their authentication module to capture those important objects .. I just don't comprehend this.This is mind boggling .. I have spent almost 4 weeks on trying to solve this basic problem when comes to form based authentication using JAAS. 1. Valid credential - no issue2. Credential disabled due to gt 3 retry - This message propagate to the error page3. Invalid user id - This message propagate to error page4. Invalid password - This message propagate to error page There's no way to propagate the above error messages to the error page from JAAS login module since this module has no access to those important aforementioned objects. Hence i turn to valve (storing ThreadLocal). But as you can see, the error page gets displayed first even before i can store them in the session object. Without this feature, the only error message i can display is for example: Incorrect email or password. But this is incorrect if the account is disabled. So i'm just flabbergasted that there's a JAAS module but without access to those basic objects used in any web development. This is beyond mind boggling .. Any insights? Date: Mon, 18 May 2015 16:08:41 -0400 From: ch...@christopherschultz.net To: users@tomcat.apache.org Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ming Yap, On 5/18/15 11:43 AM, Kim Ming Yap wrote: so who control the data flow? The data is really just a data stream. Anyone dumping data into that stream controls the flow. Any component with access to the OutputStream to the client can inject something into it. The method call flow doesn't place any restrictions on what each component is allowed to put into that OutputStream. Does the data flow has stages just like control flow? It's the Wild West: any component can do anything it wants. Or is it just the http web server? As long as there are output stream going out .. the http web server will server those output stream to the client's browser? Exactly. Basically no control stages when comes to data flow? Correct. There are basically two stages: 1. Before the response has been committed 2. After the response has been committed The committment of the response occurs when either of the following things happen: a. The response buffer fills up (container flushes buffer) b. A component explicitly flushes the response buffer Before the response has been committed, you can add/modify/remove response headers, change the response status code (e.g. 200 OK), request the creation of an HttpSession, and a few other things. After the response has been committed, you can do none of those things: only sending bytes to the response stream will work after that. But again, the only things that triggers the commit of the response if the response buffer filling up (or an explicit flush() call). Any component can cause that event to occur, and no other components are notified that it's about to happen. You can check to see if the response has been committed, but you can't do anything effective to stop it. - -chris Date: Mon, 18 May 2015 14:54:24 +0100 From: ma...@apache.org To: users@tomcat.apache.org Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve On 18/05/2015 13:57, Kim Ming Yap wrote: Wow .. that really confuses me. I've studied the Java EE component and the basic understanding of flow is as follows (if i do not flush the data) client request -- web container (encapsulate request/response) -- filter (contain request/response object) -- Servlet (JSP) -- filter (request / response object here can be modified here for eventual display on browser) -- client browser On the way back the client browser, if i do a break point just immediately after the dofilter() method and stop there, the JSP page is not displayed. So if i get your right: 1. If the above is done without flushing the data .. then yes. That JSP page is not displayed since i stop at the breakpoint. Correct. The entire response is contained in the output buffer at that point. 2. However if i do a flush before the break point, data will be send to the client eventhough my code stops at the break point? Correct. On the first write to the client, the HTTP Response headers will be written. This is the point at which the response is considered
Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ming Yap, On 5/18/15 4:56 PM, Kim Ming Yap wrote: Now here's comes to crucial point and question when comes to JAAS. I know the benefit of JAAS - a pluggable authentication and authorization module. Why and in JavaEE's name have a JAAS realm (eg in Tomcat) where the loginmodule has no access to those most important objects - sessions, request etc? ... because JAAS does not require you to be running within a web context. You can use JAAS in a think client. Or from a command-line client. Or whatever. In those cases, what would you use for the request or session? I did a bit of research .. hence other web container like JBoss, Oracle WebLogic has to build an extended version of their authentication module to capture those important objects .. I just don't comprehend this.This is mind boggling. Pluggable authentication and authorization is kind of an unattainable goal when you want it to work across any use case. You just happen to be thinking of the web-based authentication use case, here, and it's not matching up with your expectations. What if you wanted to use some information about a TLS certificate for authentication? Does the JAAS module now need to have access to the X.509 certificate as well? What about a Smart Card? Where does that fit into your web-based view of JAAS? It's just more complicated than you think, unfortunately. I have spent almost 4 weeks on trying to solve this basic problem when comes to form based authentication using JAAS. 1. Valid credential - no issue2. Credential disabled due to gt 3 retry - This message propagate to the error page3. Invalid user id - This message propagate to error page4. Invalid password - This message propagate to error page You should do some reading about user-enumeration vulnerabilities and similar things. You probably don't want to give this kind of information to a user. Hint: the user might be an adversary, and any information you give them them is something they can use to gain access to your system. For example: if I enter ob...@whitehouse.gov as my username and you tell me user does not exist, I can keep trying usernames until I get one that does exist. Great, now I know the user exists and I can keep trying passwords until I get in. If you tell me credentials disabled, then I will know when I've tripped some kind of maximum login-attempt trigger that will (likely) disable the user for a while. So, I'll adjust my attack strategy so that I only try each user 3 times because I know that after that, they will be disabled. If you have a hard business requirement to tell the user why they aren't being permitted to login, you might want to go back to whoever wrote those requirements and ask them to review them from a security perspective. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVWmE7AAoJEBzwKT+lPKRYLHsP/0SjF8xJlXoZUPLRZVKAvJ9U Lf4c5eokEFOjQdbMx4e3vLnTfYK2dWnq0d1Te3n+Zk6fWahy4ijiHHZsdvsQxHCt VDFmXZe6FcBu1bFzcU9JNnr2RqRDEBd3St7wWlReB49LpgQaXh3jvKQgPK67ChR9 K0kBAgzV9BRXzKRLjkEHhC+Q3jFgzmd2J3HerDCgKB6jSFw6dn8NdZJqCfAIAG6R xtbYvryRrQEVaMNs0Z0eDRsRy3iTAZAA1FZOUGSxVfAWapcj12RtnbKfB6tX+wc1 ghy6ZZW3efQSirvZ4BbYqsptBYzsA3oU25zbJG5jdz170okYLphx9vbtbP7wFQFJ CPANIDWLj/aTKCch+SCOMLlOXCBAR69HobDG3Tzi0riaeZAxNuBV61SZjIUhA+Bl tVfihOoLxZQcPk7s4VoR4w1SD7nBqMSkzbwTJujbjM7UKi311lRr6LqO6DvYEsg1 eX4qpKELndniJ035wrZXjbGtMS6JWDRjmeIJkVc0+6XsdMJ7c1bzaImfJg9dv6x9 ZlKpiTbW4n5jC6jrvu5elRuAudf0Me467y9JDZq6ujMmcPVr3BcQQKb4cHXnPRzh BpHqXcn19LZGatyx0wpz8nf5ZjHQiyeaWOgSjLyk8yJXXz6EyA4SZ8Ndi8O5Z/tb kgPkqUPohzH02HWcg6E2 =q5gu -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
I think Tomcat should provide interfaces for different scenarios .. that's my opinion. So coming back to my web form-based authentication problem, is there a solution to it? I still want to solve my problem Please advice.Thanks. Date: Mon, 18 May 2015 18:01:31 -0400 From: ch...@christopherschultz.net To: users@tomcat.apache.org Subject: Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ming Yap, On 5/18/15 4:56 PM, Kim Ming Yap wrote: Now here's comes to crucial point and question when comes to JAAS. I know the benefit of JAAS - a pluggable authentication and authorization module. Why and in JavaEE's name have a JAAS realm (eg in Tomcat) where the loginmodule has no access to those most important objects - sessions, request etc? ... because JAAS does not require you to be running within a web context. You can use JAAS in a think client. Or from a command-line client. Or whatever. In those cases, what would you use for the request or session? I did a bit of research .. hence other web container like JBoss, Oracle WebLogic has to build an extended version of their authentication module to capture those important objects .. I just don't comprehend this.This is mind boggling. Pluggable authentication and authorization is kind of an unattainable goal when you want it to work across any use case. You just happen to be thinking of the web-based authentication use case, here, and it's not matching up with your expectations. What if you wanted to use some information about a TLS certificate for authentication? Does the JAAS module now need to have access to the X.509 certificate as well? What about a Smart Card? Where does that fit into your web-based view of JAAS? It's just more complicated than you think, unfortunately. I have spent almost 4 weeks on trying to solve this basic problem when comes to form based authentication using JAAS. 1. Valid credential - no issue2. Credential disabled due to gt 3 retry - This message propagate to the error page3. Invalid user id - This message propagate to error page4. Invalid password - This message propagate to error page You should do some reading about user-enumeration vulnerabilities and similar things. You probably don't want to give this kind of information to a user. Hint: the user might be an adversary, and any information you give them them is something they can use to gain access to your system. For example: if I enter ob...@whitehouse.gov as my username and you tell me user does not exist, I can keep trying usernames until I get one that does exist. Great, now I know the user exists and I can keep trying passwords until I get in. If you tell me credentials disabled, then I will know when I've tripped some kind of maximum login-attempt trigger that will (likely) disable the user for a while. So, I'll adjust my attack strategy so that I only try each user 3 times because I know that after that, they will be disabled. If you have a hard business requirement to tell the user why they aren't being permitted to login, you might want to go back to whoever wrote those requirements and ask them to review them from a security perspective. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVWmE7AAoJEBzwKT+lPKRYLHsP/0SjF8xJlXoZUPLRZVKAvJ9U Lf4c5eokEFOjQdbMx4e3vLnTfYK2dWnq0d1Te3n+Zk6fWahy4ijiHHZsdvsQxHCt VDFmXZe6FcBu1bFzcU9JNnr2RqRDEBd3St7wWlReB49LpgQaXh3jvKQgPK67ChR9 K0kBAgzV9BRXzKRLjkEHhC+Q3jFgzmd2J3HerDCgKB6jSFw6dn8NdZJqCfAIAG6R xtbYvryRrQEVaMNs0Z0eDRsRy3iTAZAA1FZOUGSxVfAWapcj12RtnbKfB6tX+wc1 ghy6ZZW3efQSirvZ4BbYqsptBYzsA3oU25zbJG5jdz170okYLphx9vbtbP7wFQFJ CPANIDWLj/aTKCch+SCOMLlOXCBAR69HobDG3Tzi0riaeZAxNuBV61SZjIUhA+Bl tVfihOoLxZQcPk7s4VoR4w1SD7nBqMSkzbwTJujbjM7UKi311lRr6LqO6DvYEsg1 eX4qpKELndniJ035wrZXjbGtMS6JWDRjmeIJkVc0+6XsdMJ7c1bzaImfJg9dv6x9 ZlKpiTbW4n5jC6jrvu5elRuAudf0Me467y9JDZq6ujMmcPVr3BcQQKb4cHXnPRzh BpHqXcn19LZGatyx0wpz8nf5ZjHQiyeaWOgSjLyk8yJXXz6EyA4SZ8Ndi8O5Z/tb kgPkqUPohzH02HWcg6E2 =q5gu -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
On 17/05/2015 23:44, Kim Ming Yap wrote:
Hi,I'm building a website using form based authentication integrating with
JAAS for user based authentication. I don't have issue when a successful
credential is authenticated. Rather I'm having difficulty understanding the
flow of JAAS back to the client should the form based authentication failed.
SOFTWARE:1. Apache Tomee plus 1.7.12. Java 83. Tomcat JAAS Realm
OBJECTIVE:Custom error captured in JAAS login module to propagate to error
page
You are unlikely to get much help from Tomcat with this since
propagating back custom errors is considered poor security practise (an
attacker should not be able to tell why authentication failed).
BASIC UNDERSTANDING:
The Tomcat JAAS layer is not integrated with the web container layer. Hence
the former does not have access to request, session etc.
JAAS is integrated as a Realm - i.e. something that validates
credentials provided by an Authenticator. The Authenticator has full
access to the request and the response. You may want to consider a
custom Authenticator.
SOLUTION:
Using ThreadLocal which capture the custom error message in JAAS layer to be
used when the flow reaches back to the custom valve on the way back to the
browser.
You need to be careful you don't trigger memory leaks when using
ThreadLocals.
PROBELM:Understanding of basic request/response flow involving Tomcat and JAAS
a. request -- valve -- JAAS -- Filter -- Servlet/JSPb. response --
valve (**) -- JAAS -- Filter -- Servlet/JSP
I suspect that order is wrong.
JAAS is called by the Authenticator (which is a valve). The
Authenticator then calls the Filter (via a few other layers).
You might want to check the ordering of your valve and the Authenticator.
(refer to above clause b)ThreadLocal in the JAAS layer managed to capture the
custom error message and it i managed to print it after the getNext() method
of the custom valve. Thought of adding this custom error as an attribute in
the session object.
However I noticed that the error page is already displayed before i could add
this cusom error (immediately after the getNext method).
The error page will be handled by the webapp or the ErrorReportingValve
- both of whichh may get called before your Valve depending on how the
Valve is configured.
Due to that the ready custom error message cannot be used
SAMPLE CODES:
1. web.xml
login-configauth-methodFORM/auth-methodform-login-config
form-login-page/login.jsp/form-login-page
form-error-page/login-redirect-error.jsp?error=true/form-error-page
/form-login-config/login-config
2. Custom valve and defined in META-INF/context.xml
public class SecurityValve extends ValveBase {
public void invoke(Request request, Response response) throws
IOException, ServletException { getNext().invoke(request,
response); system.out.println(after getNext()); -- break point
(BP) }
}
1. Did a break point on SecurityValve (indicated at BP) 2. On forms, i
purposely enter wrong credential and submit 3. Break point stops at
BP 4. login-redirect-error.jsp displayed already5. Since it stop at
break point BP in SecurityValve, the response back to client flow has not
reached the browser. Yet the login-redirect-error.jsp is already displayed
QUESTIONS: How can the login-redirect-error.jsp be displayed on the browser
when the response flowing back to client stop at break point BP? The flow
back to the client is not fully done yet.
You are confusing control and data. The data goes back to the client as
soon as the output is flushed (which can happen in the Servlet/JSP).
I would really appreciate any help.Thanks.
Set a break point in a JSP / Servlet and look at the stack trace to see
which Valves the request/response flow through in which order.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
Hi,I'm building a website using form based authentication integrating with JAAS
for user based authentication. I don't have issue when a successful credential
is authenticated. Rather I'm having difficulty understanding the flow of JAAS
back to the client should the form based authentication failed.SOFTWARE:1.
Apache Tomee plus 1.7.12. Java 83. Tomcat JAAS RealmOBJECTIVE:Custom error
captured in JAAS login module to propagate to error pageBASIC UNDERSTANDING:The
Tomcat JAAS layer is not integrated with the web container layer. Hence the
former does not have access to request, session etc.SOLUTION:Using ThreadLocal
which capture the custom error message in JAAS layer to be used when the flow
reaches back to the custom valve on the way back to the
browser.PROBELM:Understanding of basic request/response flow involving Tomcat
and JAASa. request -- valve -- JAAS -- Filter -- Servlet/JSPb. response
-- valve (**) -- JAAS -- Filter -- Servlet/JSP(refer to above clause
b)ThreadLocal in the JAAS layer managed to capture the custom error message and
it i managed to print it after the getNext() method of the custom valve.
Thought of adding this custom error as an attribute in the session
object.However I noticed that the error page is already displayed before i
could add this cusom error (immediately after the getNext method).Due to that
the ready custom error message cannot be usedSAMPLE CODES:1. web.xml
login-configauth-methodFORM/auth-methodform-login-config
form-login-page/login.jsp/form-login-page
form-error-page/login-redirect-error.jsp?error=true/form-error-page
/form-login-config/login-config2. Custom valve and defined in
META-INF/context.xmlpublic class SecurityValve extends ValveBase {
public void invoke(Request request, Response response) throws IOException,
ServletException { getNext().invoke(request, response);
system.out.println(after getNext()); -- break point (BP) }}1. Did a
break point on SecurityValve (indicated at BP) 2. On forms, i purposely
enter wrong credential and submit 3. Break point stops at BP 4.
login-redirect-error.jsp displayed already5. Since it stop at break point
BP in SecurityValve, the response back to client flow has not reached the
browser. Yet the login-redirect-error.jsp is already displayedQUESTIONS: How
can the login-redirect-error.jsp be displayed on the browser when the response
flowing back to client stop at break point BP? The flow back to the client is
not fully done yet.I would really appreciate any help.Thanks.
Tomcat valve JAAS : form error page displayed first before response reaches back to Tomcat valve
Hi,I'm building a website using form based authentication integrating with JAAS
for user based authentication. I don't have issue when a successful credential
is authenticated. Rather I'm having difficulty understanding the flow of JAAS
back to the client should the form based authentication failed.
SOFTWARE:1. Apache Tomee plus 1.7.12. Java 83. Tomcat JAAS Realm
OBJECTIVE:Custom error captured in JAAS login module to propagate to error page
BASIC UNDERSTANDING:
The Tomcat JAAS layer is not integrated with the web container layer. Hence the
former does not have access to request, session etc.
SOLUTION:
Using ThreadLocal which capture the custom error message in JAAS layer to be
used when the flow reaches back to the custom valve on the way back to the
browser.
PROBELM:Understanding of basic request/response flow involving Tomcat and JAAS
a. request -- valve -- JAAS -- Filter -- Servlet/JSPb. response --
valve (**) -- JAAS -- Filter -- Servlet/JSP
(refer to above clause b)ThreadLocal in the JAAS layer managed to capture the
custom error message and it i managed to print it after the getNext() method of
the custom valve. Thought of adding this custom error as an attribute in the
session object.
However I noticed that the error page is already displayed before i could add
this cusom error (immediately after the getNext method).
Due to that the ready custom error message cannot be used
SAMPLE CODES:
1. web.xml
login-configauth-methodFORM/auth-methodform-login-config
form-login-page/login.jsp/form-login-page
form-error-page/login-redirect-error.jsp?error=true/form-error-page
/form-login-config/login-config
2. Custom valve and defined in META-INF/context.xml
public class SecurityValve extends ValveBase {
public void invoke(Request request, Response response) throws
IOException, ServletException { getNext().invoke(request, response);
system.out.println(after getNext()); -- break point (BP) }
}
1. Did a break point on SecurityValve (indicated at BP) 2. On forms, i
purposely enter wrong credential and submit 3. Break point stops at BP
4. login-redirect-error.jsp displayed already5. Since it stop at break
point BP in SecurityValve, the response back to client flow has not reached the
browser. Yet the login-redirect-error.jsp is already displayed
QUESTIONS: How can the login-redirect-error.jsp be displayed on the browser
when the response flowing back to client stop at break point BP? The flow back
to the client is not fully done yet.
I would really appreciate any help.Thanks.
Re: CGIServlet - Disregarding 404 error-page
That is exactly the line I am referring to.
Simply replacing the call to res.setStatus with res.sendError would
definitely be wrong due to what you described. That change is not what I am
suggesting. It is simply what I did for a quick test. I was thinking it
would be worth it to add a flag as a servlet init-param to allow support
for the error-pages. The default would maintain current functionality so as
not to break anything currently in place.
Something like:
if (!cgiEnv.isValid()) {
if (shouldTriggerErrorPage) {
res.sendError(404);
} else {
res.setStatus(404);
}
}
There are also a few other calls to setStatus that would probably be
handled the same way in order to handle other error codes as well.
As for the if (!cgiEnv.isValid()) condition, isValid() will return false
if a request is made for a file that does not exist. Since the file doesn't
exist, I actually wanted to show a proper 404 error page matching the error
pages for the rest of my server. Currently, all I see is a blank page from
the CGIServlet since my debug level doesn't meet the logging condition.
Thanks for the help,
Jake
On Mon, Mar 16, 2015 at 7:49 PM, Konstantin Kolinko knst.koli...@gmail.com
wrote:
2015-03-16 21:52 GMT+03:00 Jacob Haverkost jdh5...@gmail.com:
Version: 6.0.43
OS: Win7 x64
Currently, the CGIServlet does not appear to support using the 404
error-page specified in the web.xml (ROOT). The error-pages work fine
This appears to be due to the line, res.setStatus(404);, inside of
doGet().
According to the documentation for HttpServletResponse.setStatus(int),
If
this method is used to set an error code, then the container's error page
mechanism will not be triggered.
This line appears in all major versions of Tomcat that I have looked into
(8.0.20, 7.0.59).
Just for a quick test, I changed setStatus to sendError and the
error-page
worked as expected. Is there a way to have the error-page work without
changing the source code? If not, should I submit a bug report to
include a
configuration parameter for the CGIServlet to allow support for the
error-page?
If you are talking about the following: (lines 612-614 in CGIServlet
of current Tomcat 6.0.x)
if (!cgiEnv.isValid()) {
res.setStatus(404);
}
You cannot just change res.setStatus(404); with res.sendError(404),
as that will break the following code that generates a HTML page with
a debug message.
See the block starting with if (debug = 10).
My guess (without looking deep into this) is that if
(!cgiEnv.isValid()) condition is there to catch a configuration
error. I mean that you would not see that with a properly configured
CGIServlet. If my guess is wrong, you need to provide a specific use
case that demonstrates otherwise.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CGIServlet - Disregarding 404 error-page
2015-03-16 21:52 GMT+03:00 Jacob Haverkost jdh5...@gmail.com:
Version: 6.0.43
OS: Win7 x64
Currently, the CGIServlet does not appear to support using the 404
error-page specified in the web.xml (ROOT). The error-pages work fine
This appears to be due to the line, res.setStatus(404);, inside of doGet().
According to the documentation for HttpServletResponse.setStatus(int), If
this method is used to set an error code, then the container's error page
mechanism will not be triggered.
This line appears in all major versions of Tomcat that I have looked into
(8.0.20, 7.0.59).
Just for a quick test, I changed setStatus to sendError and the error-page
worked as expected. Is there a way to have the error-page work without
changing the source code? If not, should I submit a bug report to include a
configuration parameter for the CGIServlet to allow support for the
error-page?
If you are talking about the following: (lines 612-614 in CGIServlet
of current Tomcat 6.0.x)
if (!cgiEnv.isValid()) {
res.setStatus(404);
}
You cannot just change res.setStatus(404); with res.sendError(404),
as that will break the following code that generates a HTML page with
a debug message.
See the block starting with if (debug = 10).
My guess (without looking deep into this) is that if
(!cgiEnv.isValid()) condition is there to catch a configuration
error. I mean that you would not see that with a properly configured
CGIServlet. If my guess is wrong, you need to provide a specific use
case that demonstrates otherwise.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
CGIServlet - Disregarding 404 error-page
Version: 6.0.43 OS: Win7 x64 Currently, the CGIServlet does not appear to support using the 404 error-page specified in the web.xml (ROOT). The error-pages work fine This appears to be due to the line, res.setStatus(404);, inside of doGet(). According to the documentation for HttpServletResponse.setStatus(int), If this method is used to set an error code, then the container's error page mechanism will not be triggered. This line appears in all major versions of Tomcat that I have looked into (8.0.20, 7.0.59). Just for a quick test, I changed setStatus to sendError and the error-page worked as expected. Is there a way to have the error-page work without changing the source code? If not, should I submit a bug report to include a configuration parameter for the CGIServlet to allow support for the error-page? Thanks for any feedback or help you can provide. - Jake
Re: CGIServlet - Disregarding 404 error-page
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jacob, On 3/16/15 2:52 PM, Jacob Haverkost wrote: Version: 6.0.43 OS: Win7 x64 Currently, the CGIServlet does not appear to support using the 404 error-page specified in the web.xml (ROOT). The error-pages work fine This appears to be due to the line, res.setStatus(404);, inside of doGet(). According to the documentation for HttpServletResponse.setStatus(int), If this method is used to set an error code, then the container's error page mechanism will not be triggered. This line appears in all major versions of Tomcat that I have looked into (8.0.20, 7.0.59). Just for a quick test, I changed setStatus to sendError and the error-page worked as expected. Is there a way to have the error-page work without changing the source code? If not, should I submit a bug report to include a configuration parameter for the CGIServlet to allow support for the error-page? Thanks for any feedback or help you can provide. It seems reasonable to me to file an enhancement request for this. If you provide a patch, you can get your name into the changelog ;) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVBzo3AAoJEBzwKT+lPKRYkdsP/iutPC4vdDO8LkuwoiXZXM4S Gjh3rWAyqYgVzPq20B+sICkF1cFnovVJnCjdO8D1r2IdFyDcyJoTYDat28oEPqow +3K9vAQUPa+vp0il5YQsi3OuUuna511rH0aEcC4c8M9FyzsMXKLbwZVQu3TQSU2Y 5rImG1K9DODNEVhZA/XbkiOkJunn75D/84FdE3abb1fK9/gn1G/WOJdogelxUhPP FtwDdMK/TsgQM1hDOUF7ieGEYIKyZmzbrXIOnehd2zFAg/1smER9hHUvDGl4UXPd 9MorVWl7C0u74JVntBSrhHmfzUkqz96XG5JZc8mGAxZ9uFdJhvhQMQxCvttB9P7q jEdzJ7t2ZtARH71s0KZya3+r3/F9lkw1OCcF7ITBhRpE4C8Z8vLQqd7puG1mxiUm VIK/pNClVLG60a0L0fvjUJ1tLPEvY2p7SFf0TZ/7rBbGT9/xSqSWESflRLpNExiC SyzlPvilhDsvhyUxKv7L/SqoOqjoiYUtsJyVwVH+jW3JSoayYdq/V9ikTc6bAKaK 6qdBAqm5BXKg8rdYZXQ3OOIVmR/OBnDOTM0GyeeuDYtlhTezYA6Utj/SLorz1OIG viH90/rXWqSAbKrgt/L+YWBIWX4L9M7no+QRQeFKdnjeZpORg0MEkK6/s5pn7wFJ isXMVqWeMk/u6iez4uZ0 =ONFn -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Custom error page for all errors
Is there a way to route all errors to a single web page? Something like: error-page error-codeall/error-code locationmyerror.jsp/location /error-page Basically I want to control the content of everything that goes out of my service. Thanks Mark
Re: Custom error page for all errors
On 19/08/2014 21:05, Mark Haroldson wrote: Is there a way to route all errors to a single web page? Leave out the error-code tag and you define the default error page. That will work in Tomcat 8 and I think in 7 as well. Mark Something like: error-page error-codeall/error-code locationmyerror.jsp/location /error-page Basically I want to control the content of everything that goes out of my service. Thanks Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Single error page for multiple web applications
Thank you all for your input! I do realize that our use case is somewhat odd, as we have multiple webapps that have shared resources and are related in that sense. For now, we should go for the duplication of resources (using Tomcat 7). However, the webAppMount option looks like a fair option to me, once we have migrated to Tomcat 8. Regards, Maarten 2014/1/1 Christopher Schultz ch...@christopherschultz.net -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Leo, On 12/31/13, 3:58 PM, Leo Donahue wrote: On Dec 31, 2013 3:15 AM, Maarten van Hulsentop maar...@vanhulsentop.nl wrote: Hello, We are using Tomcat to host a number of web applications as a uniform solution. We trying to implement something that seems to be an odd requirement, evh it is really a use case for us. We would like to define a single [default] error page for all web applications residing on this Tomcat instance. After some experimentation and googling around, it seems that there is no clear-cut solution for this. I see a few options; - Let the global conf/web.xml define error pages for all web applications at once. However these are always relative to the web application context, and require every web application to pack the error pages again, which is a duplicate of resources and defeats the DRY principle. I asked a question similar to this a while back regarding JSF templates. If you pick a location to share this resource among all web apps, then your web apps aren't self contained. The solution is in your build / deploy process. +1 - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSxGvAAAoJEBzwKT+lPKRYWxsQALL6eBfL6J9Gv1Lkw1YY4sHo BmVEDiOW2fKpI8U7XJgWeGOJosN0Pd7hrBh4NP8KZtqP8Xx+t7yf+R0iIaftp6a9 cN237abc629k5x8k3Cg5XwY94mVMVYRTbLu4BnlsERVCVskw+A4dhcAfwwdJRykc fg0FbLN0WV33uYz7zFsSl0hxP2Yhxl1ZQBocn8OgwdiEkO17K6NLZhfD54AX3W5i CfyXRImO6hdpHg3+XTgEQvyfP0/Ydw4n7B8XqRBN9fjOWc2hQp+SYR6Th8BrPWz1 tRLDR07SmN3BlwSikAiiX7tibzWAfLBK5ENDJ2nUVWhAlp4A9Hbz6W+eOrHu1Bzy ghYVs+MMWqd0axBomKVvBq4giL1jhSB2fMno6HdLup/+FF4cdGmfK3eWM5h15rwq +hoXjJguZIA2riKlbn5oPKYTEpiP65ufZ5Wa2ylY5KOgQTvENYWgYNj/3p3E9gQY PIh9IFUjSXaeG4dZnx9ouUNGO8cBaFPYiBfTaaPyY0DRsatV96z6zCKu249GEcgM GZ1gumDJN0mbfsUayqGfBkhneUi83xwDItejjYxyhlxMv3bYesMxGcnmH1bN5UlC n/s438m6CpfvIVTq/aQH0AZqStOeVKR5uBX6nqF+yFb7IWa2XpbVonAjYjlsVMDk IaUOf1dAf8ISd41svgSc =qThL -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Single error page for multiple web applications
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Leo, On 12/31/13, 3:58 PM, Leo Donahue wrote: On Dec 31, 2013 3:15 AM, Maarten van Hulsentop maar...@vanhulsentop.nl wrote: Hello, We are using Tomcat to host a number of web applications as a uniform solution. We trying to implement something that seems to be an odd requirement, evh it is really a use case for us. We would like to define a single [default] error page for all web applications residing on this Tomcat instance. After some experimentation and googling around, it seems that there is no clear-cut solution for this. I see a few options; - Let the global conf/web.xml define error pages for all web applications at once. However these are always relative to the web application context, and require every web application to pack the error pages again, which is a duplicate of resources and defeats the DRY principle. I asked a question similar to this a while back regarding JSF templates. If you pick a location to share this resource among all web apps, then your web apps aren't self contained. The solution is in your build / deploy process. +1 - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSxGvAAAoJEBzwKT+lPKRYWxsQALL6eBfL6J9Gv1Lkw1YY4sHo BmVEDiOW2fKpI8U7XJgWeGOJosN0Pd7hrBh4NP8KZtqP8Xx+t7yf+R0iIaftp6a9 cN237abc629k5x8k3Cg5XwY94mVMVYRTbLu4BnlsERVCVskw+A4dhcAfwwdJRykc fg0FbLN0WV33uYz7zFsSl0hxP2Yhxl1ZQBocn8OgwdiEkO17K6NLZhfD54AX3W5i CfyXRImO6hdpHg3+XTgEQvyfP0/Ydw4n7B8XqRBN9fjOWc2hQp+SYR6Th8BrPWz1 tRLDR07SmN3BlwSikAiiX7tibzWAfLBK5ENDJ2nUVWhAlp4A9Hbz6W+eOrHu1Bzy ghYVs+MMWqd0axBomKVvBq4giL1jhSB2fMno6HdLup/+FF4cdGmfK3eWM5h15rwq +hoXjJguZIA2riKlbn5oPKYTEpiP65ufZ5Wa2ylY5KOgQTvENYWgYNj/3p3E9gQY PIh9IFUjSXaeG4dZnx9ouUNGO8cBaFPYiBfTaaPyY0DRsatV96z6zCKu249GEcgM GZ1gumDJN0mbfsUayqGfBkhneUi83xwDItejjYxyhlxMv3bYesMxGcnmH1bN5UlC n/s438m6CpfvIVTq/aQH0AZqStOeVKR5uBX6nqF+yFb7IWa2XpbVonAjYjlsVMDk IaUOf1dAf8ISd41svgSc =qThL -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Single error page for multiple web applications
Hello, We are using Tomcat to host a number of web applications as a uniform solution. We trying to implement something that seems to be an odd requirement, even though it is really a use case for us. We would like to define a single [default] error page for all web applications residing on this Tomcat instance. After some experimentation and googling around, it seems that there is no clear-cut solution for this. I see a few options; - Let the global conf/web.xml define error pages for all web applications at once. However these are always relative to the web application context, and require every web application to pack the error pages again, which is a duplicate of resources and defeats the DRY principle. - An Error reporting valve can be implemented to handle error pages. Simply extend ErrorReportValve delivered from Tomcat and implement the report() method. But then how should this report method behave? 1- It could build up a HTML page from java code directly (as is being done in the Tomcat default implementation of the ErrorReportValve). The downside of this would be that it is not possible to style the page afterwards. 2- It could fetch the HTML page from a location specified in configuration (system property or otherwise) and stream it to the client. But is it possible to have dynamic behavior in that case (jsp behavior). I think we would need a RequestDispatcher for that and that is supposed to be in context i presume. 3- It could fetch the ROOT context (which has to be crossContext=true then i assume) and delegate the handling of errors to a page in the root context. This one would have my preference, as it allows the configuration of a single error page, while trying to stick (mimic) as much of the normal J2EE behavior as possible. But it also seems to be the most tricky one. Also, i am not sure on the crossContext setting. Documentation points out that it should not be set on security conscious environments. My experience is that security is always important, so does this make it a no-no or is this a theoretical security risk? Please share your opinions about this, things i missed, or (even better!) your solution :) Thank you in advance! Regards, Maarten van Hulsentop
Re: Single error page for multiple web applications
Hello Maarten, When I was in the same boat, I found http://stackoverflow.com/questions/13914575/how-to-build-server-level-custom-error-page-in-tomcatand http://wiki.apache.org/tomcat/FAQ/Miscellaneous#Q6 both very helpful. I found these by googling https://www.google.nl/?gws_rd=crei=ALNzUtHWPKKN4wTVv4DgAw#q=tomcat+webapp+error+pagesafe=off HTH Kind regards/met vriendelijke groet, Serge Fonville http://www.sergefonville.nl 2013/12/31 Maarten van Hulsentop maar...@vanhulsentop.nl Hello, We are using Tomcat to host a number of web applications as a uniform solution. We trying to implement something that seems to be an odd requirement, even though it is really a use case for us. We would like to define a single [default] error page for all web applications residing on this Tomcat instance. After some experimentation and googling around, it seems that there is no clear-cut solution for this. I see a few options; - Let the global conf/web.xml define error pages for all web applications at once. However these are always relative to the web application context, and require every web application to pack the error pages again, which is a duplicate of resources and defeats the DRY principle. - An Error reporting valve can be implemented to handle error pages. Simply extend ErrorReportValve delivered from Tomcat and implement the report() method. But then how should this report method behave? 1- It could build up a HTML page from java code directly (as is being done in the Tomcat default implementation of the ErrorReportValve). The downside of this would be that it is not possible to style the page afterwards. 2- It could fetch the HTML page from a location specified in configuration (system property or otherwise) and stream it to the client. But is it possible to have dynamic behavior in that case (jsp behavior). I think we would need a RequestDispatcher for that and that is supposed to be in context i presume. 3- It could fetch the ROOT context (which has to be crossContext=true then i assume) and delegate the handling of errors to a page in the root context. This one would have my preference, as it allows the configuration of a single error page, while trying to stick (mimic) as much of the normal J2EE behavior as possible. But it also seems to be the most tricky one. Also, i am not sure on the crossContext setting. Documentation points out that it should not be set on security conscious environments. My experience is that security is always important, so does this make it a no-no or is this a theoretical security risk? Please share your opinions about this, things i missed, or (even better!) your solution :) Thank you in advance! Regards, Maarten van Hulsentop
Re: Single error page for multiple web applications
Hello Serge, Thank you for your reply. This option seems to be similar to the first thing i tried, editing conf/web.xml. As is suggested in http://stackoverflow.com/questions/13914575/how-to-build-server-level-custom-error-page-in-tomcat But contrary to what's stated in the stackoverlow message, this does not work if the error occours in the context of another web application. The following issue description is similar to mine; http://anthonyjdev.blogspot.nl/2012/09/custom-error-page-for-all-apps-in-tomcat.html In this case, even if the location is defined in conf/web.xml (global), the error pages are being searched for in the context of the web application that issued the error. In strict J2EE sense, i do understand that reasoning. That's not what i want though ;) If i am wrong about the understanding of all of this, please correct me. But i just tried that stackoverlow approach again and still it seems to be tied to the webapp that issues the error. Thank you, Regards, Maarten . 2013/12/31 Serge Fonville serge.fonvi...@gmail.com Hello Maarten, When I was in the same boat, I found http://stackoverflow.com/questions/13914575/how-to-build-server-level-custom-error-page-in-tomcatand http://wiki.apache.org/tomcat/FAQ/Miscellaneous#Q6 both very helpful. I found these by googling https://www.google.nl/?gws_rd=crei=ALNzUtHWPKKN4wTVv4DgAw#q=tomcat+webapp+error+pagesafe=off HTH Kind regards/met vriendelijke groet, Serge Fonville http://www.sergefonville.nl 2013/12/31 Maarten van Hulsentop maar...@vanhulsentop.nl Hello, We are using Tomcat to host a number of web applications as a uniform solution. We trying to implement something that seems to be an odd requirement, even though it is really a use case for us. We would like to define a single [default] error page for all web applications residing on this Tomcat instance. After some experimentation and googling around, it seems that there is no clear-cut solution for this. I see a few options; - Let the global conf/web.xml define error pages for all web applications at once. However these are always relative to the web application context, and require every web application to pack the error pages again, which is a duplicate of resources and defeats the DRY principle. - An Error reporting valve can be implemented to handle error pages. Simply extend ErrorReportValve delivered from Tomcat and implement the report() method. But then how should this report method behave? 1- It could build up a HTML page from java code directly (as is being done in the Tomcat default implementation of the ErrorReportValve). The downside of this would be that it is not possible to style the page afterwards. 2- It could fetch the HTML page from a location specified in configuration (system property or otherwise) and stream it to the client. But is it possible to have dynamic behavior in that case (jsp behavior). I think we would need a RequestDispatcher for that and that is supposed to be in context i presume. 3- It could fetch the ROOT context (which has to be crossContext=true then i assume) and delegate the handling of errors to a page in the root context. This one would have my preference, as it allows the configuration of a single error page, while trying to stick (mimic) as much of the normal J2EE behavior as possible. But it also seems to be the most tricky one. Also, i am not sure on the crossContext setting. Documentation points out that it should not be set on security conscious environments. My experience is that security is always important, so does this make it a no-no or is this a theoretical security risk? Please share your opinions about this, things i missed, or (even better!) your solution :) Thank you in advance! Regards, Maarten van Hulsentop
Re: Single error page for multiple web applications
On Dec 31, 2013 3:15 AM, Maarten van Hulsentop maar...@vanhulsentop.nl wrote: Hello, We are using Tomcat to host a number of web applications as a uniform solution. We trying to implement something that seems to be an odd requirement, evh it is really a use case for us. We would like to define a single [default] error page for all web applications residing on this Tomcat instance. After some experimentation and googling around, it seems that there is no clear-cut solution for this. I see a few options; - Let the global conf/web.xml define error pages for all web applications at once. However these are always relative to the web application context, and require every web application to pack the error pages again, which is a duplicate of resources and defeats the DRY principle. I asked a question similar to this a while back regarding JSF templates. If you pick a location to share this resource among all web apps, then your web apps aren't self contained. The solution is in your build / deploy process. If you want to ignore that advice, Tomcat 8 now has webAppMount, if want to go there. I still haven't had a chance to explore that option. Leo
Re: Error page messages
David Kerber wrote: On 11/30/2012 5:59 PM, André Warnier wrote: Christopher Schultz wrote: ... I've even seen a site with a Perl-based (or was it PHP-based) service .. must have been PHP, not Perl, I'm sure. We Perl guys don't do things that way. As I was telling Leo off-line, we have a nice global switch called fatals_to_browser, which you can just turn on on a dev website if you want to see the stack traces, and turn off for a prod website where you don't. So when you deliver software to customers, you turn it off, and it just looks a lot better. Not that you need the feature too often either, because Perl always finds a way to interpret your code so as to do something, instead of That's really scary! just giving up. It was meant to be, how do you say this, tongue in cheek ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Error page messages
Are there standardized server responses that one should expect to see when dealing with java.lang, javax.servlet and javax.faces exceptions that should be displayed to the client? I don't know that I would expect to see any of these on a public website, as I am likely not to care what happens on the server I'm browsing, as long as the server can recover/redirect. Leo
Re: Error page messages
On 30/11/2012 21:00, Leo Donahue - RDSA IT wrote: Are there standardized server responses that one should expect to see when dealing with java.lang, javax.servlet and javax.faces exceptions that should be displayed to the client? You mean status codes or error pages? If an exception isn't handled* by the app then it's 500 and a stacktrace if you haven't configured a custom error page. Those packages probably have a few tens of exceptions that could be thrown. I don't know that I would expect to see any of these on a public website, as I am likely not to care what happens on the server I'm browsing, as long as the server can recover/redirect. Catch them at the appropriate point in your code, or configure a custom error page. p * uncaught exception is the usual term. -- [key:62590808] signature.asc Description: OpenPGP digital signature
RE: Error page messages
-Original Message- From: Pid [mailto:p...@pidster.com] Sent: Friday, November 30, 2012 3:04 PM To: Tomcat Users List Subject: Re: Error page messages On 30/11/2012 21:00, Leo Donahue - RDSA IT wrote: Are there standardized server responses that one should expect to see when dealing with java.lang, javax.servlet and javax.faces exceptions that should be displayed to the client? You mean status codes or error pages? Error pages. If an exception isn't handled* by the app then it's 500 and a stacktrace if you haven't configured a custom error page. Those packages probably have a few tens of exceptions that could be thrown. I don't know that I would expect to see any of these on a public website, as I am likely not to care what happens on the server I'm browsing, as long as the server can recover/redirect. Catch them at the appropriate point in your code, or configure a custom error page. And what kind of information does one show the user in a custom error page? I don't know of any public facing websites, off hand, that show uncaught exception messages. I was just trying to decide what I would show, if anything, if I configured a custom error page for certain types of exceptions, such as java.lang, or javax.servlet, or javax.faces. p * uncaught exception is the usual term. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Error page messages
On 30/11/2012 22:09, Leo Donahue - RDSA IT wrote: -Original Message- From: Pid [mailto:p...@pidster.com] Sent: Friday, November 30, 2012 3:04 PM To: Tomcat Users List Subject: Re: Error page messages On 30/11/2012 21:00, Leo Donahue - RDSA IT wrote: Are there standardized server responses that one should expect to see when dealing with java.lang, javax.servlet and javax.faces exceptions that should be displayed to the client? You mean status codes or error pages? Error pages. If an exception isn't handled* by the app then it's 500 and a stacktrace if you haven't configured a custom error page. Those packages probably have a few tens of exceptions that could be thrown. I don't know that I would expect to see any of these on a public website, as I am likely not to care what happens on the server I'm browsing, as long as the server can recover/redirect. Catch them at the appropriate point in your code, or configure a custom error page. And what kind of information does one show the user in a custom error page? I don't know of any public facing websites, off hand, that show uncaught exception messages. I was just trying to decide what I would show, if anything, if I configured a custom error page for certain types of exceptions, such as java.lang, or javax.servlet, or javax.faces. A polite message saying oops, or a fail whale, or a unicorn... p -- [key:62590808] signature.asc Description: OpenPGP digital signature
Re: Error page messages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Leo, On 11/30/12 5:09 PM, Leo Donahue - RDSA IT wrote: -Original Message- From: Pid [mailto:p...@pidster.com] Sent: Friday, November 30, 2012 3:04 PM To: Tomcat Users List Subject: Re: Error page messages On 30/11/2012 21:00, Leo Donahue - RDSA IT wrote: Are there standardized server responses that one should expect to see when dealing with java.lang, javax.servlet and javax.faces exceptions that should be displayed to the client? You mean status codes or error pages? Error pages. If an exception isn't handled* by the app then it's 500 and a stacktrace if you haven't configured a custom error page. Those packages probably have a few tens of exceptions that could be thrown. I don't know that I would expect to see any of these on a public website, as I am likely not to care what happens on the server I'm browsing, as long as the server can recover/redirect. Catch them at the appropriate point in your code, or configure a custom error page. And what kind of information does one show the user in a custom error page? I don't know of any public facing websites, off hand, that show uncaught exception messages. I was just trying to decide what I would show, if anything, if I configured a custom error page for certain types of exceptions, such as java.lang, or javax.servlet, or javax.faces. How about: web.xml: error-page exception-typejava.lang.Throwable/exception-type location/WEB-INF/uncaught-error.html/location /error-page uncaught-error.html: !DOCTYPE html html headtitleError/title/head body h1Error/h1 p Aw, crap. /p /body /html You can put anything in there you want, man. If the stack trace seems too ugly for you (it really is, honestly), then replace it with something else. Need some inspiration? Try Google. Or http://ux.stackexchange.com/questions/15955/how-to-create-a-useful-500-internal-server-error-page - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlC5MMQACgkQ9CaO5/Lv0PC2SwCeNW8Q8enE9m08sq9j6tYVFRX/ csoAniXbINKCbXd1ix+J9Nd3dHo0piLE =EnMx -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Error page messages
From: Leo Donahue - RDSA IT [mailto:leodona...@mail.maricopa.gov] Subject: RE: Error page messages I don't know of any public facing websites, off hand, that show uncaught exception messages. You need to get out more - there are tons of poorly implemented websites that will splatter stack traces to the browser, especially during those odd hours when something is out for backup, maintenance, etc. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Error page messages
-Original Message- From: Pid [mailto:p...@pidster.com] Sent: Friday, November 30, 2012 3:13 PM To: Tomcat Users List Subject: Re: Error page messages On 30/11/2012 22:09, Leo Donahue - RDSA IT wrote: -Original Message- From: Pid [mailto:p...@pidster.com] Sent: Friday, November 30, 2012 3:04 PM To: Tomcat Users List Subject: Re: Error page messages On 30/11/2012 21:00, Leo Donahue - RDSA IT wrote: Are there standardized server responses that one should expect to see when dealing with java.lang, javax.servlet and javax.faces exceptions that should be displayed to the client? You mean status codes or error pages? Error pages. If an exception isn't handled* by the app then it's 500 and a stacktrace if you haven't configured a custom error page. Those packages probably have a few tens of exceptions that could be thrown. I don't know that I would expect to see any of these on a public website, as I am likely not to care what happens on the server I'm browsing, as long as the server can recover/redirect. Catch them at the appropriate point in your code, or configure a custom error page. And what kind of information does one show the user in a custom error page? I don't know of any public facing websites, off hand, that show uncaught exception messages. I was just trying to decide what I would show, if anything, if I configured a custom error page for certain types of exceptions, such as java.lang, or javax.servlet, or javax.faces. A polite message saying oops, or a fail whale, or a unicorn... p Good options, and very tempting. Maybe one of these? http://tinyurl.com/bvl2gko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Error page messages
-Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Friday, November 30, 2012 3:19 PM To: Tomcat Users List Subject: Re: Error page messages -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Leo, On 11/30/12 5:09 PM, Leo Donahue - RDSA IT wrote: -Original Message- From: Pid [mailto:p...@pidster.com] Sent: Friday, November 30, 2012 3:04 PM To: Tomcat Users List Subject: Re: Error page messages On 30/11/2012 21:00, Leo Donahue - RDSA IT wrote: Are there standardized server responses that one should expect to see when dealing with java.lang, javax.servlet and javax.faces exceptions that should be displayed to the client? You mean status codes or error pages? Error pages. If an exception isn't handled* by the app then it's 500 and a stacktrace if you haven't configured a custom error page. Those packages probably have a few tens of exceptions that could be thrown. I don't know that I would expect to see any of these on a public website, as I am likely not to care what happens on the server I'm browsing, as long as the server can recover/redirect. Catch them at the appropriate point in your code, or configure a custom error page. And what kind of information does one show the user in a custom error page? I don't know of any public facing websites, off hand, that show uncaught exception messages. I was just trying to decide what I would show, if anything, if I configured a custom error page for certain types of exceptions, such as java.lang, or javax.servlet, or javax.faces. How about: web.xml: error-page exception-typejava.lang.Throwable/exception-type location/WEB-INF/uncaught-error.html/location /error-page uncaught-error.html: !DOCTYPE html html headtitleError/title/head body h1Error/h1 p Aw, crap. /p /body /html Yeah, I blew off some steam playing on dev port 8080 with some fun messages just now. This whole time I thought by confusing my end users by taking them back to the web app's main page when an exception occurs was a bad idea. I really didn't want to tell them, hey, sorry but the javax.faces.View expired because you waited too long to do something productive. You can put anything in there you want, man. If the stack trace seems too ugly for you (it really is, honestly), then replace it with something else. Need some inspiration? Try Google. Or http://ux.stackexchange.com/questions/15955/how-to-create-a-useful-500- internal-server-error-page - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlC5MMQACgkQ9CaO5/Lv0PC2SwCeNW8Q8enE9m08sq9j6tYV FRX/ csoAniXbINKCbXd1ix+J9Nd3dHo0piLE =EnMx -END PGP SIGNATURE-
RE: Error page messages
-Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Friday, November 30, 2012 3:28 PM To: Tomcat Users List Subject: RE: Error page messages From: Leo Donahue - RDSA IT [mailto:leodona...@mail.maricopa.gov] Subject: RE: Error page messages I don't know of any public facing websites, off hand, that show uncaught exception messages. You need to get out more ... - Chuck +1 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Error page messages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 11/30/12 5:28 PM, Caldarale, Charles R wrote: From: Leo Donahue - RDSA IT [mailto:leodona...@mail.maricopa.gov] Subject: RE: Error page messages I don't know of any public facing websites, off hand, that show uncaught exception messages. You need to get out more - there are tons of poorly implemented websites that will splatter stack traces to the browser, especially during those odd hours when something is out for backup, maintenance, etc. My favorite ones run IIS. They give you loads of information about what really went wrong. I've even seen a site with a Perl-based (or was it PHP-based) service bombed because it couldn't connect to the database. In the error message were the credentials the script had tried to use as well as the hostname of the database, etc. Basically, a recipe book for attacks. Fail. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlC5NogACgkQ9CaO5/Lv0PD7jQCggobiKE0Vqxlt6H7QBLA5vhaT jhEAoI2E+TyHim7vd6D0/f7eJvt6rOTj =CDmP -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Error page messages
Christopher Schultz wrote: ... I've even seen a site with a Perl-based (or was it PHP-based) service .. must have been PHP, not Perl, I'm sure. We Perl guys don't do things that way. As I was telling Leo off-line, we have a nice global switch called fatals_to_browser, which you can just turn on on a dev website if you want to see the stack traces, and turn off for a prod website where you don't. So when you deliver software to customers, you turn it off, and it just looks a lot better. Not that you need the feature too often either, because Perl always finds a way to interpret your code so as to do something, instead of just giving up. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Error page messages
On 11/30/2012 5:59 PM, André Warnier wrote: Christopher Schultz wrote: ... I've even seen a site with a Perl-based (or was it PHP-based) service .. must have been PHP, not Perl, I'm sure. We Perl guys don't do things that way. As I was telling Leo off-line, we have a nice global switch called fatals_to_browser, which you can just turn on on a dev website if you want to see the stack traces, and turn off for a prod website where you don't. So when you deliver software to customers, you turn it off, and it just looks a lot better. Not that you need the feature too often either, because Perl always finds a way to interpret your code so as to do something, instead of That's really scary! just giving up. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: NPE during custom error page handling in Tomcat 7.0.32
This is resolved -- at least this is a formula that works:
Tomcat.addServlet(context, error_jspx, new error_jspx());
context.addServletMapping(/error.jspx, error_jspx);
while this doesn't:
Tomcat.addServlet(context, error_jspx, new
error_jspx()).addMapping(/error.jspx);
On Wed, Oct 10, 2012 at 8:06 PM, Sean Owen sro...@apache.org wrote:
Hello all,
I'm looking for any ideas on the following issue:
https://issues.apache.org/bugzilla/show_bug.cgi?id=53958
On Tomcat 7.0.32, using embedded Tomcat, I'm seeing a
NullPointerException when using a custom error page. The page itself
is fine and loads if accessed directly. Triggering an error like a 404
results in an NPE during handling of the error page, like:
Oct 10, 2012 7:47:29 PM org.apache.catalina.core.StandardHostValve custom
SEVERE: Exception Processing ErrorPage[errorCode=404, location=/error.jspx]
java.lang.NullPointerException
at
org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:456)
at
org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:327)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:193)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
...
Mark's tried to reproduce it and can't, even with the exact same test
case I'm running, copied in the issue there (and copied below).
I'm wondering if anyone sees an error in the configuration, or can
imagine what the issue may be from the additional details in the
issue. Or, even has time to try out the test case locally.
Best regards and thanks for any ideas.
Sean
import java.io.File;
import org.apache.catalina.Context;
import org.apache.catalina.Lifecycle;
import org.apache.catalina.LifecycleEvent;
import org.apache.catalina.LifecycleListener;
import org.apache.catalina.Server;
import org.apache.catalina.connector.Connector;
import org.apache.catalina.core.JasperListener;
import org.apache.catalina.deploy.ErrorPage;
import org.apache.catalina.startup.Tomcat;
public class Test {
public static void main(String[] args) throws Exception {
Tomcat tomcat = new Tomcat();
Connector connector = new
Connector(org.apache.coyote.http11.Http11NioProtocol);
connector.setPort(8080);
connector.setSecure(false);
connector.setScheme(http);
File tmpDir = new File(System.getProperty(java.io.tmpdir));
tomcat.setBaseDir(tmpDir.getAbsolutePath());
tomcat.setConnector(connector);
tomcat.getService().addConnector(connector);
File contextPath = new File(tmpDir, context);
contextPath.mkdirs();
Context context = tomcat.addContext(, contextPath.getAbsolutePath());
context.setWebappVersion(3.0);
ErrorPage errorPage = new ErrorPage();
errorPage.setErrorCode(404);
errorPage.setLocation(/error.jspx);
context.addErrorPage(errorPage);
Server server = tomcat.getServer();
LifecycleListener jasperListener = new JasperListener();
server.addLifecycleListener(jasperListener);
jasperListener.lifecycleEvent(new LifecycleEvent(server,
Lifecycle.BEFORE_INIT_EVENT, null));
Tomcat.addServlet(context, error_jspx, new
error_jspx()).addMapping(/error.jspx);
tomcat.start();
server.await();
}
}
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
NPE during custom error page handling in Tomcat 7.0.32
Hello all,
I'm looking for any ideas on the following issue:
https://issues.apache.org/bugzilla/show_bug.cgi?id=53958
On Tomcat 7.0.32, using embedded Tomcat, I'm seeing a
NullPointerException when using a custom error page. The page itself
is fine and loads if accessed directly. Triggering an error like a 404
results in an NPE during handling of the error page, like:
Oct 10, 2012 7:47:29 PM org.apache.catalina.core.StandardHostValve custom
SEVERE: Exception Processing ErrorPage[errorCode=404, location=/error.jspx]
java.lang.NullPointerException
at
org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:456)
at
org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:327)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:193)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
...
Mark's tried to reproduce it and can't, even with the exact same test
case I'm running, copied in the issue there (and copied below).
I'm wondering if anyone sees an error in the configuration, or can
imagine what the issue may be from the additional details in the
issue. Or, even has time to try out the test case locally.
Best regards and thanks for any ideas.
Sean
import java.io.File;
import org.apache.catalina.Context;
import org.apache.catalina.Lifecycle;
import org.apache.catalina.LifecycleEvent;
import org.apache.catalina.LifecycleListener;
import org.apache.catalina.Server;
import org.apache.catalina.connector.Connector;
import org.apache.catalina.core.JasperListener;
import org.apache.catalina.deploy.ErrorPage;
import org.apache.catalina.startup.Tomcat;
public class Test {
public static void main(String[] args) throws Exception {
Tomcat tomcat = new Tomcat();
Connector connector = new
Connector(org.apache.coyote.http11.Http11NioProtocol);
connector.setPort(8080);
connector.setSecure(false);
connector.setScheme(http);
File tmpDir = new File(System.getProperty(java.io.tmpdir));
tomcat.setBaseDir(tmpDir.getAbsolutePath());
tomcat.setConnector(connector);
tomcat.getService().addConnector(connector);
File contextPath = new File(tmpDir, context);
contextPath.mkdirs();
Context context = tomcat.addContext(, contextPath.getAbsolutePath());
context.setWebappVersion(3.0);
ErrorPage errorPage = new ErrorPage();
errorPage.setErrorCode(404);
errorPage.setLocation(/error.jspx);
context.addErrorPage(errorPage);
Server server = tomcat.getServer();
LifecycleListener jasperListener = new JasperListener();
server.addLifecycleListener(jasperListener);
jasperListener.lifecycleEvent(new LifecycleEvent(server,
Lifecycle.BEFORE_INIT_EVENT, null));
Tomcat.addServlet(context, error_jspx, new
error_jspx()).addMapping(/error.jspx);
tomcat.start();
server.await();
}
}
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: empty error page when using sendError()
On Sat, 11 Aug 2012 09:07:11 +0100 Mark Thomas ma...@apache.org wrote: You are already in an error page so sendError will not trigger the error page matching process again. If it did there is a strong possibility that you could end up in an infinite loop. Mark This makes sense, thanks! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: empty error page when using sendError()
On Fri, 10 Aug 2012 10:50:17 -0400 Christopher Schultz ch...@christopherschultz.net wrote: When I try to send error page directly from ErrorHandler using HttpServletResponse, it works fine and page is displayed, so it seems the problem is with sendError() method. Is this an expected behaviour or some sort of bug? Oh... do you mean there is no content when your ErrorHandler sends the response? Are you producing any content? I certainly don't see a place where you are producing a response document of any kind. What did you expect the client to see on the screen? Hi, thanks for the reply. 1) I mean if I try to send the response like this: --- PrintWriter pw = response.getWriter(); pw.write(htmlbodyError!/body/html); pw.close(); --- it works OK and I see an Error! message on the client side. 2) If I use sendError() method instead, I don't see anything - just an empty page. 3) This happens ONLY if the request was forwarded to ErrorHandler servlet by Tomcat in case of an error or exception: --- error-page exception-typejava.lang.Throwable/exception-type location/ErrorHandler/location /error-page error-page error-code404/error-code location/ErrorHandler/location /error-page --- If, for example, I request ErrorHandler directly by URL, I can see an error page. So I wonder why this happens: is it a bug or my misunderstanding of sendError() method? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: empty error page when using sendError()
On 11/08/2012 08:17, Vladimir Mokrozub wrote: On Fri, 10 Aug 2012 10:50:17 -0400 Christopher Schultz ch...@christopherschultz.net wrote: When I try to send error page directly from ErrorHandler using HttpServletResponse, it works fine and page is displayed, so it seems the problem is with sendError() method. Is this an expected behaviour or some sort of bug? Oh... do you mean there is no content when your ErrorHandler sends the response? Are you producing any content? I certainly don't see a place where you are producing a response document of any kind. What did you expect the client to see on the screen? Hi, thanks for the reply. 1) I mean if I try to send the response like this: --- PrintWriter pw = response.getWriter(); pw.write(htmlbodyError!/body/html); pw.close(); --- it works OK and I see an Error! message on the client side. 2) If I use sendError() method instead, I don't see anything - just an empty page. 3) This happens ONLY if the request was forwarded to ErrorHandler servlet by Tomcat in case of an error or exception: --- error-page exception-typejava.lang.Throwable/exception-type location/ErrorHandler/location /error-page error-page error-code404/error-code location/ErrorHandler/location /error-page --- If, for example, I request ErrorHandler directly by URL, I can see an error page. So I wonder why this happens: is it a bug or my misunderstanding of sendError() method? You are already in an error page so sendError will not trigger the error page matching process again. If it did there is a strong possibility that you could end up in an infinite loop. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
empty error page when using sendError()
Hello,
I have a problem (tried Tomcat 7.0.29 and Glassfish 3.1) with
displaying an error page when exception is thrown and processed by
another servlet.
Here is what I've added to web.xml:
-
error-page
exception-typejava.lang.Throwable/exception-type
location/ErrorHandler/location
/error-page
-
Here is a test servlet that throws an exception:
-
@WebServlet(/TestServlet)
public class TestServlet extends HttpServlet {
protected void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException,
IOException {
throw new RuntimeException(TestServlet exception);
}
}
-
And here is ErrorHandler servlet:
-
@WebServlet(/ErrorHandler)
public class ErrorHandler extends HttpServlet {
protected void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException,
IOException {
// process exception thrown
response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR,
(String)
request.getAttribute(javax.servlet.error.message));
}
protected void doPost(HttpServletRequest request,
HttpServletResponse response) throws ServletException,
IOException {
doGet(request, response);
}
}
-
When I type http://server-name/TestServlet in the address bar, I get
an empty page instead of default Tomcat error page, though the status
code in the header is correct: HTTP/1.1 500 Internal Server Error.
And even if I add a custom error page in web.xml like this:
-
error-page
error-code500/error-code
location/error.html/location
/error-page
-
I still get an empty page instead of error.html.
When I try to send error page directly from ErrorHandler using
HttpServletResponse, it works fine and page is displayed, so it seems
the problem is with sendError() method. Is this an expected behaviour or
some sort of bug?
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: empty error page when using sendError()
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vlad,
On 8/10/12 3:48 AM, Vladimir Mokrozub wrote:
And here is ErrorHandler servlet: -
@WebServlet(/ErrorHandler) public class ErrorHandler extends
HttpServlet { protected void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException
{ // process exception thrown
response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR,
(String) request.getAttribute(javax.servlet.error.message)); }
protected void doPost(HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException
{ doGet(request, response); } } -
When I type http://server-name/TestServlet in the address bar, I
get an empty page instead of default Tomcat error page, though the
status code in the header is correct: HTTP/1.1 500 Internal Server
Error.
Try setting the response message explicitly to something unexpected
like Fruit Loops! and see if you get that coming back to the client.
I wonder if your code is not being called at all, but 500 Internal
Server Error is still being returned because there is a real error on
the server.
And even if I add a custom error page in web.xml like this:
- error-page error-code500/error-code
location/error.html/location /error-page
- I still get an empty page instead of
error.html.
When I try to send error page directly from ErrorHandler using
HttpServletResponse, it works fine and page is displayed, so it
seems the problem is with sendError() method. Is this an expected
behaviour or some sort of bug?
Oh... do you mean there is no content when your ErrorHandler sends the
response? Are you producing any content? I certainly don't see a place
where you are producing a response document of any kind. What did you
expect the client to see on the screen?
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlAlH6kACgkQ9CaO5/Lv0PA6VwCfZ6k4ANpBrYytvdNWDY8bjN00
bOEAoJMF67fu0J8qdciUzAfczrl+DMDD
=KYBV
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Manager activeSessions and customized error page
Hi! I configured the Manager's maxActiveSessions attribute in context.xml. If the configured value is exceeded an IllegalStateException createSession: Too many active sessions is thrown in ManagerBase class. In our application we catch this exception around httpServletRequest.getSession(true) and redirect to an customized error page. Works! Now I activated form based authentication via securiy constraint in web.xml. If I try to open the web application with my browser by sending the first request, the response is empty (status 200 OK). Is there any way to map a static customized error page in this scenario? If not: Is there any other approach to limit the number of sessions? Thanks! Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Manager activeSessions and customized error page
2012/5/14 Thomas Rohde t...@ordix.de: Hi! I configured the Manager's maxActiveSessions attribute in context.xml. If the configured value is exceeded an IllegalStateException createSession: Too many active sessions is thrown in ManagerBase class. In our application we catch this exception around httpServletRequest.getSession(true) and redirect to an customized error page. Works! Now I activated form based authentication via securiy constraint in web.xml. If I try to open the web application with my browser by sending the first request, the response is empty (status 200 OK). Is there any way to map a static customized error page in this scenario? It depends on where ErrorReportValve is in the request processing chain in your situation. There were several changes to that (read: fixes) in different Tomcat 7.0.x versions. You did not wrote which version you do use. If it is reproducible in latest 7.0.27, feel free to create a bug report and attach a simple sample web application + steps to reproduce. It might be that it is already reproducible with the standard example app [1], but I have not tried. [1] http://localhost:8080/examples/jsp/security/protected/index.jsp If not: Is there any other approach to limit the number of sessions? I think it is possible with a Filter, Valve or with a SessionListener. It should be also be possible with a custom o.a.c.Manager. YMMV. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: Manager activeSessions and customized error page
-Ursprüngliche Nachricht- Von:Konstantin Kolinko knst.koli...@gmail.com Gesendet: Mo 14.05.2012 15:00 Betreff:Re: Manager activeSessions and customized error page An: Tomcat Users List users@tomcat.apache.org; 2012/5/14 Thomas Rohde t...@ordix.de: Hi! I configured the Manager's maxActiveSessions attribute in context.xml. If the configured value is exceeded an IllegalStateException createSession: Too many active sessions is thrown in ManagerBase class. In our application we catch this exception around httpServletRequest.getSession(true) and redirect to an customized error page. Works! Now I activated form based authentication via securiy constraint in web.xml. If I try to open the web application with my browser by sending the first request, the response is empty (status 200 OK). Is there any way to map a static customized error page in this scenario? It depends on where ErrorReportValve is in the request processing chain in your situation. There were several changes to that (read: fixes) in different Tomcat 7.0.x versions. You did not wrote which version you do use. Sorry! I tested with 7.0.8. If it is reproducible in latest 7.0.27, feel free to create a bug report and attach a simple sample web application + steps to reproduce. It might be that it is already reproducible with the standard example app [1], but I have not tried. [1] http://localhost:8080/examples/jsp/security/protected/index.jsp Now I tried with the standard example and 7.0.27. I get the default 500 error page. Would be great to have a possibiltiy to make a distinguish between this error and any other error. If not: Is there any other approach to limit the number of sessions? I think it is possible with a Filter, Valve or with a SessionListener. It should be also be possible with a custom o.a.c.Manager. YMMV. A Filter was my first approach. But the filter is invoked after authentication has taken place. And for authentication a session is needed. ;-) A HttpSessionListener is invoked AFTER a session is created. It seems that every approach has some ugly pitfalls. :( Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: Manager activeSessions and customized error page
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas, On 5/14/12 9:44 AM, Thomas Rohde wrote: A Filter was my first approach. But the filter is invoked after authentication has taken place. And for authentication a session is needed. ;-) Right: the form authenticator is in a Valve and Valves run before Filters. A HttpSessionListener is invoked AFTER a session is created. Hrm. It seems that every approach has some ugly pitfalls. :( Agreed. Perhaps a different exception type could be used? We are using IllegalStateException but there's no particular reason a different subclass of RuntimeException couldn't be used in this case: something that could then be mapped in web.xml using error-page. Since it would technically be a change to the API to throw something other than IllegalStateException, you might get some push-back on a solution like this. Please file a bug in bugzilla and we'll hash it out over there. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+xK40ACgkQ9CaO5/Lv0PAC7QCfRZTH+jxiw97jNt3oAhyCTGsk yqoAn2ztvQuphobb0VyINu89J9h3YBYg =Dozm -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: Manager activeSessions and customized error page
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14/05/2012 16:58, Christopher Schultz wrote: Thomas, On 5/14/12 9:44 AM, Thomas Rohde wrote: A Filter was my first approach. But the filter is invoked after authentication has taken place. And for authentication a session is needed. ;-) Right: the form authenticator is in a Valve and Valves run before Filters. A HttpSessionListener is invoked AFTER a session is created. Hrm. It seems that every approach has some ugly pitfalls. :( Agreed. Perhaps a different exception type could be used? We are using IllegalStateException but there's no particular reason a different subclass of RuntimeException couldn't be used in this case: something that could then be mapped in web.xml using error-page. Since it would technically be a change to the API to throw something other than IllegalStateException, you might get some push-back on a solution like this. A change to a new sub-class of IllegalStateException shouldn't break anything. Mark Please file a bug in bugzilla and we'll hash it out over there. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPsTIDAAoJEBDAHFovYFnnjYEP/ibbVSvXy1T22zHo/ZPeDuOJ p/AwNGgyafsv/FExSDFVTWiRJNPRpImaVmVnc9JzRj7DQJC1xjQzp0SsCYh9Gu58 ZGyz6U9psDZYbSW6cfNToVdbgJZWEdBXo5jb0s/kU1GHqfKx1ZzwrcKCHc2OAYZ+ XZvMNb29ouCPF7kVdFYyXZm/WVLrw5ZQ1KL60f65iIvZDaBrBCNgnhh7Fhxq2PU+ NzRwWiGWVAPWxk1VcBxZuJQz+qsRqp22FBkaEM8A7mDBTfbJvK+rszBqPNk/YGGq MHRg5DysjTEWizfmRySSw9cSHtQfHq2cQxuxVMfgfMVt67BqeW+r7GB5kUNK/Dpt fKTFw5AkmJDXYSE0tKOgVq1eECiybSP5co/DFrtnNmVQI/AXePrJ+G8lLdC9KYV/ UyjuT8jPl5JUTA6mKUafGCxL1RYDPFZ3KYpeu9mRDW4gMMmVIsp5xUPMZvPRyfBq l6O3zjYGMNtFaedcOColeJuXQTvYqiizB2fPzzJdh10Mmb8G1PMlB0cHjhO3/j/F kQ1W4aQxr4gipQWj0zTqrwZYTkndia0v4VqctbiYJmyHTKAeb6z/Ks9z9yya3vF9 TnvgG+Sf0KEP7zB01MI07UDXP/IdKIyeEhhqIJJ/U4ixSHtBui9MkjfMzjE3V6lw SCucYHY0sZUFwRMg+Mp1 =b/Sy -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: Manager activeSessions and customized error page
-Ursprüngliche Nachricht- Von:Mark Thomas ma...@apache.org Gesendet: Mo 14.05.2012 18:25 Betreff:Re: AW: Manager activeSessions and customized error page An: Tomcat Users List users@tomcat.apache.org; -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14/05/2012 16:58, Christopher Schultz wrote: Thomas, On 5/14/12 9:44 AM, Thomas Rohde wrote: A Filter was my first approach. But the filter is invoked after authentication has taken place. And for authentication a session is needed. ;-) Right: the form authenticator is in a Valve and Valves run before Filters. A HttpSessionListener is invoked AFTER a session is created. Hrm. It seems that every approach has some ugly pitfalls. :( Agreed. Perhaps a different exception type could be used? We are using IllegalStateException but there's no particular reason a different subclass of RuntimeException couldn't be used in this case: something that could then be mapped in web.xml using error-page. Since it would technically be a change to the API to throw something other than IllegalStateException, you might get some push-back on a solution like this. There it is: https://issues.apache.org/bugzilla/show_bug.cgi?id=53230 A change to a new sub-class of IllegalStateException shouldn't break anything. Mark Please file a bug in bugzilla and we'll hash it out over there. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPsTIDAAoJEBDAHFovYFnnjYEP/ibbVSvXy1T22zHo/ZPeDuOJ p/AwNGgyafsv/FExSDFVTWiRJNPRpImaVmVnc9JzRj7DQJC1xjQzp0SsCYh9Gu58 ZGyz6U9psDZYbSW6cfNToVdbgJZWEdBXo5jb0s/kU1GHqfKx1ZzwrcKCHc2OAYZ+ XZvMNb29ouCPF7kVdFYyXZm/WVLrw5ZQ1KL60f65iIvZDaBrBCNgnhh7Fhxq2PU+ NzRwWiGWVAPWxk1VcBxZuJQz+qsRqp22FBkaEM8A7mDBTfbJvK+rszBqPNk/YGGq MHRg5DysjTEWizfmRySSw9cSHtQfHq2cQxuxVMfgfMVt67BqeW+r7GB5kUNK/Dpt fKTFw5AkmJDXYSE0tKOgVq1eECiybSP5co/DFrtnNmVQI/AXePrJ+G8lLdC9KYV/ UyjuT8jPl5JUTA6mKUafGCxL1RYDPFZ3KYpeu9mRDW4gMMmVIsp5xUPMZvPRyfBq l6O3zjYGMNtFaedcOColeJuXQTvYqiizB2fPzzJdh10Mmb8G1PMlB0cHjhO3/j/F kQ1W4aQxr4gipQWj0zTqrwZYTkndia0v4VqctbiYJmyHTKAeb6z/Ks9z9yya3vF9 TnvgG+Sf0KEP7zB01MI07UDXP/IdKIyeEhhqIJJ/U4ixSHtBui9MkjfMzjE3V6lw SCucYHY0sZUFwRMg+Mp1 =b/Sy -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Servlet Mapping w/ Error Page
On 12/31/11 2:04 PM, Konstantin Kolinko wrote:
2011/12/31 George Sextongeor...@mhsoftware.com:
I have a servlet mapping for a page named
/403.html
I can invoke that URL and get a page as expected.
In my deployment descriptor, I have an error mapping:
error-page
error-code403/error-code
location/403.html/location
/error-page
in my code I have
if (someCondition) {
res.sendError(HttpServletResponse.SC_FORBIDDEN);
return;
}
When this code is hit, my custom page is not displayed. I get a blank page.
No error is thrown by tomcat.
I looked at this a little more. It looks like the response may have been
committed before calling HttpServletResponse.sendError(). Once I
re-structured the code to not commit the response, it started working.
If I change the error-page entry to reference a static HTML page, the page
is displayed as expected.
This looks like a bug to me, but I wanted to run it past tomcat-user and
see what other people think.
1. Tomcat version=?
Overall it looks like a bug. But if you submit it I expect you to
provide a simple sample webapp that reproduces it on 7.0.23.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
--
George Sexton
MH Software, Inc.
303 438-9585
http://www.mhsoftware.com/
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Servlet Mapping w/ Error Page
On 1:59 PM, George Sexton wrote:
On 12/31/11 2:04 PM, Konstantin Kolinko wrote:
2011/12/31 George Sextongeor...@mhsoftware.com:
I have a servlet mapping for a page named
/403.html
I can invoke that URL and get a page as expected.
In my deployment descriptor, I have an error mapping:
error-page
error-code403/error-code
location/403.html/location
/error-page
in my code I have
if (someCondition) {
res.sendError(HttpServletResponse.SC_FORBIDDEN);
return;
}
When this code is hit, my custom page is not displayed. I get a
blank page.
No error is thrown by tomcat.
If I change the error-page entry to reference a static HTML page,
the page
is displayed as expected.
This looks like a bug to me, but I wanted to run it past
tomcat-user and
see what other people think.
1. Tomcat version=?
Sorry, I had the best of intentions here. I dl'd the 6.0 for testing.
6.0.35
Overall it looks like a bug. But if you submit it I expect you to
provide a simple sample webapp that reproduces it on 7.0.23.
I could do that.
Hi, George-
One thing to look out for is that location is relative to the root of
the web application. To me, this means that the error page must exist
in every context in which it is declared.
-Terence Bandoian
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Servlet Mapping w/ Error Page
I have a servlet mapping for a page named
/403.html
I can invoke that URL and get a page as expected.
In my deployment descriptor, I have an error mapping:
error-page
error-code403/error-code
location/403.html/location
/error-page
in my code I have
if (someCondition) {
res.sendError(HttpServletResponse.SC_FORBIDDEN);
return;
}
When this code is hit, my custom page is not displayed. I get a blank
page. No error is thrown by tomcat.
If I change the error-page entry to reference a static HTML page, the
page is displayed as expected.
This looks like a bug to me, but I wanted to run it past tomcat-user
and see what other people think.
--
George Sexton
MH Software, Inc.
303 438-9585
http://www.mhsoftware.com/
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Servlet Mapping w/ Error Page
2011/12/31 George Sexton geor...@mhsoftware.com:
I have a servlet mapping for a page named
/403.html
I can invoke that URL and get a page as expected.
In my deployment descriptor, I have an error mapping:
error-page
error-code403/error-code
location/403.html/location
/error-page
in my code I have
if (someCondition) {
res.sendError(HttpServletResponse.SC_FORBIDDEN);
return;
}
When this code is hit, my custom page is not displayed. I get a blank page.
No error is thrown by tomcat.
If I change the error-page entry to reference a static HTML page, the page
is displayed as expected.
This looks like a bug to me, but I wanted to run it past tomcat-user and
see what other people think.
1. Tomcat version=?
Overall it looks like a bug. But if you submit it I expect you to
provide a simple sample webapp that reproduces it on 7.0.23.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Servlet Mapping w/ Error Page
On 12/31/11 2:04 PM, Konstantin Kolinko wrote:
2011/12/31 George Sextongeor...@mhsoftware.com:
I have a servlet mapping for a page named
/403.html
I can invoke that URL and get a page as expected.
In my deployment descriptor, I have an error mapping:
error-page
error-code403/error-code
location/403.html/location
/error-page
in my code I have
if (someCondition) {
res.sendError(HttpServletResponse.SC_FORBIDDEN);
return;
}
When this code is hit, my custom page is not displayed. I get a blank page.
No error is thrown by tomcat.
If I change the error-page entry to reference a static HTML page, the page
is displayed as expected.
This looks like a bug to me, but I wanted to run it past tomcat-user and
see what other people think.
1. Tomcat version=?
Sorry, I had the best of intentions here. I dl'd the 6.0 for testing.
6.0.35
Overall it looks like a bug. But if you submit it I expect you to
provide a simple sample webapp that reproduces it on 7.0.23.
I could do that.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
--
George Sexton
MH Software, Inc.
303 438-9585
http://www.mhsoftware.com/
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
No error-page for IllegalStateException(Too many active sessions) Instead: Empty page HTTP code 200 (OK)
Hello, in somecases, Tomcat dosn't allow output of an error page for too many active sessions. Reproduction: 1) Configure Tomcat 6 or 7 example application to allow maxActiveSessions=1 only (e.g. adding /examples/META-INF/context.xml#SimpeSessionManager...) 2) Visit http://localhost:8080/examples/jsp/security/protected 3) delete cookies 4) hit reresh Shouldshow: Internal Server error 500 But shows: empty page (0 bytes content-length; code 200) Is there a way to catch this exeption from within your web app? Or is it a bug? Thanks, Selaron - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: error-page for http 500 error code does not work
Chris, Through further investigation, I now believe the JSF framework I'm using is absorbing the error, and the framework's error page is what is throwing the 500 error. I wonder if the 500 error thrown by the framework's error page should fall through to the custom error page servlet I've created? The JSF framework is the Sun Visual Web Pack that is no longer supported on the Oracle Netbeans IDE. I posted on the forum for Netbeans in the hopes that someone can tell me how to disable the default exception handler for the Visual Web Pack. Thanks! - Kevin, On 6/3/2011 9:43 AM, Kevin Claver wrote: When the custom error servlet fails to display, I get the stock tomcat http 500 error page. If I look at the access log, I see the 500 error: 192.168.xxx.xxx - - [02/Jun/2011:13:53:14 -0600] POST /HMAApp/faces/main/TaskSearchTab.jsp HTTP/1.0 500 1000 So, you are sure the error happens in the requested JSP and not in the error page itself? If the error page suffers an error... it's all over. - -chris
Re: error-page for http 500 error code does not work
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevin, On 6/7/2011 8:56 AM, Kevin Claver wrote: Through further investigation, I now believe the JSF framework I'm using is absorbing the error, and the framework's error page is what is throwing the 500 error. I wonder if the 500 error thrown by the framework's error page should fall through to the custom error page servlet I've created? As I said, if the error page suffers an error, you can't really show the error page. The JSF framework is the Sun Visual Web Pack that is no longer supported on the Oracle Netbeans IDE. I posted on the forum for Netbeans in the hopes that someone can tell me how to disable the default exception handler for the Visual Web Pack. Post back whatever you find. I'm sure it will help someone in the future (who bothers to search the archives before posting). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3ufJsACgkQ9CaO5/Lv0PCeZwCfTYuzJj9EoW8HZTy5e1/vu6Es OS8AoJxhF6MaCWg70S8fwiX1n0y+3XaI =8D34 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: error-page for http 500 error code does not work
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevin, On 6/3/2011 9:43 AM, Kevin Claver wrote: When the custom error servlet fails to display, I get the stock tomcat http 500 error page. If I look at the access log, I see the 500 error: 192.168.xxx.xxx - - [02/Jun/2011:13:53:14 -0600] POST /HMAApp/faces/main/TaskSearchTab.jsp HTTP/1.0 500 1000 So, you are sure the error happens in the requested JSP and not in the error page itself? If the error page suffers an error... it's all over. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3s3tQACgkQ9CaO5/Lv0PBDRQCfbWW4kboAjuM/gwLUMWZlENBe ujMAoI5+nPvqUy4A+6mnaQMYHpk1gcjn =h0ce -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: error-page for http 500 error code does not work
On 02/06/2011 21:45, Kevin Claver wrote: Two things I would like to note: 1. When I invoke the Java HMAExceptionHandlerServlet configured to be used in the error-page block in the application specific web.xml directly from the URL in the browser, it works. 2. Tomcat 5.5.33 does correctly redirect to the error-page when running on a Windows 7 machine. The only time I have an issue is on the Linux configuration above. The first things I'd check is whether there's something different about your Tomcat installation on Linux. You can ZIP the whole Tomcat install (including the app(s), if they're in tomcat/webapps) and transfer the file unzip on your Linux install. Start it up see if the same thing happens. Also: what error do you see, when the custom error servlet/page fails to display? Is it the same error as you expect or a different one? - if an NPE occurs in your app, do you see a 500 + NPE stacktrace? - or if a 500 occurs, do you see a 404? p signature.asc Description: OpenPGP digital signature
Re: error-page for http 500 error code does not work
Thanks for the quick reply! I zipped the tomcat install and deployed it to my Win 7 machine where it works without issue. When the custom error servlet fails to display, I get the stock tomcat http 500 error page. If I look at the access log, I see the 500 error: 192.168.xxx.xxx - - [02/Jun/2011:13:53:14 -0600] POST /HMAApp/faces/main/TaskSearchTab.jsp HTTP/1.0 500 1000 I also see the com.sun.rave.web.ui.appbase.ApplicationException and java.lang.NullPointerException in the localhost log file (both of which are set to display the custom error page in the application specific web.xml): Jun 2, 2011 1:53:14 PM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet Faces Servlet threw exception com.sun.rave.web.ui.appbase.ApplicationException at com.sun.rave.web.ui.appbase.faces.ViewHandlerImpl.cleanup(ViewHandlerImpl.java:559) at com.sun.rave.web.ui.appbase.faces.ViewHandlerImpl.renderView(ViewHandlerImpl.java:276) at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:107) at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:245) at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:137) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:214) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at com.sun.rave.web.ui.util.UploadFilter.doFilter(UploadFilter.java:198) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:581) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:879) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:662) Caused by: java.lang.NullPointerException at hmaapp.utilmanagement.OPProcMain.prerender(OPProcMain.java:2355) at com.sun.rave.web.ui.appbase.faces.ViewHandlerImpl.prerender(ViewHandlerImpl.java:771) at com.sun.rave.web.ui.appbase.faces.ViewHandlerImpl.renderView(ViewHandlerImpl.java:268) ... 22 more - On 02/06/2011 21:45, Kevin Claver wrote: Two things I would like to note: =20 1. When I invoke the Java HMAExceptionHandlerServlet configured to be = used in the error-page block in the application specific web.xml directly= from the URL in the browser, it works. =20 2. Tomcat 5.5.33 does correctly redirect to the error-page when runnin= g on a Windows 7 machine. The only time I have an issue is on the Linux = configuration above. The first things I'd check is whether there's something different about your Tomcat installation on Linux. You can ZIP the whole Tomcat install (including the app(s), if they're in tomcat/webapps) and transfer the file unzip on your Linux install. Start it up see if the same thing happens. Also: what error do you see, when the custom error servlet/page fails to display? Is it the same error as you expect or a different one? - if an NPE occurs in your app, do you see a 500 + NPE stacktrace? - or if a 500 occurs, do you see a 404? p
RE: error-page for http 500 error code does not work
From: Kevin Claver [mailto:kcla...@yahoo.com] Subject: Re: error-page for http 500 error code does not work I zipped the tomcat install and deployed it to my Win 7 machine where it works without issue. I'll hazard a guess that you have a case sensitivity issue. Something in your configuration specifies the wrong case for who knows what (perhaps a file name), or a file is installed with the wrong casing. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: error-page for http 500 error code does not work
Thanks Charles, however, I did try to change the error code for the custom error servlet to 404 and it works on the Linux install. It's only an issue if I try to trap the 500 error. From: Caldarale, Charles R chuck.caldar...@unisys.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, June 3, 2011 7:47 AM Subject: RE: error-page for http 500 error code does not work From: Kevin Claver [mailto:kcla...@yahoo.com] Subject: Re: error-page for http 500 error code does not work I zipped the tomcat install and deployed it to my Win 7 machine where it works without issue. I'll hazard a guess that you have a case sensitivity issue. Something in your configuration specifies the wrong case for who knows what (perhaps a file name), or a file is installed with the wrong casing. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
error-page for http 500 error code does not work
Issue: Tomcat does not redirect to the HMAExceptionHandlerServlet servlet I have configured in the application specific web.xml when running on Linux I've tried searching all of the lists for an answer to this question. I've seen several postings by people having the same issue, but never a solution. My Tomcat version: Apache Tomcat 5.5.33 (I've also tried 5.5.27 and 6.0.32) running on: Fedora 2.6.27.5-117.fc10.x86_64 Two things I would like to note: 1. When I invoke the Java HMAExceptionHandlerServlet configured to be used in the error-page block in the application specific web.xml directly from the URL in the browser, it works. 2. Tomcat 5.5.33 does correctly redirect to the error-page when running on a Windows 7 machine. The only time I have an issue is on the Linux configuration above. My application specific web.xml (located in tomcat install/webapps/application/WEB-INF folder) : ?xml version=1.0 encoding=UTF-8? web-app version=2.4 xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; context-param param-namejavax.faces.STATE_SAVING_METHOD/param-name param-valueserver/param-value /context-param context-param param-namejavax.faces.CONFIG_FILES/param-name param-value/WEB-INF/navigation.xml,/WEB-INF/managed-beans.xml/param-value /context-param context-param param-namecom.sun.faces.validateXml/param-name param-valuetrue/param-value /context-param context-param param-namecom.sun.faces.verifyObjects/param-name param-valuefalse/param-value /context-param filter filter-nameUploadFilter/filter-name filter-classcom.sun.rave.web.ui.util.UploadFilter/filter-class init-param description The maximum allowed upload size in bytes. If this is set to a negative value, there is no maximum. The default value is 100. /description param-namemaxSize/param-name param-value100/param-value /init-param init-param description The size (in bytes) of an uploaded file which, if it is exceeded, will cause the file to be written directly to disk instead of stored in memory. Files smaller than or equal to this size will be stored in memory. The default value is 4096. /description param-namesizeThreshold/param-name param-value4096/param-value /init-param /filter filter-mapping filter-nameUploadFilter/filter-name servlet-nameFaces Servlet/servlet-name /filter-mapping servlet servlet-nameFaces Servlet/servlet-name servlet-classjavax.faces.webapp.FacesServlet/servlet-class load-on-startup1/load-on-startup /servlet servlet servlet-nameThemeServlet/servlet-name servlet-classcom.sun.rave.web.ui.theme.ThemeServlet/servlet-class /servlet servlet servlet-nameHMAExceptionHandlerServlet/servlet-name servlet-classhmaapp.common.HMAExceptionHandlerServlet/servlet-class /servlet servlet-mapping servlet-nameFaces Servlet/servlet-name url-pattern/faces/*/url-pattern /servlet-mapping servlet-mapping servlet-nameHMAExceptionHandlerServlet/servlet-name url-pattern/error/ExceptionHandler/url-pattern /servlet-mapping servlet-mapping servlet-nameThemeServlet/servlet-name url-pattern/theme/*/url-pattern /servlet-mapping servlet-mapping servlet-nameInterqualJSServlet/servlet-name url-pattern/InterqualJSServlet/url-pattern /servlet-mapping servlet-mapping servlet-nameHMAExceptionHandlerServlet/servlet-name url-pattern/HMAExceptionHandlerServlet/url-pattern /servlet-mapping welcome-file-list welcome-filefaces/SignOn.jsp/welcome-file /welcome-file-list error-page exception-typejavax.servlet.ServletException/exception-type location/error/ExceptionHandler/location /error-page error-page exception-typejava.io.IOException/exception-type location/error/ExceptionHandler/location /error-page error-page exception-typejavax.faces.FacesException/exception-type location/error/ExceptionHandler/location /error-page error-page exception-typecom.sun.rave.web.ui.appbase.ApplicationException/exception-type location/error/ExceptionHandler/location /error-page error-page error-code500/error-code location/error/ExceptionHandler/location /error-page error-page exception-typejava.lang.NullPointerException/exception-type location/error/ExceptionHandler/location /error-page jsp-config jsp-property
Re: Overriding error page displayed when a context fails to initialize
Thanks every one for your useful tips and suggestions. I was able to override the container's default error page using a custom error valve. For any one else that may have a need to do this... The key is to configure your Host element in the config to override the error report valve. This took a while for me to find out, but it is documented in the Tomcat docs (never paid attention, I guess). On the Host element, you can define errorReportValveClass attribute as documented in http://tomcat.apache.org/tomcat-6.0-doc/config/host.html. As far as implementing the custom valve, the easiest is to extend the org.apache.catalina.valves.ErrorReportValve and override the report(...) method to send your own HTML. Sai Pullabhotla On Wed, May 25, 2011 at 5:48 PM, Sai Pullabhotla sai.pullabho...@jmethods.com wrote: I made the context fail by not having the database available. Basically, in the contextInitialized method, we need to load various application settings from the database and if the DB is not up, the context fails to load. The custom error pages are defined in the web.xml for ROOT and context1. All error codes and specific exceptions are forwarded to an ErrorHandlerServlet, which performs additional logging, create custom titles and descriptions based on the error code/exception and then in turn forwards to a JSP which displays the error. I will take a look at the ErrorReportValve and see if I could make use of it. Thanks. Sai Pullabhotla On Wed, May 25, 2011 at 9:04 AM, Pid p...@pidster.com wrote: On 25/05/2011 13:36, Sai Pullabhotla wrote: Thanks for the replies and suggestions. I don't think Tomcat falls back to the ROOT context if another context fails to start (unless I'm missing something). Just to try it out, I did create a subfolder called context1 in ROOT, with an index page in the folder. I made the context1 to fail. The log indicates that context1 failed to startup with the following error. SEVERE: Context [/context1] startup failed due to previous errors How did you make it fail? When I try an URL that starts with /context1, I still get Tomcat's default error page with a status code of 404, not the custom error pages I've in ROOT or the context1. If course, it will never be able to load the custom error pages from context1, it does not fall back to ROOT either. All other URLs (that do not start with /context1) display the custom error pages from the ROOT context. How have you defined the custom error pages? The main reason why we need custom error pages is for security - do NOT display any information about the product that may help a hacker to run sophisticated attacks. I guess, it may not be a bad idea for a product (container) to provide an option to override error pages. @See ErrorReportValve http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/valves/ErrorReportValve.html http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html p - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Overriding error page displayed when a context fails to initialize
Thanks for the replies and suggestions. I don't think Tomcat falls back to the ROOT context if another context fails to start (unless I'm missing something). Just to try it out, I did create a subfolder called context1 in ROOT, with an index page in the folder. I made the context1 to fail. The log indicates that context1 failed to startup with the following error. SEVERE: Context [/context1] startup failed due to previous errors When I try an URL that starts with /context1, I still get Tomcat's default error page with a status code of 404, not the custom error pages I've in ROOT or the context1. If course, it will never be able to load the custom error pages from context1, it does not fall back to ROOT either. All other URLs (that do not start with /context1) display the custom error pages from the ROOT context. The main reason why we need custom error pages is for security - do NOT display any information about the product that may help a hacker to run sophisticated attacks. I guess, it may not be a bad idea for a product (container) to provide an option to override error pages. Sai Pullabhotla On Tue, May 24, 2011 at 1:15 PM, André Warnier a...@ice-sa.com wrote: Caldarale, Charles R wrote: From: Sai Pullabhotla [mailto:sai.pullabho...@jmethods.com] Subject: Re: Overriding error page displayed when a context fails to initialize What I'm looking for is a way to override the error pages of Tomcat at the global level (not application/context specific) There's no such mechanism mostly because the servlet spec doesn't provide for one. The ROOT webapp becomes the catch-all, and you can put filters and generic error pages there. Would the following work, e.g. ? Suppose there are 3 webapps : app1, app2, app3, respectively deployed at (tomcat_dir)/webapps/app1 (tomcat_dir)/webapps/app2 (tomcat_dir)/webapps/app3 plus the default ROOT context deployed at (tomcat_dir)/webapps/ROOT and suppose you created 3 additional directories under webapps/ROOT, respectively (tomcat_dir)/webapps/ROOT/app1 (tomcat_dir)/webapps/ROOT/app2 (tomcat_dir)/webapps/ROOT/app3 The standard Tomcat setup defines, in (tomcat_dir)/conf/web.xml, a welcome file list as follows : welcome-file-list welcome-fileindex.html/welcome-file welcome-fileindex.htm/welcome-file welcome-fileindex.jsp/welcome-file /welcome-file-list So, in each of the above new directories, you deploy a index.jsp page, like (tomcat_dir)/webapps/ROOT/app1/index.jsp (tomcat_dir)/webapps/ROOT/app2/index.jsp (tomcat_dir)/webapps/ROOT/app3/index.jsp , each of these pages displaying a nice message like : Sorry, this xyz application failed to deploy and is not available. Then what would happen is : - if all applications deploy properly, a request for the URL /app1/x would be mapped to the application app1 - if app1 did not deploy properly, a request for the URL /app1 would end up being mapped to the default ROOT application and its sub-directory /ROOT/app1, thus returning the welcome page (tomcat_dir)/webapps/ROOT/app1/index.jsp, and the message. No ? (The above was for the basic principle, but I suppose one could optimise this, to avoid having to create these sub-directories and duplicating those error pages, by mapping these things more cleverly in ROOT's web.xml.) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Overriding error page displayed when a context fails to initialize
On 25/05/2011 13:36, Sai Pullabhotla wrote: Thanks for the replies and suggestions. I don't think Tomcat falls back to the ROOT context if another context fails to start (unless I'm missing something). Just to try it out, I did create a subfolder called context1 in ROOT, with an index page in the folder. I made the context1 to fail. The log indicates that context1 failed to startup with the following error. SEVERE: Context [/context1] startup failed due to previous errors How did you make it fail? When I try an URL that starts with /context1, I still get Tomcat's default error page with a status code of 404, not the custom error pages I've in ROOT or the context1. If course, it will never be able to load the custom error pages from context1, it does not fall back to ROOT either. All other URLs (that do not start with /context1) display the custom error pages from the ROOT context. How have you defined the custom error pages? The main reason why we need custom error pages is for security - do NOT display any information about the product that may help a hacker to run sophisticated attacks. I guess, it may not be a bad idea for a product (container) to provide an option to override error pages. @See ErrorReportValve http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/valves/ErrorReportValve.html http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html p signature.asc Description: OpenPGP digital signature
