Manager App no longer working after context.xml changes

[Alan Davenport]

All,

I am having a peculiar issue with a Tomcat instance.

In trying to lock the manager app access down to only 'localhost' access, I have somehow caused the manager app no longer to work. Originally it was installed as part of a JasperReports install and all defaults were accepted. The application worked 'out of the box'.

I will try and repeat the steps to see if anyone can think of what I can check:

1. I renamed the ROOT directory to ROOT_secure so that the default Tomcat page no longer shows up when users hit the base URL
2. Inside the META-INF folder for host-manager (under WebApps) I uncommented out the <Valve> entry that limits access to only 'localhost' use
3. Inside the META-INF folder for manager (under WebApps) I I uncommented out the <Valve> entry that limits access to only 'localhost' use
4. I have restarted the server and Tomcat service several timse.

One additional step I did prior to uncommenting out the <Valve> entry was I created a custom context.html in the apache-tomcat\conf\Catalina\localhost folder with basically the same <Valve> entry as is in the previously mentioned entries. I have since removed this file from that folder.

Symptoms ... when trying to access url/manager/html externally I get a Https Status 403 'Access to the specified resource has been forbidden' message. When trying to launch the url/manager/html web page internally, i get HTTP status 404 'The requested resource is not available'.

So, somehow in my steps taken prior to modifying the context.xml file in the META-INF folder I damaged the app. The manager.2015-x-x.log file is empty and I am not sure where else to look.

Reinstalling Tomcat is not an option at this time as it would require a complete reconfiguration of the Jasper Reports mechanism.

Can anyone think of what I may have inadvertently done while making these config changes? THANK YOU!

[Tim Holloway]

Welcome to the JavaRanch, Alan!

Actually, I usually don't use the Tomcat admin webapps myself. But for a production box, Tomcat is typically being fronted by an HTTP reverse proxy, so I don't block IPs within Tomcat, I block them at the firewall. Since NO webapp is allotted direct external access on my servers, whether admin or not. You have to go through the proxy, which is where I do my fine-grained control.

If you have damaged your admin webapps, the easiest way to recover them is to obtain a duplicate copy of the Tomcat server, shut down the live one, delete the host-manager and manager directories from TOMCAT_HOME/webapps (NOTE: Java is CASE-SENSITIVE, so I hope you're not really spelling it WebApps!). Then copy the host-manager and manager directories from the duplicate Tomcat's webapps directories into TOMCAT_HOME/webapps/. That should set you back to factory defaults, assuming that you haven't mucked around with TOMCAT_HOME/conf/server.xml. And, of course, your actual access to these apps does depend on having enabled the security Realm for them and having added appropriate userid/password and roles to TOMCAT_HOME/conf/tomcat-users.xml.

[Alan Davenport]

Tim,

Thanks for your quick response. Launching another server beside it sounds like a good idea.

I do have one question though ... I haven't built the tomcat-users file just yet (other than default) but would that cause the 'resource not available' message? Usually I would still get the authentication pop up, with the 403 message page to follow with the instructions on how to configure the tomcat-users.xml file.

And, on the server.xml file, the only things I have changed was an added entry for connector port = 443 for our custom certificate. I have also commented out and uncommented out the entry for 8080 to disable non-secure access. Either way, I still have the same issue.

[Tim Holloway]

Tomcat implements the J2EE Container-Managed security standard using plug-in modules called "Realms". The default configuration in server.xml is to use a MemoryRealm, which uses the tomcat-users.xml file as its "database". Any realm will do, including LDAP/ActiveDirectory, JDBC and many more, but that one requires no external resources, so it's a simple way to get started. And actually, although it's the "default" Realm in server.xml, the real default is no Realm at all, since as shipped, it's commented out. The original MemoryRealm would not recognize changes to tomcat-users.xml until you restarted Tomcat. Some of the newer children of that Realm can, but in no case will changes to a user or role definition be recognized until the user has logged out and back in again (to do otherwise would be a potential security problem).

If you attempt to access a URL that's Realm-protected, Tomcat will immediately intercept and present a login screen or dialog (depending on which option was set in the webapp's web.xml file). Failure to login will prevent you from going further. If you login, but your userid doesn't include a role associated with that URL, you get a "503 Forbidden" error.

A 404 error indicates that Tomcat could not process an allowed URL. That can occur if you attempt to communicate with a non-existent webapp (the context name in the URL doesn't match any deployed context) or if the webapp exists but doesn't have a method defined for returning a suitable response, either directly (via a servlet or jsp) or by percolating up to the Tomcat default webapp, which is what serves up things like static image/css/javascript files, lists directories, and so forth.

If you aren't talking to a port that Tomcat's listening on, then unless some OTHER server is listening on that port, the network connection to that port will fail and the client will (hopefully!) display an error message. If you attempt to talk to a port using the wrong protocol (for example, sending plain text to a HTTPS port), usually that, too will give some sort of error message which is typically somewhat cryptic.

[Alan Davenport]

I appreciate the high level explanation.

Turns out, your suggestion of spinning up another instance in tandem and copying over directory worked like a charm. I actually pulled the directory from a slightly newer version of Tomcat but it seems to work just fine.

Thanks for your help.

[Tim Holloway]

Although the Tomcat admin webapps do know how to grab Tomcat's dials and meters, in the final analysis, they're still webapps, so as long as they are designed for the same version of Tomcat that they're deployed in, you can pretty much do with them as you please.

A locked-down production server will often remove them entirely, along with the samples and examples and other non-essential stuff, just to make the overall system more secure and to free up resources that no one's supposed to be using anyway.