Re: 400 Bad Request - where do I find the detailed reason for the bad request so I can fix it?

[Graham Leggett]

On 28 Nov 2023, at 21:10, Graham Leggett  wrote:

> So the reason we get a 400 Bad Request with no error detail is that we arrive 
> at this line with throwable set to null:
> 
> https://github.com/apache/tomcat/blob/9.0.x/java/org/apache/catalina/valves/ErrorReportValve.java#L129
> 
> With no throwable we are eventually led here, which is our generic “an error 
> has occurred, not telling you what it is” page:
> 
> https://github.com/apache/tomcat/blob/9.0.x/java/org/apache/catalina/valves/ErrorReportValve.java#L169

I think I've figured out what is happening, I've not yet figured out why it is 
happening, but we’ve got further.

In my case, a jersey-client v3 API is generating a big non-pretty blob of XML 
on one line (no newlines), and is passing this in a POST request to tomcat9 
listening on a unix domain socket.

If I hijack the unix domain socket with socat, I only see 4096-ish bytes being 
received of a body of size approx 1/4MB (from Content-Length, not chunked). 
This looks suspiciously like the size of one write. Why that’s happening is a 
jersey-client question.

In tomcat9 however, it appears that tomcat is seeing 4096-ish bytes, a closed 
and truncated connection (we have a Content-Length so tomcat9 knows it’s 
truncated), tomcat9 is correctly picking up the request body is too small, and 
is correctly returning 400 Bad Request, but there is no exception or detail 
string, so the admin has no idea this is what’s wrong.

Regards,
Graham
—


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: 400 Bad Request - where do I find the detailed reason for the bad request so I can fix it?

[Graham Leggett]

On 29 Nov 2023, at 07:18, Thomas Hoffmann (Speed4Trade GmbH) 
 wrote:

>> I’m in dependency hell - java8 to java17, JAXB as used by Jersey2 broke. No
>> idea why, but an internal Oracle implementation is hardcoded somewhere.
>> 
>> java.lang.ClassNotFoundException: oracle.xml.jaxp.JXSAXParserFactory
> 
> I think you got trapped in the javax-jakarta hell after upgrading.
> As a general recommendation, you should upgrade all libraries in your app.
> Mostly all new versions have switched to using Jakarta.

I have indeed.

I have learned that tomca9 (which I’m stuck on) requires jersey2 (fair enough), 
which in turn requires a lot of code in the javax namespace that is packaged in 
jars in the jakarta namespace.

> Do you use and build system like gradle or maven? 
> They should take care of the new dependencies. Otherwise you have to look it 
> up.
> 
> If some libraries don’t support Jakarta package yet, you have to add the 
> legacy jaxb libs:
> https://mvnrepository.com/artifact/com.sun.xml.bind/jaxb-impl

Maven is being used, but many of the dependencies are optional, and it is not 
clear which versions are required (the latest jakarta versions are too new). 
The advice that I was given was to use the exact same pinned versions of 
everything used by the particular jersey release:

https://github.com/eclipse-ee4j/jersey/blob/2.x/pom.xml#L2313

Regards,
Graham
—

Re: 400 Bad Request - where do I find the detailed reason for the bad request so I can fix it?

[Graham Leggett]

On 28 Nov 2023, at 19:11, Graham Leggett  wrote:

>> In your debugger, when you break-on-exception, what happens if you allow the 
>> exception to propagate up to the first exception-handler? Does Tomcat 
>> swallow the exception? Or it it caught elsewhere?
> 
> The exception eventually ends up inside ErrorReportValve, but I’m debugging a 
> remote box and don’t have any of the source code tied up - will do further 
> digging.

So the reason we get a 400 Bad Request with no error detail is that we arrive 
at this line with throwable set to null:

https://github.com/apache/tomcat/blob/9.0.x/java/org/apache/catalina/valves/ErrorReportValve.java#L129

With no throwable we are eventually led here, which is our generic “an error 
has occurred, not telling you what it is” page:

https://github.com/apache/tomcat/blob/9.0.x/java/org/apache/catalina/valves/ErrorReportValve.java#L169

Regards,
Graham
—

Re: 400 Bad Request - where do I find the detailed reason for the bad request so I can fix it?

[Graham Leggett]

On 28 Nov 2023, at 18:42, Christopher Schultz  
wrote:

> In your debugger, when you break-on-exception, what happens if you allow the 
> exception to propagate up to the first exception-handler? Does Tomcat swallow 
> the exception? Or it it caught elsewhere?

The exception eventually ends up inside ErrorReportValve, but I’m debugging a 
remote box and don’t have any of the source code tied up - will do further 
digging.

> When you say you have an "unmarshalling problem"... do you mean in your own 
> application? Or something in Tomcat? (I can't think of anything in Tomcat 
> we'd call "unmarshalling", but I figure I'd ask.)

I’m in dependency hell - java8 to java17, JAXB as used by Jersey2 broke. No 
idea why, but an internal Oracle implementation is hardcoded somewhere.

java.lang.ClassNotFoundException: oracle.xml.jaxp.JXSAXParserFactory

Regards,
Graham
—

Re: 400 Bad Request - where do I find the detailed reason for the bad request so I can fix it?

[Graham Leggett]

On 28 Nov 2023, at 09:41, Mark Thomas  wrote:

>> What do I need to do to see the exception that generated the bad request, so 
>> that I know specifically what’s wrong and can fix it?
> 
> Enabling debug logging for
> 
> org.apache.coyote.http11.Http11Processor may help.
> 
> It is probably the tightening up of the HTTP parsing that is triggering the 
> 400 response.

I eventually attached a remote debugger and stopped on all exceptions to get 
it. A problem with unmarshalling was being triggered then replaced with a 
generic 400. We’re now stuck on another bug, same symprom, this time a 500 with 
no exception.

What I’m finding is that the following valve on v9.0.65 has no effect:



Instead of rendering the exception in the output, we get the following:

HTTP Status 500 – Internal Server 
Errorbody {font-family:Tahoma,Arial,sans-serif;} 
h1, h2, h3, b {color:white;background-color:#525D76;} h1 {font-size:22px;} h2 
{font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a {color:black;} 
.line 
{height:1px;background-color:#525D76;border:none;}HTTP 
Status 500 – Internal Server ErrorType Status 
ReportMessage Internal Server ErrorDescription The 
server encountered an unexpected condition that prevented it from fulfilling 
the request.Apache Tomcat/9.0.65

Is this a known problem?

Regards,
Graham
—

400 Bad Request - where do I find the detailed reason for the bad request so I can fix it?

[Graham Leggett]

Hi all,

Long running webapps, tomcat recently updated from tomcat7 to tomcat v9.0.65. 
One webapp sends a request to another.

The request fails with a 400 Bad Request, with the detail message "The server 
cannot or will not process the request due to something that is perceived to be 
a client error (e.g., malformed request syntax, invalid request message 
framing, or deceptive request routing).”

I am aware what a 400 bad request is, however the message above gives me an 
incomplete list of possible reasons for the bad request, rather than the actual 
specific reason for this specific bad request. Google is filled with generic 
results, and is of no help.

What do I need to do to see the exception that generated the bad request, so 
that I know specifically what’s wrong and can fix it?

Regards,
Graham
—


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat9 silently ignores web application

[Graham Leggett]

On 08 Jul 2023, at 11:20, Graham Leggett  wrote:

> In summary, the client hits tomcat, tomcat returns 404 on the request, and 
> there is no trace in the access logfile that the client was ever there.

I've traced it to one level up - there is an httpd above this that was routing 
requests destined to this application to a second independent tomcat running on 
the same machine. This second tomcat was (correctly) returning 404.

When the logfile says no hits coming in, it means the hits are going somewhere 
else.

Now to pull apart httpd...

Regards,
Graham
—


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat9 silently ignores web application

[Graham Leggett]

On 08 Jul 2023, at 10:08, Graham Leggett  wrote:

> Another data point - when starting the application up under tomcat9 in 
> eclipse, there is also no mention in the logs of the web application having 
> been deployed, however I am able to hit the application with curl and receive 
> a sensible result. The application has been silently started.
> 
> On the target machine, we get no log line same as under eclipse, and no 
> application (404 Not Found). The application might have been silently started 
> at a different URL and with no log line we’ll never know, or it silently 
> failed to start and with no error we’ll never know.

Having switched from declaring a context in server.xml to Catalina/localhost we 
now get the startup line - it seems that applications defined in server.xml are 
silently deployed, but the behaviour hasn’t changed, we still get 404 on the 
application.

08-Jul-2023 11:59:59.016 INFO [main] 
org.apache.catalina.startup.HostConfig.deployDescriptor Deployment of 
deployment descriptor 
[/var/lib/tomcats/xxx-service-test/conf/Catalina/localhost/xxx-service-test.xml]
 has finished in [5,334] ms

A further data point - the access_log as defined by default under the Host is 
created but stays empty:

  







  

In summary, the client hits tomcat, tomcat returns 404 on the request, and 
there is no trace in the access logfile that the client was ever there.

Anyone seen behaviour like this before?

Regards,
Graham
—

Re: Tomcat9 silently ignores web application

[Graham Leggett]

On 07 Jul 2023, at 23:23, Graham Leggett  wrote:

>> When you start Tomcat, do you get a message about /foo/bar being 
>> deployed in catalina.out? For example, I get this for every deployment:
>> 
>> Jul 06, 2023 4:09:33 PM org.apache.catalina.startup.HostConfig 
>> deployDirectory
>> INFO: Deploying web application directory [/full/path/to/web/application]
>> Jul 06, 2023 4:09:39 PM org.apache.catalina.startup.HostConfig 
>> deployDirectory
>> INFO: Deployment of web application directory 
>> [/full/path/to/web/application] has finished in [6,007] ms
> 
> In tomcat7 I see that line logged, in tomcat9 I do not.

Another data point - when starting the application up under tomcat9 in eclipse, 
there is also no mention in the logs of the web application having been 
deployed, however I am able to hit the application with curl and receive a 
sensible result. The application has been silently started.

On the target machine, we get no log line same as under eclipse, and no 
application (404 Not Found). The application might have been silently started 
at a different URL and with no log line we’ll never know, or it silently failed 
to start and with no error we’ll never know.

In the absence of both an error message, and confirmation of web application 
deployment, we’re flying blind.

Digging into the source, we find three similar strings to say we’re finished 
deploying a web application. Setting a breakpoint on all three, none of them 
are hit (or I’m using jdb wrong):

main[1] stop
No breakpoints set.
main[1] stop in org.apache.catalina.startup.HostConfig.deployDirectory
Deferring breakpoint org.apache.catalina.startup.HostConfig.deployDirectory.
It will be set after the class is loaded.
main[1] stop in org.apache.catalina.startup.HostConfig.deployDescriptor
Deferring breakpoint org.apache.catalina.startup.HostConfig.deployDescriptor.
It will be set after the class is loaded.
main[1] stop in org.apache.catalina.startup.HostConfig.deployWAR
Deferring breakpoint org.apache.catalina.startup.HostConfig.deployWAR.
It will be set after the class is loaded.
main[1] resume
All threads resumed.
> Set deferred breakpoint org.apache.catalina.startup.HostConfig.deployWAR
Set deferred breakpoint org.apache.catalina.startup.HostConfig.deployDescriptor
Set deferred breakpoint org.apache.catalina.startup.HostConfig.deployDirectory

> 

Regards,
Graham
—

Re: Tomcat9 silently ignores web application

[Graham Leggett]

On 2023/07/07 13:44:07 Christopher Schultz wrote:

> When you start Tomcat, do you get a message about /foo/bar being 
> deployed in catalina.out? For example, I get this for every deployment:
> 
> Jul 06, 2023 4:09:33 PM org.apache.catalina.startup.HostConfig 
> deployDirectory
> INFO: Deploying web application directory [/full/path/to/web/application]
> Jul 06, 2023 4:09:39 PM org.apache.catalina.startup.HostConfig 
> deployDirectory
> INFO: Deployment of web application directory 
> [/full/path/to/web/application] has finished in [6,007] ms

In tomcat7 I see that line logged, in tomcat9 I do not.

> Are you seeing that, and does it include (a) the expected path to your 
> application and (b) no errors indicating that deployment has failed?

There are no errors indicating that deployment has failed. In addition, there 
are many expected loglines showing that the application has been initialised 
(various application specific lines that I expect to see).

In short:

- the application is going through all the motions of being deployed 
successfully.
- no log line appears to say the application was deployed at the expected path.
- all URLs return 404 with no error.

It is failing silently at some point.

Regards,
Graham
—


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Tomcat links application at the root of the server?

[Graham Leggett]

Hi all,

Is there is application out there that will provide, at / (or a path of your 
choosing), a list of links of applications currently deployed and running under 
tomcat?

Ideally I want tomcat to tell me what applications have been deployed and if 
they have been deployed successfully, preferably by pointing curl and the root 
of the server and going “what’s here and how do I get there”.

(This is a wildly different question to “what do I think is here and how do I 
think I get there”)

Regards,
Graham
—


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat9 silently ignores web application

[Graham Leggett]

Hi,

> 1. Please read
> https://tomcat.apache.org/tomcat-9.0-doc/config/context.html#Defining_a_context
>  
> 
> 
> You are injecting a Context into a Host at the time when the
> server.xml file is parsed. It does not go through the proper
> "deployment" processing at start time.

I understand the different places that tomcat looks for contexts, I don’t 
understand “It does not go through the proper “deployment” processing at start 
time”. Can you clarify?

> 2. What result did you expect?

What I have is a context that is tightly bound to the tomcat that contains it. 
The whole tomcat generated is autogenerated, so creating lots of little files 
and somehow mapping their filenames safely on the filesystem is complexity I 
would rather avoid. One single server.xml is perfect in this case.

Where I am getting stuck is that tomcat is being coy with the deployment - I 
see tomcat complain loudly if you point at an appBase that doesn’t exist, but 
you change it to an appBase that does exist and tomcat starts fine, says 
nothing, and every URL returns a 404. Something has gone wrong somewhere, but 
without being given a clue as to what it is, I’m stuck.

Regards,
Graham
—

Tomcat9 silently ignores web application

[Graham Leggett]

Hi all,

I have for a while now been moving various web applications onto a new machine 
running tomcat9, and things have been working great. I have suddenly reached 
one web application which is silently ignored.

Tomcat starts up without any error, makes no mention of the webapp. If the 
webapp points to a bogus directory, tomcat complains very loudly, point tomcat 
to the correct directory, tomcat ignores the webapp.

Any attempt to hit the webapp returns the dreaded tomcat 404 page. 
Interestingly hitting /foo/bar returns a redirect to /foo/bar/ (as you would 
expect it to), but /foo/bar/ returns a tomcat 404.

The webapp is not being newly developed, and works fine on tomcat7 on the old 
machine.

Is there anything that can be done to coax an error message or any message out 
of tomcat when it fails to deploy something?

Snip of server.xml looks like this:

  










  

Regards,
Graham
—


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Need help understanding support for Unix Domain Sockets in Tomcat 7.0.x

[Graham Leggett]

On 25 Sep 2015, at 10:33 PM, Christopher Schultz  
wrote:

> While I obviously agree with the sentiment, I do feel bad for the OP
> who has to fight this battle.

It is important however to clarify that this isn’t a typical scenario, lest 
someone cites this thread as to why they should be doing the same thing.

> 1. All the code we currently have in tcnative uses APR for everything,
> and I'm not sure if APR supports AF_UNIX sockets, or even if it would
> have to support them to do this.

The as-yet-unreleased v1.6 of APR does support unix domain sockets, although 
the docs for it don’t appear to be very clear.

> 2. The plumbing required to configure an AF_UNIX socket is
> non-trivial, and it's currently all wired-around using AF_INET
> sockets, so it's got hostname, port, etc. I suppose we could stuff the
> inode's name into the hostname and ignore the port number or something
> like that, but it's fairly hacky.

Currently APR seems to accept the UDS filename where the IP address would 
otherwise be provided.

> So this is a non-trivial amount of work, here.
> 
> Srini, is there any chance your employer would pay someone to write
> this code? Patches are always welcome, and Tomcat is otherwise
> completely free…

If there was a push for unix domain sockets from Tomcat it would definitely 
help working out whether the APR_UNIX implementation does what it needs to do, 
and gets properly documented and v1.6 released.

Regards,
Graham
—


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Need help understanding support for Unix Domain Sockets in Tomcat 7.0.x

[Graham Leggett]

On 23 Sep 2015, at 22:05, André Warnier (tomcat)  wrote:

> - you convince whoever wrote that requirement, that an internal TCP 
> connection within the same host, is no less secure than a Unix Domain socket

+1.

Regards,
Graham
--


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Need help understanding support for Unix Domain Sockets in Tomcat 7.0.x

[Graham Leggett]

On 23 Sep 2015, at 5:55 PM, Srinivasan Raman  wrote:

> Sorry, I should have provided more details while posting the query.
> Due to a security policy that mandates that a certain type of sensitive data 
> flowing over a communication channel must be encrypted, we are using SSL. If 
> the communication channel were to be Unix Domain sockets, we do not need to 
> encrypt the data, based on the data classification for this use-case.

Would it be possible to confirm the need for encrypting traffic over localhost?

Regards,
Graham
—


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: java.lang.NullPointerException at org.apache.jasper.JspCompilationContext.getTldResourcePath(JspCompilationContext.java:536) when starting Embedded Tomcat Instance

[Graham Leggett]

On 16 Mar 2015, at 11:48 AM, Thusitha Thilina Dayaratne thusit...@wso2.com 
wrote:

 ERROR {org.apache.catalina.core.ApplicationDispatcher} -
 Servlet.service() for servlet bridgeservlet threw exception
 java.lang.NullPointerException
 at
 
 org.apache.jasper.JspCompilationContext.getTldResourcePath(JspCompilationContext.java:536)
 at
 org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:410)
 at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:469)
 at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1430)
 at org.apache.jasper.compiler.Parser.parse(Parser.java:139)
 
 snip/
 
 I can't figure out the reason to get this NullPointerException.
 Can someone help me out?
 
 If we knew which version of Tomcat 8 you were using, someone could look
 at the relevant source code to try to figure out what was going on.
 I'm using tomcat version *8.0.20*

Browse to the sourcecode of v8.0.20 of tomcat here:

https://svn.apache.org/viewvc/tomcat/tc8.0.x/tags/TOMCAT_8_0_20/java/org/apache/jasper/JspCompilationContext.java?view=markup

The lines you want look like this:

535 public TldResourcePath getTldResourcePath(String uri) {
536 return getOptions().getTldCache().getTldResourcePath(uri); 
537 }

Obviously either getOptions() or getTldCache() is returning null.

Reverse engineer the source to find out which, or stop the code in a debugger.

Regards,
Graham
—


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat7: debugging realms - a howto?

[Graham Leggett]

On 14 Mar 2015, at 3:43 PM, Graham Leggett minf...@sharp.fm wrote:

 Changing the auth-type to CLIENT-CERT shows that the username has been 
 replaced by the subject-DN of the cert, which is progress.

Reverse engineering tomcat showed that the tomcatAuthentication parameter 
solved half the problem - when the webserver provided REMOTE_USER, this was 
used as the principal in the request, but as a side effect the role lookup was 
bypassed, and any web application using roles stopped working.

The attached patches for tomcat v7.0.x, tomcat v8.0.x and tomcat 9.0.x 
introduce the tomcatAuthorization flag:

https://bz.apache.org/bugzilla/show_bug.cgi?id=57708

The tomcatAuthorization flag, when true, takes the REMOTE_USER from the 
webserver, but ensures that all the role lookups occur as normal.

This means you can drop in a webserver in front of a tomcat hosted web 
application, and automatically the authn of the webserver will replace the 
authn in the web application, leaving the authz intact and working.

This solves my problem.

Regards,
Graham
—


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat7: debugging realms - a howto?

[Graham Leggett]

On 14 Mar 2015, at 1:04 AM, Konstantin Kolinko knst.koli...@gmail.com wrote:

 You are using JRE's default java.util.logging.LogManager.
 
 You need to configure JRE to use the Tomcat JULI implementation of log
 manager with
 -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
 
 The JRE class is usable, but its logging.properties format is a bit different.

Adding the above to Eclipse’s launcher configuration brought sanity back to the 
logging.

What this revealed was that no realm decisions were being made - we weren’t 
getting that far.

Placing a watchpoint on the “status” variable in the response revealed the 
point at which we were getting the 403.

In my case switching from basic auth to cert meant changing the tomcat protocol 
from HTTP to AJP, and this in turn caused a 
org.apache.catalina.valves.RemoteAddrValve configuration to kick in, which now 
no longer pointed at localhost (address of Apache proxy) but rather the browser 
IP, thanks to AJP:

Valve className=org.apache.catalina.valves.RemoteAddrValve
allow=127.0.0.1”/

Stepping through the org.apache.catalina.valves.RemoteAddrValve implementation 
in the debugger showed that when it returned the 403, it logged nothing in the 
log, and it returned no explanatory message in the response. Ideally this needs 
to be fixed: https://bz.apache.org/bugzilla/show_bug.cgi?id=57705

Now I get the basic authentication to hit as normal.

Changing the auth-type to CLIENT-CERT shows that the username has been replaced 
by the subject-DN of the cert, which is progress.

Regards,
Graham
—


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Getting tomcat to honour REMOTE_USER as provided via mod_proxy_ajp

[Graham Leggett]

Hi all,

I have reached the point where with an auth-method of CLIENT-CERT is returning 
the Subject DN of the certificate as the username.

What I need to achieve is for tomcat to honour the REMOTE_USER environment 
variable as set by Apache httpd. I have noticed the tomcatAuthentication flag 
can be used to ask tomcat to respect the authentication decision provided by 
Apache httpd, but breakpoints set at the point where we check for these values 
in AbstractAjpProcessor never fire.

Is this possible?

Regards,
Graham
—


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Getting tomcat to honour REMOTE_USER as provided via mod_proxy_ajp

[Graham Leggett]

On 14 Mar 2015, at 4:15 PM, Graham Leggett minf...@sharp.fm wrote:

 I have reached the point where with an auth-method of CLIENT-CERT is 
 returning the Subject DN of the certificate as the username.
 
 What I need to achieve is for tomcat to honour the REMOTE_USER environment 
 variable as set by Apache httpd. I have noticed the tomcatAuthentication flag 
 can be used to ask tomcat to respect the authentication decision provided by 
 Apache httpd, but breakpoints set at the point where we check for these 
 values in AbstractAjpProcessor never fire.
 
 Is this possible?

I discovered that the piece of the Apache config that was enforcing the cert 
auth had been temporarily disabled. Enabling that brought me to the next wall.

When tomcat passes through httpd's version of REMOTE_USER, tomcat places the 
resulting effective userid in a CoyotePrincipal object.

When the realms are being parsed, the DataSourceRealm falls back to the 
RealmBase version of hasRole(), which denies access (again, silently with no 
log message or explanation) because the principal object is not a 
GeneralPrincipal.

if ((principal == null) || (role == null) ||
!(principal instanceof GenericPrincipal))
// BOOM - we fail here and silently return false
return (false);

GenericPrincipal gp = (GenericPrincipal) principal;
boolean result = gp.hasRole(role);
if (log.isDebugEnabled()) {
String name = principal.getName();
if (result)
log.debug(sm.getString(realmBase.hasRoleSuccess, name, role));
else
log.debug(sm.getString(realmBase.hasRoleFailure, name, role));
}

Looking at CoyotePrincipal, this represents a simple username only. In 
contrast, GenericPrincipal represents a username/password/list-of-roles triple.

I need to dig further, but it seems that the tomcatAuthentication option 
silently disables authorization in the process.

Regards,
Graham
—


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Tomcat7: debugging realms - a howto?

[Graham Leggett]

Hi all,

I have a working realm installation using basic authentication, which I need to 
switch to client certificate authentication. Having done so it doesn’t work, I 
just get “forbidden”, with no indication of the error involved.

Back in the day there was a simple “debug” flag that turned on debugging. That 
seems to have been replaced with the significantly more complicated 
java.util.logging implementation, based on adding a logging.properties file. 
Adding this file, along with suggested entries to debug realms has had no 
effect, I can still see nothing in console.out.

Can anyone point at a simple, clear and unambiguous set of instructions that 
indicate how to debug a realm configuration?

I have tomcat up and running in a debugger, if the realm logging is broken is 
there a suggested point in the code I should be placing a breakpoint so I can 
step through this?

Regards,
Graham
—


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Switching basic auth to client-cert with realms - how?

[Graham Leggett]

On 13 Mar 2015, at 10:34 PM, Neven Cvetkovic neven.cvetko...@gmail.com wrote:

 What doesn’t seem to fit is the realm definition - specifying userCredCol
 is marked as mandatory, but this is obviously not present with a client
 certificate. What do you specify in this field?
 
 
 You define the password column, which could have NULL values now, since we
 don't use passwords anymore.

I don’t follow, do you mean I shouldn’t define the password column?

 Here's another interesting article that tackles the old version of Tomcat,
 but the ideas are very similar. Here's a link:
 http://stackoverflow.com/questions/163113/can-client-cert-auth-method-be-used-with-a-jdbc-realm-within-tomcat

I’ve already found all of these, and have trawled through them to no avail. It 
appears all the information is stale.

I am currently stuck on two specific areas:

- None of the debug logging seems to work any more in any kind of predictable 
fashion, as detailed in my other message.
- Turning on SQL statement logging in postgres shows that at no point is any 
SQL statement executed against the database.

If I had some kind of meaningful error that accompanied the 403 it would be a 
huge help.

Is anyone able to confirm where I might place a breakpoint to step through the 
tomcat code?

Regards,
Graham
—


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat7: debugging realms - a howto?

[Graham Leggett]

On 13 Mar 2015, at 9:58 PM, Neven Cvetkovic neven.cvetko...@gmail.com wrote:

 Just to confirm, the 403 Forbidden page was rendered by Tomcat, not Apache
 HTTPD?

Yes, it is branded tomcat and appears in the tomcat access log.

 I don't expect it is an Apache issue here - because you mentioned your
 application worked before - I assume with the same URL, and no updates to
 Apache HTTPD configuration.
 
 Next thing I would probably increase the verbosity of the Realm logging, by
 updating your conf/logging.properties, e.g.
 org.apache.catalina.realm.level = ALL
 org.apache.catalina.realm.useParentHandlers = true
 org.apache.catalina.authenticator.level = ALL
 org.apache.catalina.authenticator.useParentHandlers = true
 
 
 You might want to disable buffering as well, e.g.
 1catalina.org.apache.juli.FileHandler.bufferSize = -1

None of these changes to logging.properties have any effect on my test system 
of tomcat v7.0.59 deployed to RHEL6. I get no changes to catalina.out at all, 
it stays completely silent.

I tried to make the same changes to a tomcat v7.0.59 running within Eclipse, 
and in this case I get the following:

Can't load log handler 2localhost.org.apache.juli.FileHandler
java.lang.ClassNotFoundException: 2localhost.org.apache.juli.FileHandler
java.lang.ClassNotFoundException: 2localhost.org.apache.juli.FileHandler
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
at java.util.logging.LogManager$3.run(LogManager.java:418)
at java.security.AccessController.doPrivileged(Native Method)
at java.util.logging.LogManager.loadLoggerHandlers(LogManager.java:405)
at java.util.logging.LogManager.addLogger(LogManager.java:609)
at java.util.logging.LogManager.demandLogger(LogManager.java:355)
at java.util.logging.Logger.getLogger(Logger.java:328)
at org.apache.juli.logging.DirectJDKLog.init(DirectJDKLog.java:71)
at 
org.apache.juli.logging.DirectJDKLog.getInstance(DirectJDKLog.java:196)
at org.apache.juli.logging.LogFactory.getInstance(LogFactory.java:170)
at org.apache.juli.logging.LogFactory.getLog(LogFactory.java:311)
at 
org.apache.catalina.core.ContainerBase.getLogger(ContainerBase.java:452)
at 
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1102)
at 
org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:816)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at 
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1575)
at 
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1565)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)

Further on, the following is logged, which suggests that there is no roles 
defined at all:

Mar 13, 2015 10:13:12 PM org.apache.catalina.authenticator.AuthenticatorBase 
invoke
FINE: Security checking request GET /
Mar 13, 2015 10:13:12 PM org.apache.catalina.authenticator.AuthenticatorBase 
invoke
FINE: Security checking request GET /
Mar 13, 2015 10:13:12 PM org.apache.catalina.realm.RealmBase 
findSecurityConstraints
FINE:   No applicable constraints defined
Mar 13, 2015 10:13:12 PM org.apache.catalina.realm.RealmBase 
findSecurityConstraints
FINE:   No applicable constraints defined
Mar 13, 2015 10:13:12 PM org.apache.catalina.authenticator.AuthenticatorBase 
invoke
FINE:  Not subject to any constraint
Mar 13, 2015 10:13:12 PM org.apache.catalina.authenticator.AuthenticatorBase 
invoke
FINE:  Not subject to any constraint

None of this is making any sense. Is there no simply way of switching on realm 
debugging as we used to with the “debug” attribute?

Regards,
Graham
—


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Switching basic auth to client-cert with realms - how?

[Graham Leggett]

Hi all,

I have a basic authentication setup that works great as below.

login-config
auth-methodBASIC/auth-method
realm-namePatricia/realm-name
/login-config

!-- Security roles referenced by this web application --
security-role
role-nameadministrator/role-name
/security-role
security-role
role-nameunderwriter/role-name
/security-role
security-role
role-nameaccountant/role-name
/security-role
security-role
role-namebroker/role-name
/security-role
security-role
role-namefeeds/role-name
/security-role

It is backed up with a realm like this:

  Realm className=“org.apache.catalina.realm.DataSourceRealm
 [snip]
 userTable=person userNameCol=mail
 userCredCol=user_password
 userRoleTable=company_person roleNameCol=serial /

I need to switch basic authentication to client certificates, as provided by 
Apache httpd and proxied in with AJP. The username is provided by Apache httpd 
in REMOTE_USER.

In theory, changing the auth-method to CLIENT-CERT should do the trick, but I 
just get forbidden.

What doesn’t seem to fit is the realm definition - specifying userCredCol is 
marked as mandatory, but this is obviously not present with a client 
certificate. What do you specify in this field?

Does anyone have a working example of authentication using client certificates 
and authorization using a realm backed with a DataSource?

Regards,
Graham
—


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Apache and Tomcat

[Graham Leggett]

On Mon, April 10, 2006 9:59 am, Franck Borel said:

 The Apache Web Server and mod_jk are written in C++

Small detail, they are both written in C.

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat 5.5 and Logging - any plain english instructions anywhere?

[Graham Leggett]

Larry Isaacs wrote:


You could try modifying common/classes/logging.properties to see
if you can increase the output.


Tomcat doesn't ship with such a config file, but it gives a sample one 
in the logging docs. Having tried to do some semi intelligent cut and 
pasting to create a logging config for my webapp, I now have a zero 
length logfile.


I have listed logging.properties below, can anybody see anything wrong 
with it?



 I haven't worked with Struts
enough to say what logging output you should expect.  If no luck,
then there's always Google. :)


This is one of those Google searches that falls into the all questions 
no answers category, it was the first thing I tried :(


Here is logging.properties:

handlers = 1catalina.org.apache.juli.FileHandler, 
2localhost.org.apache.juli.FileHandler, \
   3manager.org.apache.juli.FileHandler, 
4admin.org.apache.juli.FileHandler, \
   5rfs.org.apache.juli.FileHandler, 
java.util.logging.ConsoleHandler


.handlers = 1catalina.org.apache.juli.FileHandler, 
java.util.logging.ConsoleHandler



# Handler specific properties.
# Describes specific configuration info for Handlers.


1catalina.org.apache.juli.FileHandler.level = FINE
1catalina.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
1catalina.org.apache.juli.FileHandler.prefix = catalina.

2localhost.org.apache.juli.FileHandler.level = FINE
2localhost.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
2localhost.org.apache.juli.FileHandler.prefix = localhost.

3manager.org.apache.juli.FileHandler.level = FINE
3manager.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
3manager.org.apache.juli.FileHandler.prefix = manager.

4admin.org.apache.juli.FileHandler.level = FINE
4admin.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
4admin.org.apache.juli.FileHandler.prefix = admin.

5rfs.org.apache.juli.FileHandler.level = FINE
5rfs.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
5rfs.org.apache.juli.FileHandler.prefix = rfs.

java.util.logging.ConsoleHandler.level = FINE
java.util.logging.ConsoleHandler.formatter = 
java.util.logging.SimpleFormatter




# Facility specific properties.
# Provides extra control for each logger.


org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].handlers = \
   2localhost.org.apache.juli.FileHandler

org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].level 
= INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].handlers 
= \

   3manager.org.apache.juli.FileHandler

org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/admin].level 
= INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/admin].handlers 
= \

   4admin.org.apache.juli.FileHandler

org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/rfs].level 
= FINE
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/rfs].handlers 
= \

   5rfs.org.apache.juli.FileHandler

# For example, set the com.xyz.foo logger to only log SEVERE
# messages:
#org.apache.catalina.startup.ContextConfig.level = FINE
#org.apache.catalina.startup.HostConfig.level = FINE
#org.apache.catalina.session.ManagerBase.level = FINE

Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature