tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Mod_jk returning source code of jsp files
Date Tue, 24 Apr 2012 09:11:33 GMT
ironclaw hand wrote:
> Ok thanks for the reply and the points are taken on board but as I said before I havent
actually done this before and I am initially trying to get it to work as the existing system
does (using the config files from the current installation).
> I know in an ideal world your suggestion would be best but I was just asked to install
current versions of apache, tomcat and mod_jk and get it all to work and I was given some
existing config files, as said I have never done this before so initially I would actually
like to get mod_jk working so that I can actually see the java code getting executed and the
dynamic content returned.
> I dont think the overhead of tomcat serving static pages is the reason apache is installed
on these machines, I think it is because of the load balancing as there are a number of machines
with Tomcat installed on them that will be in the load although initially I am only trying
to get apache to direct to a tomcat on local host.
> I was looking for some help understanding why mod_jk  doesnt work for me, surely this
cant be related to the security issues you mentioned?
Well, you are probably mistaken there.
With the current configuration, what is apparently attempted is, for some URLs, to have 
Apache httpd /not/ forwarding them to Tomcat via mod_jk, and instead having Apache httpd 
serving them directly, using a "back door" into Tomcat's webapps/sft/ directory.

This /is/ a security issue, because in this way, any security mechanism that may be in 
place at the Tomcat level to avoid delivering the wrong content, are bypassed.
That is why, from a security point of view, it is strongly recommended not to allow Apache

to see, and serve the content of, directories whose content should be controlled by 
Tomcat.  Your Alias and <Directory> section at the Apache level do just that, so they

create a large potential security hole, which then someone tries to plug using other 
instructions (which by the way look like they're wrong and/or incomplete).

But apart from the security issue, this scheme has further drawbacks :
- it makes things more confusing as to whom is serving what
- Tomcat "knows" that a .jsp file's content is not to be served as is.  It knows that this

kind of file has to be "compiled" into a servlet, and that instead of delivering the 
content of the .jsp file, it should run the resulting servlet, and serve its response.
Apache httpd has no idea about that. It sees a .jsp file as just a text file, and happily

serves its contents as is (even if the .jsp source file contained some information which a

user should never see).
And that is exactly what you are seeing.

Something in your present configuration allows Apache to "see" these jsp's, and serve them

directly.  It is not very clear at the moment how this happens.  In order to remove some 
potential reasons why this could happen, Chris and I showed you how to modify your 
configuration so that in the principle, it should not happen. Or at least, it should 
remove one potential way in which it could be happening, leaving us with a more 
transparent situation helping to find the real reason.

A useful tool to find out what happens is the mod_jk logfile.  Increase JkLogLevel 
gradually, until you see which URLs mod_jk is actually forwarding to Tomcat (and which 
ones it is not, and why not).

A bit of background, to understand what happens :
When mod_jk is configured within Apache httpd, it acts as a "content generator".  For 
Apache httpd, it is mod_jk itself which creates the content that is returned to the user.

  Apache httpd has no idea that behind mod_jk, there are one or more Tomcats who actually

do the work.
When it comes time to generate the response to a request URL, Apache passes this URL in 
turn to all configured "content generators" (one of them being mod_jk).  Each of these 
content generators gets a shot at deciding whether it wants to generate content for that 
URL, or just decline.  If the content generator declines, Apache passes the URL through 
the next content generator in the chain, to see if it does better.  The last content 
generator in the chain is the Apache builtin one, which reads the file from disk and sends

the content back "as is".
In other words, mod_jk gets to see /every/ request URL, and gets to decide if for this 
one, it wants to pass it on to Tomcat or not.  It decides this on the base of an internal

table it has built at server startup, on the base of the JkMount/JkUnmount instructions it

knows about. If it decides that this URL is not for Tomcat, it returns a "declined" answer

to Apache, and Apache proceeds to ask the next module.  If mod_jk decides to pass this 
request to Tomcat, then it does so using the AJP connection, and waits for Tomcat's 
response. When it gets the Tomcat response, it returns it to Apache (as if it had created

it itself), along with a return code that means "here is the response, you do not need to

call any other module anymore".

What is most probably happening in your case is one of two cases :
- either this request never makes it to the VirtualHost in which this mod_jk is activated.

  In that case, the mod_jk log would not even show the requests for these .jsp's.
As a result, Apache defaults to handling the request with its own content generator, which

just returns the .jsp file from disk.
- or the request makes it to the VirtualHost, and mod_jk sees it (and puts this in the 
log), but mod_jk for some reason does not find a match with the request patterns that it 
should forward to Tomcat.  The log will show you that also.
As a result, Apache also defaults to handling the request with its own content generator,

which just returns the .jsp file from disk.

In both these cases, due to your present configuration, Apache /can/ deliver the .jsp file

"as is", because it can see them, directly in the Tomcat webapps/sft directory.  If it 
didn't, then you'd get a 404 error when you request a /sft/*.jsp URL.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message