oh...@cox.net wrote:
---- Christopher Schultz <ch...@christopherschultz.net> wrote:
Chris, you managed to confuse the guy..
...
To be clear, in the discussion before now, I was just using mod_ajp
and that was a perfectly valid way to connect Apache to Tomcat.
...
I'm now in the process of trying to switch my Apache conf to use mod_jk.
Aaaah. Why did you do that ?
Not that it is not /also/ a valid way to connect Apache to Tomcat, but both are pretty
much equivalent, and now you're starting a whole new bag of possible complications.
The reason is that I'm starting to get the feeling that the Apache 3rd party
agent
(it's Oracle's OAM webgate, which I haven't said till now, sorry) might not be
setting
things in the Apache environment that are needed for AJP.
Well, in that case it won't be doing it for mod_jk either, because mod_jk and
mod_proxy_ajp use exactly the same protocol (AJP) to talk to Tomcat. That's because they
are both talking to the same <Connector protocol="AJP"> in Tomcat, so of course they have
to speak the same dialect.
I hope you saved your prior configuration..
...
skipping a whole big chunk
...
Shouldn't the one "JkMount /samplesajp/*" that I have be enough to proxy
through the mod_jk?
Yes it should, if used in the right place.
But maybe you are using <VirtualHost> sections, in which case the JkMount directive might
not be in the right place.
Also, why is it appearing to try to process the "/oam/..." URIs?
That is because, to Apache, mod_jk is a "content handler" or "response handler".
Apache doesn't know that Tomcat even exists.
When Apache gets a request, it processes it in a series of steps, of which the response
generation is one of the last.
Apache will "pass" the request to all registered response-generating modules which are
(potentially) applicable for this request, one after the other.
Each such module gets a chance to look at the request and decide if it is for
him or not.
If it decides not, then it returns a "declined" response to Apache, and Apache passes the
request to the next response-generating module in the chain.
The first response-generator in the chain which decides "hey, this is for me", generates
the appropriate response, and returns an "ok" response to Apache.
Then Apache knows that the response was generated, and that it does not need to call the
next module in the chain anymore.
mod_jk is such a response handler, so it gets /every/ request that Apache processes, and
it can decide if it wants to take it or not.
It does this by examining the URI, and deciding if it matches one of the entries in its
URI mapping table (the one it built from the JkMount directives).
That's what you see in the log.
If it decides that the URI does not match (as in the case of that /oam/ URI), it
immediately returns a "declined" response to Apache, and Apache will call the next
possible response handler.
If it decides that it does match one of the entries in its table, then mod_jk will
"generate the response" for that request (and let Apache know later that it did).
But mod_jk is a cheat.
It does not really generate a response itself. Behind the scenes (and unknown to Apache),
it slily passes the request to the back-end Tomcat (via AJP), and lets Tomcat do the work.
And when Tomcat sends back a response, mod_jk presents it to Apache as if it has produced
it all by itself, and Apache is none the wiser.
Now since I have berated poor mod_jk, I should mention that any other proxy module (like
mod_proxy_http or mod_proxy_ajp) does exactly the same.
They get to have a peek at any Apache request (at least any that falls into their "scope",
be that the whole <VirtualHost> or just a <Location>), and they decide if they want to
handle it or not.
(This is a difference between Apache and Tomcat : in Tomcat, it is Tomcat which does the
work of matching a request to a webapp; in Apache, it is the modules who do that work).
So now that this is out of the way, let's get back to the core of the issue.
You wanted to pass the Apache authenticated user-id to Tomcat, right ?
And we have not yet established, but pretty much guessed, that this should happen via a
"request attribute" within the AJP protocol exchange between Apache (via mod_proxy_ajp OR
mod_jk) and Tomcat, said request attribute being very likely to be the one named
"remote_user" (lowercase). (And if not, one would be allowed to wonder what this AJP
request attribute might be for).
And Apache has a different terminology, and what AJP and Tomcat call "request attributes",
Apache seems to name "server variables" or "environment variables", depending on where you
look.
And in any case, as you have yourself established, it seems that Tomcat is pretty much
ignoring the HTTP header "REMOTE_USER" that you have set, at least for any purpose of
authentication.
So the whole point is, how do you set this Apache server or environment variable within
Apache, before the request gets proxied to Tomcat ?
And how do you insure that mod_jk or mod_proxy_ajp really picks up that value, to pass it
to Tomcat ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
