Re: Why does mod_jk bypass Apache authorization?
Am 11.09.2014 um 22:15 schrieb Daniel Pfeiffer: On 2014-09-10 22:12, Mark Eggers wrote: I don't think that the trailing /* is valid for a simple Location directive. If you want regular expressions you'll have to use either LocationMatch or Location ~ (Location followed by the ~) This was the decisive hint! JkMount needs /*, but Location doesn't seem to handle it well. This makes the one-argument-form of JkMount quite useless. The solution was using the two-argument-form isolated with /* and Location without. I updated the docs in svn to make that behavior more clear und to warn against that type of use. See: http://svn.apache.org/viewvc?view=revisionrevision=1626582 Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does mod_jk bypass Apache authorization?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 9/12/14 6:07 PM, André Warnier wrote: Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 9/12/14 11:14 AM, Mark Eggers wrote: Chris, On 9/12/2014 7:13 AM, Christopher Schultz wrote: Daniel, On 9/11/14 4:15 PM, Daniel Pfeiffer wrote: On 2014-09-10 22:12, Mark Eggers wrote: I don't think that the trailing /* is valid for a simple Location directive. If you want regular expressions you'll have to use either LocationMatch or Location ~ (Location followed by the ~) This was the decisive hint! JkMount needs /*, but Location doesn't seem to handle it well. This makes the one-argument-form of JkMount quite useless. The solution was using the two-argument-form isolated with /* and Location without. Still doesn't explain why it sometimes works, but I'll leave that as an exercise for mod_jk fans. Would you please log a bug in Tomcat's Bugzilla for this? At the very least, it warrants a documentation fix, and possibly a review of how mappings for Locations are expressed/evaluated. -chris - From the documentation: Inside Location, one omits the first argument (path), which gets inherited from the Location. That's where I took my clue. In Tomcat documentation fashion, the density of information is quite high. I personally don't have a problem with this, even though it's not normally my style (obviously :-p). The problem is that most people would write: Location /foo JkMount worker /Location The /foo in location will handle any URL beginning with /foo while mod_jk will handle a URL with /exactly/ that path /foo. Basically, Location /foo behaves like Location /foo/* without actually saying it, nitpick : more like /foo* +1 and mod_jk will stupidly do exactly as requested, which is not always what might be expected. That's why the above doesn't work as expected, but using Set-Handler does: when Location/JkMount is used, we get a bad JkMount result (mod_jk maps only /foo, not /foo/*). If you use Set-Handler, then /httpd/ makes the decision that the URL matches the Location amd then sets the handler for it. I really do think this warrants at least a documentation update. Clearly explained, thanks. As an addendum, I would venture that the situation gets even more complicated (or downright nonsensical) with LocationMatch regexp, because there is no way JkMount can possibly match that. And as a bit more than an addendum : When you think about it, it would probably greatly simplify mod_jk itself, if it just assumed that any request passed to it was for it, period, and not have his own match evaluation. And let the front-end entirely decide whether mod_jk is the appropriate content-generating handler for this request.(*) See below. Right now, basically, 2 consecutive evaluations are taking place (or at least seem to) : - first httpd, going through all its Location, LocationMatch and File sections, and then if mod_jk is called, it re-does its own evaluation in function of its own separate URI-mapping table. And one has to hope that the results match, which they don't always, as per above. (**) I would guess this is a design left over from a time when maybe Apache httpd's URL-matching was not entirely able to match Tomcat's (***), and nobody thought of questioning it ever after. No, it's because Java web-application people would probably think in terms of the servlet spec's rules for URL pattern matching, where full regexes aren't supported. Instead, you get exact-matching, path-prefix-matching, and extension-matching only. These can all be done by mod_jk (via JkMount) without using regular expressions for the matching, which significantly improves performance. If you want to emulate url-pattern*.jsp/url-pattern with Location, I believe you must use LocationMatch which will use full regular expression matching (for all requests!). At the very least, one possibility would be for mod_jk, when it sees a JkMount inside any Location* section, to turn its own uri-mapping off entirely, and just accept the request as it is. In other words, such a JkMount would just become an alias to SetHandler myself. (Unless no-jk is set of course). Oh do those things get complicated.. +1 It probably *does* make sense for mod_jk to examine the value of the handler to see if it has been explicitly set. I don't know enough about http pipeline processing to know whether or not mod_jk can find out whether Set-Handler has already ... umm .. executed? That's a question for one of the devs more seasoned in httpd/apr. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUFusvAAoJEBzwKT+lPKRYQfUQAJQw7PXMgduk13FYz1JmtjXN gTlZdwYD8QtF7hZn9sHj8SItrgxhTOd/+YWCR3AoVmW7Mb7rdc04Uj5SmpCsArot Icu7ezSXMPX1/XXMFGvDHDAwd09lfhED/MG8CrYk5rLLCe8t9n3ZSjQfF50kJa3j
Re: Why does mod_jk bypass Apache authorization?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 9/12/14 8:36 PM, Mark Eggers wrote: Here was my naive thought. haven't tested this yet (may be a project for this weekend). Outside of a Location or LocatioMatch directive, the JkMount directive parses the configured URL prefix. If requested URL passes the rules, then mod_jk gets to handle the request. Inside of Location or LocationMatch, things are a bit different. Apache HTTPD parses the incoming request. If the requested URL passes, then it's sent along to whatever is inside of the directive. So you can think of a JkMount wrapped in a Location or LocationMatch directive as a 'dynamic' JkMount. It gets rewritten with whatever passes the Location or LocationMatch directives. mod_jk must modify its own internal map of URL (patterns) - workers when it finds a one-argument JkMount within a Location. Simply using Set-Handler is not quite enough: you have to use JkMount (or set JK_WORKER_NAME - or whatever you set with JkWorkerIndicator), otherwise mod_jk will have no idea how to route the request. So, if mod_jk were to skip the URL-matching and rely on httpd's Location (or whatever construct) and Set-Handler, it would also require that JkMount [workerName] (or SetEnv JK_WORKER_NAME [workerName)] also be present. I would imagine that, at configuration time, it would be difficult to determine if all of these things requirements have been met. At request-time, it would be easy to tell if things were okay, but then you may have a bit of confusion by users who haven't quite configured things properly and get a different default behavior then they were expecting. Something like: JkMount [i-made-it-inside] worker At least that was my understanding. And yes, the documentation is not so clear. It doesn't seem to me that obvious that JkMount would somehow read the parameter from Location or LocationMatch and use that in a configuration such as: JkMount /*faddle.jsp$ worker Especially since that regular expression would make no since to JkMount. Correct. It's perfectly reasonable to do something like this: Location ~/.*/abc/*.exe JkMount workerX /Location ... and have a URL pattern that mod_jk has no idea how to handle. It's starting to sound more and more like mod_jk should just not try to over-think things and re-evaluate URLs, etc: it needs a mode where it will take the worker name from JkMount (or Set-Handler) and just use it without checking the URL. On the other hand, I'm not sure how mod_jk can detect (during a request) when it's being called from within a Location. You may have to set some other environment variable to disable mod_jk's URL (re)evaluation logic. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUFu4DAAoJEBzwKT+lPKRY6MYP/iU0iCDHoAtGNk7PqD40MJAG BNGsyc5iaecc+Zs5z6Bq+XAqz5U5ytQt0eJVCL2uw0mFGo+dVmNmiD5IukyNDV2+ YAs9zhAfY5rEAEBssR/KiQkAapnfXN5VQQn80PVSyIwfMqrl3HDuH/kf9xZ66F9v c45szWJHdnAAe+xxp1oI7JHnoZMgROJdwdr7/kwZ2eX6YpjRMMPQ11mQ5mI4yfrZ B5QbprxQA99Eg33rf6WJnTmHaLlj+df0j+BR+vF/vIta7U0qz4IpcIZXM4YYMOOj 8BjI0ei7Wbifv1xx+PW3mOAuFnZiTE8HZHddieiJEItwKqc4ZoioheQUsUfkATAt fwCdl/Gj1Evr5kqPo4ybmyq05H9Pnt0d6AciKuPnd3GfT1Ia7oPY+Sxqro8SDBeq 47OpGqZHk4tAdH4er2jxO2AkobdkYplv3gtcc5v5VtgToieMsB5TADRByTp1B4gh WK8pQbw8jEDBoeJYE73bwcbHS6H6TqmVkhgniB8cmawKi3b4zrahf2dlEKgRwswV /BOYvqomL/XJUKo8DEiDzTMProjSIjNQD1KkATnUBxkw+vZqvYX7fM33jUTLmJCh wyxKa/MJaJMMRj8FsDZb1D2zJgRestaq/P1N2Bh5nvn9MWb8WbETGQM7wkdMbGx8 84XtqKiDng6zqSBCCr6o =W6ig -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does mod_jk bypass Apache authorization?
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 9/12/14 8:36 PM, Mark Eggers wrote: Here was my naive thought. haven't tested this yet (may be a project for this weekend). Outside of a Location or LocatioMatch directive, the JkMount directive parses the configured URL prefix. If requested URL passes the rules, then mod_jk gets to handle the request. Inside of Location or LocationMatch, things are a bit different. Apache HTTPD parses the incoming request. If the requested URL passes, then it's sent along to whatever is inside of the directive. So you can think of a JkMount wrapped in a Location or LocationMatch directive as a 'dynamic' JkMount. It gets rewritten with whatever passes the Location or LocationMatch directives. mod_jk must modify its own internal map of URL (patterns) - workers when it finds a one-argument JkMount within a Location. Simply using Set-Handler is not quite enough: you have to use JkMount (or set JK_WORKER_NAME - or whatever you set with JkWorkerIndicator), otherwise mod_jk will have no idea how to route the request. So, if mod_jk were to skip the URL-matching and rely on httpd's Location (or whatever construct) and Set-Handler, it would also require that JkMount [workerName] (or SetEnv JK_WORKER_NAME [workerName)] also be present. I would imagine that, at configuration time, it would be difficult to determine if all of these things requirements have been met. At request-time, it would be easy to tell if things were okay, but then you may have a bit of confusion by users who haven't quite configured things properly and get a different default behavior then they were expecting. Something like: JkMount [i-made-it-inside] worker At least that was my understanding. And yes, the documentation is not so clear. It doesn't seem to me that obvious that JkMount would somehow read the parameter from Location or LocationMatch and use that in a configuration such as: JkMount /*faddle.jsp$ worker Especially since that regular expression would make no since to JkMount. Correct. It's perfectly reasonable to do something like this: Location ~/.*/abc/*.exe JkMount workerX /Location ... and have a URL pattern that mod_jk has no idea how to handle. It's starting to sound more and more like mod_jk should just not try to over-think things and re-evaluate URLs, etc: it needs a mode where it will take the worker name from JkMount (or Set-Handler) and just use it without checking the URL. On the other hand, I'm not sure how mod_jk can detect (during a request) when it's being called from within a Location. You may have to set some other environment variable to disable mod_jk's URL (re)evaluation logic. Under Apache httpd, why does mod_jk even need to know where it is called from ? It could just assume that httpd is calling it when appropriate and not otherwise. If you want a universal JkMount-equivalent to JkMount /*, then do Location / SetHandler jakarta-servlet /Location , and it will be inherited by all sub-Locations (aka handle all URI's) unless overridden by another SetHandler (like SetHandler None). If you need it more focused or conditional, use the very powerful and flexible Apache Location* sections, and don't second-guess them. All the other Jk* directives can be emulated by the setting (or lack of setting) of Apache variables such as no_jk, JK_WORKER_NAME et al. This may sound counter-intuitive (if not anathema) to Tomcat-focused people. But don't forget that from a httpd point of view, mod_jk (and the possible umpteen Tomcats behind it) is just one way of generating a HTTP response for some request URI's, among many others. Sometimes you need to think out of the box. Or maybe in the box in this case; because after all, we are talking here of a configuration file which belongs to httpd. So it sounds rather logical to me that the directives in it, would have an Apache httpd look and feel; which Jk* directives do not. After all also, when you use either mod_proxy_http or mod_proxy_ajp as a connector, you do use only httpd-style directives. Finally, all this is - in my view - a rather strong argument for using the SetHandler jakarta-servlet in Apache, rather than JkMount/JkUnMount. I originally thought that it was more a matter of preference only, but as a result of this discussion and the pittfalls that it showed, it seems rather more than that : it is much less error-prone. And it would allow mod_jk to avoid its own URI-mapping logic entirely, thus removing a probably sizeable chunk of code, and making it even more efficient. (This becomes rather evident if you turn on mod_jk logging high enough that it shows its efforts at matching every URI it is given). mod_jk 2.x anyone ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does mod_jk bypass Apache authorization?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 9/15/14 11:45 AM, André Warnier wrote: Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 9/12/14 8:36 PM, Mark Eggers wrote: Here was my naive thought. haven't tested this yet (may be a project for this weekend). Outside of a Location or LocatioMatch directive, the JkMount directive parses the configured URL prefix. If requested URL passes the rules, then mod_jk gets to handle the request. Inside of Location or LocationMatch, things are a bit different. Apache HTTPD parses the incoming request. If the requested URL passes, then it's sent along to whatever is inside of the directive. So you can think of a JkMount wrapped in a Location or LocationMatch directive as a 'dynamic' JkMount. It gets rewritten with whatever passes the Location or LocationMatch directives. mod_jk must modify its own internal map of URL (patterns) - workers when it finds a one-argument JkMount within a Location. Simply using Set-Handler is not quite enough: you have to use JkMount (or set JK_WORKER_NAME - or whatever you set with JkWorkerIndicator), otherwise mod_jk will have no idea how to route the request. So, if mod_jk were to skip the URL-matching and rely on httpd's Location (or whatever construct) and Set-Handler, it would also require that JkMount [workerName] (or SetEnv JK_WORKER_NAME [workerName)] also be present. I would imagine that, at configuration time, it would be difficult to determine if all of these things requirements have been met. At request-time, it would be easy to tell if things were okay, but then you may have a bit of confusion by users who haven't quite configured things properly and get a different default behavior then they were expecting. Something like: JkMount [i-made-it-inside] worker At least that was my understanding. And yes, the documentation is not so clear. It doesn't seem to me that obvious that JkMount would somehow read the parameter from Location or LocationMatch and use that in a configuration such as: JkMount /*faddle.jsp$ worker Especially since that regular expression would make no since to JkMount. Correct. It's perfectly reasonable to do something like this: Location ~/.*/abc/*.exe JkMount workerX /Location ... and have a URL pattern that mod_jk has no idea how to handle. It's starting to sound more and more like mod_jk should just not try to over-think things and re-evaluate URLs, etc: it needs a mode where it will take the worker name from JkMount (or Set-Handler) and just use it without checking the URL. On the other hand, I'm not sure how mod_jk can detect (during a request) when it's being called from within a Location. You may have to set some other environment variable to disable mod_jk's URL (re)evaluation logic. Under Apache httpd, why does mod_jk even need to know where it is called from ? It could just assume that httpd is calling it when appropriate and not otherwise. Because we can't simply drop support for JkMount: it would break basically everybody's configuration but yours ;) If you want a universal JkMount-equivalent to JkMount /*, then do Location / SetHandler jakarta-servlet /Location , and it will be inherited by all sub-Locations (aka handle all URI's) unless overridden by another SetHandler (like SetHandler None). If you need it more focused or conditional, use the very powerful and flexible Apache Location* sections, and don't second-guess them. All the other Jk* directives can be emulated by the setting (or lack of setting) of Apache variables such as no_jk, JK_WORKER_NAME et al. This may sound counter-intuitive (if not anathema) to Tomcat-focused people. No, but inertia is a tough thing to overcome. But don't forget that from a httpd point of view, mod_jk (and the possible umpteen Tomcats behind it) is just one way of generating a HTTP response for some request URI's, among many others. Sometimes you need to think out of the box. Or maybe in the box in this case; because after all, we are talking here of a configuration file which belongs to httpd. So it sounds rather logical to me that the directives in it, would have an Apache httpd look and feel; which Jk* directives do not. After all also, when you use either mod_proxy_http or mod_proxy_ajp as a connector, you do use only httpd-style directives. Finally, all this is - in my view - a rather strong argument for using the SetHandler jakarta-servlet in Apache, rather than JkMount/JkUnMount. I originally thought that it was more a matter of preference only, but as a result of this discussion and the pittfalls that it showed, it seems rather more than that : it is much less error-prone. And it would allow mod_jk to avoid its own URI-mapping logic entirely, thus removing a probably sizeable chunk of code, and making it even more efficient. (This becomes rather evident if
Re: Why does mod_jk bypass Apache authorization?
Daniel Pfeiffer wrote: On 2014-09-10 22:12, Mark Eggers wrote: I don't think that the trailing /* is valid for a simple Location directive. If you want regular expressions you'll have to use either LocationMatch or Location ~ (Location followed by the ~) This was the decisive hint! JkMount needs /*, but Location doesn't seem to handle it well. This makes the one-argument-form of JkMount quite useless. The solution was using the two-argument-form isolated with /* and Location without. Still doesn't explain why it sometimes works, but I'll leave that as an exercise for mod_jk fans. This is a matter of preference, and if you are happy with the above, so be it. You may want to document this well in the Apache config file though, because someone viewing this later (maybe yourself even, in 6 months time) would not really understand, and may think it was a typo. I personally am a fan of the SetHandler jakarta-servlet and associated SetEnvIf instructions, mainly for this reason : Essentially, both types of directives do the same thing, but this is an Apache httpd configuration file, likely to be viewed and edited later by people who understand the Apache httpd logic, and maybe not so much of the mod_jk and Tomcat logic. So I find it better to use the Apache-style Location*, SetEnv(If) etc. kind of configuration directives, because they fit better in the standard Apache configuration and scope logic, than the Jk directives. You have just seen an example yourself : the way in which JkMount handles wildcards is not the same a the way Location* directives do, so this - in my view - leads to confusion for the unsuspecting (or just un-mod_jk-educated) sysadmin. It can also lead to confusion if later you need to implement Rewrite or Proxy directives in your Apache configuration, and start having cross-interaction with these Jk* directives. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does mod_jk bypass Apache authorization?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Daniel, On 9/11/14 4:15 PM, Daniel Pfeiffer wrote: On 2014-09-10 22:12, Mark Eggers wrote: I don't think that the trailing /* is valid for a simple Location directive. If you want regular expressions you'll have to use either LocationMatch or Location ~ (Location followed by the ~) This was the decisive hint! JkMount needs /*, but Location doesn't seem to handle it well. This makes the one-argument-form of JkMount quite useless. The solution was using the two-argument-form isolated with /* and Location without. Still doesn't explain why it sometimes works, but I'll leave that as an exercise for mod_jk fans. Would you please log a bug in Tomcat's Bugzilla for this? At the very least, it warrants a documentation fix, and possibly a review of how mappings for Locations are expressed/evaluated. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUEv9uAAoJEBzwKT+lPKRY280P/An7Nrnet7+rE/XUoe2OSejP AVf56og//irGNelYPKkPfPYI0f/inGeK6c5R1afc4DdOX/OVAzJbn4gn8dzt04Zi /CM64oW7J0j9iHIbe1Z9vKCYK/jm+yolEK/qF67keh+Izlt2PPpyYKWq0kwqYX6O vl7tnIjk21ot3ANvuKo9pDz6hCjxwn62sq81cWsHkmxf0JKl+kOc/WmeUQ/QVGTn glhDQLePCpuL9EVPmIrUeHrORuxZOHYHXjUKlV+lXPezYhIWh/1rDR1t0Ega5Ntu noVUOPR43DXQLNesE4+oZNOXQFKWdrV5FCCgfnnKlFtbrFAWbpidnRZhRD8StTQk Y6BFKbi6C3qqTS2tih41rAdQcABUtQ4ETh6UL1W+j3nD5psP30kI23vrR/NT/Ufn q0w89kfHySqOFFKVPjaQO9VUvOpejnfZ31zh+XESZRgq49K4bpovQBHMz6VKc8Xf RLi94KTA7fM1P3fmqLQ7/lPY/Ng+GEgTy7wJZGYM1mJq8FzHp5kEg1h+bCWZZ76A suD8LQZFNpd0dS8FLDL9n47pX1pAk82fICUk4JTkg61vRcSCa3HCF1SEifeslCLs EK/0GaV9dbtuffNJNFPvYOx5R7E+6IudGWgC/eV8uijc1Y7bKdXKp5WIjiKyiH3g RrAwnhZBQB6XJGxoEtk5 =eYJr -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does mod_jk bypass Apache authorization?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris, On 9/12/2014 7:13 AM, Christopher Schultz wrote: Daniel, On 9/11/14 4:15 PM, Daniel Pfeiffer wrote: On 2014-09-10 22:12, Mark Eggers wrote: I don't think that the trailing /* is valid for a simple Location directive. If you want regular expressions you'll have to use either LocationMatch or Location ~ (Location followed by the ~) This was the decisive hint! JkMount needs /*, but Location doesn't seem to handle it well. This makes the one-argument-form of JkMount quite useless. The solution was using the two-argument-form isolated with /* and Location without. Still doesn't explain why it sometimes works, but I'll leave that as an exercise for mod_jk fans. Would you please log a bug in Tomcat's Bugzilla for this? At the very least, it warrants a documentation fix, and possibly a review of how mappings for Locations are expressed/evaluated. -chris - From the documentation: Inside Location, one omits the first argument (path), which gets inherited from the Location. That's where I took my clue. In Tomcat documentation fashion, the density of information is quite high. I personally don't have a problem with this, even though it's not normally my style (obviously :-p). . . . just my two cents /mde/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (MingW32) iQEcBAEBAgAGBQJUEw3NAAoJEEFGbsYNeTwtT0UH/2fnxUiwAmft6elJBzrP3x7/ LUjw7YoHyHRJz+xpBQ30VAgNuycyYP0kGKKG7GNiD2yhECEhYR/nA+x0IB1NPmCg d0ttQmTC/NyFvIkHbsgjLFSqvLqdcpMBJnXXsbBJHbcOIIinIik4BR7IMc6cEacx tleGt0qA0Y/DjO1AfCMJsIAvGrlrNIQz5G8GiU3tf6WFopoRjPZkC3V/4Ty+ykq4 Nvzq0RzgpFK5LRGlU41adSKDGbLXm65grrmOPmMFqPsl+5AUFeBCLCgLExfIDxaT TTWNnqjjBzcgclFsq/wMJpMR7VrEHUj1CQf7qK+cNJNTWWIiOrHeeLkgPzUfrq4= =aCa2 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does mod_jk bypass Apache authorization?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 9/12/2014 2:00 AM, André Warnier wrote: Daniel Pfeiffer wrote: On 2014-09-10 22:12, Mark Eggers wrote: I don't think that the trailing /* is valid for a simple Location directive. If you want regular expressions you'll have to use either LocationMatch or Location ~ (Location followed by the ~) This was the decisive hint! JkMount needs /*, but Location doesn't seem to handle it well. This makes the one-argument-form of JkMount quite useless. The solution was using the two-argument-form isolated with /* and Location without. Still doesn't explain why it sometimes works, but I'll leave that as an exercise for mod_jk fans. This is a matter of preference, and if you are happy with the above, so be it. You may want to document this well in the Apache config file though, because someone viewing this later (maybe yourself even, in 6 months time) would not really understand, and may think it was a typo. I personally am a fan of the SetHandler jakarta-servlet and associated SetEnvIf instructions, mainly for this reason : Essentially, both types of directives do the same thing, but this is an Apache httpd configuration file, likely to be viewed and edited later by people who understand the Apache httpd logic, and maybe not so much of the mod_jk and Tomcat logic. So I find it better to use the Apache-style Location*, SetEnv(If) etc. kind of configuration directives, because they fit better in the standard Apache configuration and scope logic, than the Jk directives. You have just seen an example yourself : the way in which JkMount handles wildcards is not the same a the way Location* directives do, so this - in my view - leads to confusion for the unsuspecting (or just un-mod_jk-educated) sysadmin. It can also lead to confusion if later you need to implement Rewrite or Proxy directives in your Apache configuration, and start having cross-interaction with these Jk* directives. I can certainly see this logic, and in general I think it's sound. 1. People comfortable with configuring Apache may not be that comfortable with configuring Tomcat 2. Larger organizations may have separation of concerns Personally, I've never become as comfortable with Apache HTTPD configuration as I have with Tomcat configuration. Thus, using connector syntax makes more sense to me. However, reading the connector configuration from an Apache HTTPD viewpoint may make one a bit puzzled (as is your point above). It's all in about your viewpoint (relatively speaking). . . . just my two cents /mde/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (MingW32) iQEcBAEBAgAGBQJUEw91AAoJEEFGbsYNeTwtgJ4H/24UPg6Y7zfTDH5YjEAaYXgi N9TD0V4lyPxdSl0EyqSHH/dXALG4Vn3zT8Ms52OHsQEgFjeSAMj0p4c9aMK1fAyk EhV7mW7BB5Zf+Iz7mMCvMieos3MonEPll6ngL0NyQsqHw7hPoXGFJja/QS9juKZ0 kDWaxTyaniYz7z0suNVCmLnql7ZDQ5UrXrcx6nw22vuSqbu9FLQkiBOX79Zwb/Fo 6Xe4PMWp8ehP52iKoMe3YCW4//uBn5xeAPKKljWCJXgw4oXEzAMcV1NnZYuTQZko wn/6GsaBWsVpPNh7wFUnODXoJFRFa5lUVvSY8rUDnzSphi+xVe0NJSn7CHeyCGc= =KFqD -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does mod_jk bypass Apache authorization?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 9/12/14 11:14 AM, Mark Eggers wrote: Chris, On 9/12/2014 7:13 AM, Christopher Schultz wrote: Daniel, On 9/11/14 4:15 PM, Daniel Pfeiffer wrote: On 2014-09-10 22:12, Mark Eggers wrote: I don't think that the trailing /* is valid for a simple Location directive. If you want regular expressions you'll have to use either LocationMatch or Location ~ (Location followed by the ~) This was the decisive hint! JkMount needs /*, but Location doesn't seem to handle it well. This makes the one-argument-form of JkMount quite useless. The solution was using the two-argument-form isolated with /* and Location without. Still doesn't explain why it sometimes works, but I'll leave that as an exercise for mod_jk fans. Would you please log a bug in Tomcat's Bugzilla for this? At the very least, it warrants a documentation fix, and possibly a review of how mappings for Locations are expressed/evaluated. -chris - From the documentation: Inside Location, one omits the first argument (path), which gets inherited from the Location. That's where I took my clue. In Tomcat documentation fashion, the density of information is quite high. I personally don't have a problem with this, even though it's not normally my style (obviously :-p). The problem is that most people would write: Location /foo JkMount worker /Location The /foo in location will handle any URL beginning with /foo while mod_jk will handle a URL with /exactly/ that path /foo. Basically, Location /foo behaves like Location /foo/* without actually saying it, and mod_jk will stupidly do exactly as requested, which is not always what might be expected. That's why the above doesn't work as expected, but using Set-Handler does: when Location/JkMount is used, we get a bad JkMount result (mod_jk maps only /foo, not /foo/*). If you use Set-Handler, then /httpd/ makes the decision that the URL matches the Location amd then sets the handler for it. I really do think this warrants at least a documentation update. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUEyx2AAoJEBzwKT+lPKRYq4oP/RtFjVcKXEBH9Os4rfB/ePQm vVpG23pASOZ3yPdd2P2QnwpW4RvTpK83R10MLyl81DkgwgSSzpb6XAKT1Gl3o6DX +Fl0L7LyjNicwRiJWGvFWvV+KouY0WBeasvDWPWqugplxGt8Zrnf8HANQ0omVL+4 GT40hWpHCpozwFCFdJeKwCd6PF6XTQlQoTxfd4hWbGfHWtf/WjlySGDNrj7t2TNQ dLngNEJXtu9PaM7u/ZS9F0zF2ZKaWsYrH8DJ+ym+l/R9ixruVmVD+V+98pjg9eD5 07kZ6/IosjpacvyTMHtaf4NbjUbsGpVHn4F+5Ae3JNP+XajV90xRkuhPJNyydzgq Ws6Gp7GFkN5DjdBWwwRSPVnPOgSSatW252BgiBN1WPA0fNE4ZIJ6iqV9UdEE2Zfr jf25bX1Qe3xPQpB0jFsQ5SnSkMlRrflDAohgVN4zxxzJw684vw3vLtNoIoEKW7bJ M4DYlSVuaf70WlN4tLIZF7OWezyNUNF087QZff3BiJ9DXeZpS0v4i+XXU7LUmh/e wghXW5m6Sj9No6Nbv2VZ4Y3MNsY96CLeBK1Ge0BhHJq37gt4RJnOq1co7JwMvQpK wmpO2e0m4acLaLEkZxxmyuvnDLM83SObZo6M+WQYuWkCsUDo5XSWRvbIYYIz0SEw 7vt+Urh5OjY+xZlNJfVd =Ncr5 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does mod_jk bypass Apache authorization?
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 9/12/14 11:14 AM, Mark Eggers wrote: Chris, On 9/12/2014 7:13 AM, Christopher Schultz wrote: Daniel, On 9/11/14 4:15 PM, Daniel Pfeiffer wrote: On 2014-09-10 22:12, Mark Eggers wrote: I don't think that the trailing /* is valid for a simple Location directive. If you want regular expressions you'll have to use either LocationMatch or Location ~ (Location followed by the ~) This was the decisive hint! JkMount needs /*, but Location doesn't seem to handle it well. This makes the one-argument-form of JkMount quite useless. The solution was using the two-argument-form isolated with /* and Location without. Still doesn't explain why it sometimes works, but I'll leave that as an exercise for mod_jk fans. Would you please log a bug in Tomcat's Bugzilla for this? At the very least, it warrants a documentation fix, and possibly a review of how mappings for Locations are expressed/evaluated. -chris - From the documentation: Inside Location, one omits the first argument (path), which gets inherited from the Location. That's where I took my clue. In Tomcat documentation fashion, the density of information is quite high. I personally don't have a problem with this, even though it's not normally my style (obviously :-p). The problem is that most people would write: Location /foo JkMount worker /Location The /foo in location will handle any URL beginning with /foo while mod_jk will handle a URL with /exactly/ that path /foo. Basically, Location /foo behaves like Location /foo/* without actually saying it, nitpick : more like /foo* and mod_jk will stupidly do exactly as requested, which is not always what might be expected. That's why the above doesn't work as expected, but using Set-Handler does: when Location/JkMount is used, we get a bad JkMount result (mod_jk maps only /foo, not /foo/*). If you use Set-Handler, then /httpd/ makes the decision that the URL matches the Location amd then sets the handler for it. I really do think this warrants at least a documentation update. Clearly explained, thanks. As an addendum, I would venture that the situation gets even more complicated (or downright nonsensical) with LocationMatch regexp, because there is no way JkMount can possibly match that. And as a bit more than an addendum : When you think about it, it would probably greatly simplify mod_jk itself, if it just assumed that any request passed to it was for it, period, and not have his own match evaluation. And let the front-end entirely decide whether mod_jk is the appropriate content-generating handler for this request.(*) Right now, basically, 2 consecutive evaluations are taking place (or at least seem to) : - first httpd, going through all its Location, LocationMatch and File sections, and then if mod_jk is called, it re-does its own evaluation in function of its own separate URI-mapping table. And one has to hope that the results match, which they don't always, as per above. (**) I would guess this is a design left over from a time when maybe Apache httpd's URL-matching was not entirely able to match Tomcat's (***), and nobody thought of questioning it ever after. At the very least, one possibility would be for mod_jk, when it sees a JkMount inside any Location* section, to turn its own uri-mapping off entirely, and just accept the request as it is. In other words, such a JkMount would just become an alias to SetHandler myself. (Unless no-jk is set of course). Oh do those things get complicated.. (*) because from the httpd point of view, the content generator is mod_jk. And httpd doesn't know, and doesn't give a damn, that there is a cluster of 16 Tomcats behind mod_jk. (**) and then there is Tomcat of course, doing its own URI-to-webapp mapping. And then the webapp itself doing its own URI-to-servlet mapping. It all looks kind of redundant, doesn't it ? (***) or maybe there was no way then, for Apache httpd to change its content-handler on-the-fly, and mod_jk had to sneak its way in there to set itself. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does mod_jk bypass Apache authorization?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/12/2014 3:07 PM, André Warnier wrote: Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 9/12/14 11:14 AM, Mark Eggers wrote: Chris, On 9/12/2014 7:13 AM, Christopher Schultz wrote: Daniel, On 9/11/14 4:15 PM, Daniel Pfeiffer wrote: On 2014-09-10 22:12, Mark Eggers wrote: I don't think that the trailing /* is valid for a simple Location directive. If you want regular expressions you'll have to use either LocationMatch or Location ~ (Location followed by the ~) This was the decisive hint! JkMount needs /*, but Location doesn't seem to handle it well. This makes the one-argument-form of JkMount quite useless. The solution was using the two-argument-form isolated with /* and Location without. Still doesn't explain why it sometimes works, but I'll leave that as an exercise for mod_jk fans. Would you please log a bug in Tomcat's Bugzilla for this? At the very least, it warrants a documentation fix, and possibly a review of how mappings for Locations are expressed/evaluated. -chris - From the documentation: Inside Location, one omits the first argument (path), which gets inherited from the Location. That's where I took my clue. In Tomcat documentation fashion, the density of information is quite high. I personally don't have a problem with this, even though it's not normally my style (obviously :-p). The problem is that most people would write: Location /foo JkMount worker /Location The /foo in location will handle any URL beginning with /foo while mod_jk will handle a URL with /exactly/ that path /foo. Basically, Location /foo behaves like Location /foo/* without actually saying it, nitpick : more like /foo* and mod_jk will stupidly do exactly as requested, which is not always what might be expected. That's why the above doesn't work as expected, but using Set-Handler does: when Location/JkMount is used, we get a bad JkMount result (mod_jk maps only /foo, not /foo/*). If you use Set-Handler, then /httpd/ makes the decision that the URL matches the Location amd then sets the handler for it. I really do think this warrants at least a documentation update. Clearly explained, thanks. As an addendum, I would venture that the situation gets even more complicated (or downright nonsensical) with LocationMatch regexp, because there is no way JkMount can possibly match that. And as a bit more than an addendum : When you think about it, it would probably greatly simplify mod_jk itself, if it just assumed that any request passed to it was for it, period, and not have his own match evaluation. And let the front-end entirely decide whether mod_jk is the appropriate content-generating handler for this request.(*) Right now, basically, 2 consecutive evaluations are taking place (or at least seem to) : - first httpd, going through all its Location, LocationMatch and File sections, and then if mod_jk is called, it re-does its own evaluation in function of its own separate URI-mapping table. And one has to hope that the results match, which they don't always, as per above. (**) I would guess this is a design left over from a time when maybe Apache httpd's URL-matching was not entirely able to match Tomcat's (***), and nobody thought of questioning it ever after. At the very least, one possibility would be for mod_jk, when it sees a JkMount inside any Location* section, to turn its own uri-mapping off entirely, and just accept the request as it is. In other words, such a JkMount would just become an alias to SetHandler myself. (Unless no-jk is set of course). Oh do those things get complicated.. (*) because from the httpd point of view, the content generator is mod_jk. And httpd doesn't know, and doesn't give a damn, that there is a cluster of 16 Tomcats behind mod_jk. (**) and then there is Tomcat of course, doing its own URI-to-webapp mapping. And then the webapp itself doing its own URI-to-servlet mapping. It all looks kind of redundant, doesn't it ? (***) or maybe there was no way then, for Apache httpd to change its content-handler on-the-fly, and mod_jk had to sneak its way in there to set itself. Folks, Ah, now I see. Here was my naive thought. haven't tested this yet (may be a project for this weekend). Outside of a Location or LocatioMatch directive, the JkMount directive parses the configured URL prefix. If requested URL passes the rules, then mod_jk gets to handle the request. Inside of Location or LocationMatch, things are a bit different. Apache HTTPD parses the incoming request. If the requested URL passes, then it's sent along to whatever is inside of the directive. So you can think of a JkMount wrapped in a Location or LocationMatch directive as a 'dynamic' JkMount. It gets rewritten with whatever passes the Location or LocationMatch directives. Something like: JkMount [i-made-it-inside]
Re: Why does mod_jk bypass Apache authorization?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/12/2014 5:36 PM, Mark Eggers wrote: On 9/12/2014 3:07 PM, André Warnier wrote: Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 9/12/14 11:14 AM, Mark Eggers wrote: Chris, On 9/12/2014 7:13 AM, Christopher Schultz wrote: Daniel, On 9/11/14 4:15 PM, Daniel Pfeiffer wrote: On 2014-09-10 22:12, Mark Eggers wrote: I don't think that the trailing /* is valid for a simple Location directive. If you want regular expressions you'll have to use either LocationMatch or Location ~ (Location followed by the ~) This was the decisive hint! JkMount needs /*, but Location doesn't seem to handle it well. This makes the one-argument-form of JkMount quite useless. The solution was using the two-argument-form isolated with /* and Location without. Still doesn't explain why it sometimes works, but I'll leave that as an exercise for mod_jk fans. Would you please log a bug in Tomcat's Bugzilla for this? At the very least, it warrants a documentation fix, and possibly a review of how mappings for Locations are expressed/evaluated. -chris - From the documentation: Inside Location, one omits the first argument (path), which gets inherited from the Location. That's where I took my clue. In Tomcat documentation fashion, the density of information is quite high. I personally don't have a problem with this, even though it's not normally my style (obviously :-p). The problem is that most people would write: Location /foo JkMount worker /Location The /foo in location will handle any URL beginning with /foo while mod_jk will handle a URL with /exactly/ that path /foo. Basically, Location /foo behaves like Location /foo/* without actually saying it, nitpick : more like /foo* and mod_jk will stupidly do exactly as requested, which is not always what might be expected. That's why the above doesn't work as expected, but using Set-Handler does: when Location/JkMount is used, we get a bad JkMount result (mod_jk maps only /foo, not /foo/*). If you use Set-Handler, then /httpd/ makes the decision that the URL matches the Location amd then sets the handler for it. I really do think this warrants at least a documentation update. Clearly explained, thanks. As an addendum, I would venture that the situation gets even more complicated (or downright nonsensical) with LocationMatch regexp, because there is no way JkMount can possibly match that. And as a bit more than an addendum : When you think about it, it would probably greatly simplify mod_jk itself, if it just assumed that any request passed to it was for it, period, and not have his own match evaluation. And let the front-end entirely decide whether mod_jk is the appropriate content-generating handler for this request.(*) Right now, basically, 2 consecutive evaluations are taking place (or at least seem to) : - first httpd, going through all its Location, LocationMatch and File sections, and then if mod_jk is called, it re-does its own evaluation in function of its own separate URI-mapping table. And one has to hope that the results match, which they don't always, as per above. (**) I would guess this is a design left over from a time when maybe Apache httpd's URL-matching was not entirely able to match Tomcat's (***), and nobody thought of questioning it ever after. At the very least, one possibility would be for mod_jk, when it sees a JkMount inside any Location* section, to turn its own uri-mapping off entirely, and just accept the request as it is. In other words, such a JkMount would just become an alias to SetHandler myself. (Unless no-jk is set of course). Oh do those things get complicated.. (*) because from the httpd point of view, the content generator is mod_jk. And httpd doesn't know, and doesn't give a damn, that there is a cluster of 16 Tomcats behind mod_jk. (**) and then there is Tomcat of course, doing its own URI-to-webapp mapping. And then the webapp itself doing its own URI-to-servlet mapping. It all looks kind of redundant, doesn't it ? (***) or maybe there was no way then, for Apache httpd to change its content-handler on-the-fly, and mod_jk had to sneak its way in there to set itself. Folks, Ah, now I see. Here was my naive thought. haven't tested this yet (may be a project for this weekend). Outside of a Location or LocatioMatch directive, the JkMount directive parses the configured URL prefix. If requested URL passes the rules, then mod_jk gets to handle the request. Inside of Location or LocationMatch, things are a bit different. Apache HTTPD parses the incoming request. If the requested URL passes, then it's sent along to whatever is inside of the directive. So you can think of a JkMount wrapped in a Location or LocationMatch directive as a 'dynamic' JkMount. It gets rewritten with whatever passes the
Re: Why does mod_jk bypass Apache authorization?
On 2014-09-10 22:12, Mark Eggers wrote: I don't think that the trailing /* is valid for a simple Location directive. If you want regular expressions you'll have to use either LocationMatch or Location ~ (Location followed by the ~) This was the decisive hint! JkMount needs /*, but Location doesn't seem to handle it well. This makes the one-argument-form of JkMount quite useless. The solution was using the two-argument-form isolated with /* and Location without. Still doesn't explain why it sometimes works, but I'll leave that as an exercise for mod_jk fans. Thanks a lot! 안녕히 계세요 / coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn Daniel Pfeiffer -- 배운다 / lerne / learn / apprends Esperanto: http://lernu.net / http://ikurso.net Reliability, Perl programming and much more in Makefiles: http://makepp.sourceforge.net
Re: Why does mod_jk bypass Apache authorization?
Daniel Pfeiffer wrote: 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 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. It doesn't make a difference whether AuthName is the same as the Realm in JBoss or not. Hi. I think that the problem may be the scope of the JkMount that you have above. I do not think that it is limited to your Location section. It may be global, even when it is in that section. Can you try instead : Location /XYZ/* SetHandler jakarta-servlet AuthType basic AuthUserFile conf/passwd/XYZ AuthName XYZ security Require valid-user /Location See here for more details : https://tomcat.apache.org/connectors-doc/reference/apache.html section : Using SetHandler and Environment Variables - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does mod_jk bypass Apache authorization?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/10/2014 12:52 PM, André Warnier wrote: Daniel Pfeiffer wrote: 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 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. It doesn't make a difference whether AuthName is the same as the Realm in JBoss or not. Hi. I think that the problem may be the scope of the JkMount that you have above. I do not think that it is limited to your Location section. It may be global, even when it is in that section. Can you try instead : Location /XYZ/* SetHandler jakarta-servlet AuthType basic AuthUserFile conf/passwd/XYZ AuthName XYZ security Require valid-user /Location See here for more details : https://tomcat.apache.org/connectors-doc/reference/apache.html section : Using SetHandler and Environment Variables I think all you might need is JkMount: Location /XYZ JkMount AuthType basic AuthUserFile conf/passwd/XYZ AuthName XYZ security Require valid-user /Location Also, I don't think that the trailing /* is valid for a simple Location directive. If you want regular expressions you'll have to use either LocationMatch or Location ~ (Location followed by the ~) If you want everything INCLUDING /XYZ protected, then the above Location directive is what you want. If you want only things UNDER /XYZ protected (but NOT /XYZ), then you need: Location /XYZ/ JkMount AuthType basic AuthUserFile conf/passwd/XYZ AuthName XYZ security Require valid-user /Location based on the Apache 2.4.x documentation. . . . just my two cents /mde/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (MingW32) iQEcBAEBAgAGBQJUELC3AAoJEEFGbsYNeTwtfnIH+wR8DiOAV1Q/KTkl9eBcjuUW nGlg5L04HiyLqIYEYZvM2f3DoaWSnvmU5+D7Wrh1AO34ymkNFu5YzB1m67JV4OZ8 zSafBfnaofwYHFJSwCxNe3Qa3Y/h9A5dwGZzlR9O2N+EAVBLtOLqQTd66HyN8AgK KLk3g8FvGRynLpT0+TfPhWA+5UJyCoTaQyVCDy37cIMFYg35hdxPreAtCk0gLQEK Msz7SOU+J0aNNSP6FUMNb7hqzPxlPF/GzEUartazmM1n6HkxXiYIb+Xj81bCi7P2 lH+1W+do1Lxs3++ZZZOrjU28fE5s65BnVIfl1tQcyhYT/9E7cH1KmUcoaxp0iWY= =HdFz -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why does mod_jk bypass Apache authorization?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Daniel, On 9/10/14 3:40 PM, Daniel Pfeiffer wrote: 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 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. It doesn't make a difference whether AuthName is the same as the Realm in JBoss or not. Do you have an ErrorDocument set for 401? What is it? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUELFFAAoJEBzwKT+lPKRY1DUP/0GgmwYhmqeQ3VNpHTl3UNkg 0FTboIyXikOsEl8+ew0m8hYJGdUloClBwHFbJhF8UkZEY8MOnLJwkAt3ZZ2vpB2d PbreF0TfM6mUzr0jFF9a2Ew+CfSgpoNR3idhSAIniJCl2qSlu2Nc/qxa/jn1SLqU 7ZDaXlT5eDZGypRI0gyswKhVz5C9yF91p0r7HJtdWibinrRuB9hBR38ggACn9kF6 J0nY8L6Qod2KNc8EAVlSdvZlLBBN9GjBvQeA+zrZYn///lutl6L1uOd6tfp5ouqd z5Ph2y5i9UaKrMqOOrgzePxK01C3ciZM14ElIARQ37gUrl6/idQFg/D9tw3hVhX+ xZzPXi8F2VHKeF+WbvQ1oD0lzD2KobZ/5senhisPUdwEWVaX/xbVVV3sT+JFm8n0 7PMEDX39GGGfriVR1W2aOtUTJvkCCcOqdT91lvxWjLOmClEorjdRQevOqvVIlIMB jQb66FsWmLA4SmpABwBLHESyKnRBUFR1R1IZrtBUMeehW2MCwNg7v5Fr++6IYzRm OELFTvKIOQdajSoR3+wfzCb25M2NIs60ZH1n/5pgdfu3BkoQLaCBklDceNJnS2bG WTThZMJ5/ZM++MpVFjoMLvZY0SZC7+BsDehIFX1bOe5oZw33JnZdGOPyJBMtvRGL nURHKAtF2To793rnW4d2 =Tdbg -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
