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.

Daniel
  • 131
  • 2

1 Answers1

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>
Daniel
  • 131
  • 2
  • 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 `` nested instructions restricting access the regular way. – Shawn Oct 06 '17 at 15:08