2

Since switching from Apache 2.2 authorization gets bypassed for many JkMounts (except jk-status). If I cancel the browser password popup, I get a 401-page. It is not, as I expect, the one from Apache, but instead from JBoss, which it shouldn't have been allowed to talk to. (I found this because unauthorized users are talking to JBoss.)

On the receiving end we have both JBoss 4 and Wildfly 7. This is both with "Apache/2.4.3 (Unix) mod_jk/1.2.37" and "Apache/2.4.10 (Unix) mod_jk/1.2.40". Configuration is always like

<Location /XYZ/*> JkMount XYZ AuthType basic AuthUserFile conf/passwd/XYZ AuthName "XYZ security" Require valid-user </Location>

I even have a case where the identical setup (worker definition, <Location>, file permission and content) works on 2.4.3 but not on 2.4.10. For other JkMounts both versions both behave wrongly. If I raise the debug level, I don't see anything about how it parses this. When I call the URL, it says there is no directive protecting it.

Improve this question

1 Answer 1

Reset to default
1

It turns out the nested 1-arg syntax of JkMount is pretty useless, because it requires the trailing wildcard, while Location doesn't understand it. What works is pulling it out:

JkMount /XYZ/* XYZ <Location /XYZ>
Improve this answer
1
  • I am not using JBoss, but was looking for a similar solution with vanilla Apache and Tomcat. I was able to edit my httpd conf file similar to this, where the JkMount directive sits outside of the <Location /x> nested instructions restricting access the regular way. Commented Oct 6, 2017 at 15:08

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.