Skip to main content
P
peterw1996572
Participating Frequently
July 16, 2020
Answered

Coldfusion 2018 .htaccess file rewriterule not working for .cfm files, Tomcat AJP13 “reuse is set to

  • July 16, 2020
  • 1 reply
  • 3335 views
I have an .htaccess file in a /reports/ folder with the following rule:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.cfm?path=$1 [L,QSA]

There is an index.cfm in the /reports/ folder that loads a list of all manufacturers, if one is not specified in ?path=

The rewrite is working on my dev server, and my staging server, but on my production server I get an error from Tomcat:

HTTP Status 403 – Forbidden
Type Status Report
Description The server understood the request but refuses to authorize it.
Apache Tomcat/9.0.21

I'm on CentOS 7 with Apache 2.4.

The .htaccess file is part of the source code.

I have another site on the server that uses a RewriteRule in the vhost.conf file and that works fine in dev, staging and production.

If I change the RewriteRule to this, it redirects fine.

 

RewriteRule ^(.*)$ https://google.co.uk [L,QSA]

 

If I visit the page directly (/reports/?path=BMW/) the page loads fine.

The only thing I've been able to find is the mod_jk.log has this error when I try to load the BMW (or any other) report:

[warn] ajp_process_callback::jk_ajp_common.c (2245): (cfusion) AJP13 protocol: Reuse is set to false

The error is only on the production server, not the dev or staging servers. Does anyone have any idea what "Reuse is set to false" means? And if that's related to something that would stop my RewriteRule from working?

I've tried searching the Tomcat source code and I can't find "reuse is set to false"

I've found a "DisableReuse" flag in the Tomcat docs, but I can't find mention of that on dev, staging or production servers.

I tried setting JkOptions -DisableReuse in /etc/httpd/conf/mod_jk.conf and restarted Apache, that made no difference.

I can't find the difference between the 2 working servers and the one failing to rewrite to CFM pages, other that the "reuse is set to false" log entry.

  • Coldfusion 2018,0,10,320417
  • Amazon Coretto (Java) 11.0.8
  • Tomcat 9.0.21.0
  • Apache 2.4.6
  • Centos 7.7.1908
This topic has been closed for replies.
Correct answer Charlie Arehart

Pete, the 403 could be happening for an entirely different reason than you are anticipating, with perhaps a very simple solution.

 

I know you said that you felt the cf instances were equally configured, but you show being on cf2018 update 10, which came out just this week. That could be a key factor, as I will explain.

 

First, are you saying that your dev and staging machines are at the same cf update level?

 

And either way, did you run the wsconfig upgrade after that? And if so are you sure that the mod_jk.so file modified by that tool is indeed the one pointed to by your mod_jk.conf or whatever conf file points to it? (Does it have a july mod date?) If it's not updated, that can cause one kind of error, because of security improvements to this "ajp connector" between apache and cf (or iis and cf, as well). As another confirmation, does your workers.properties file (as pointed to also by those conf files) have a secret line (not just a monitoringsecret line)?

 

Second, even if both cf and the wsconfig WERE properly updated and DO have that secret, another security aspect of that updated ajp connector upgrade is that cf (technically the tomcat underlying it) will now reject requests (with a 403) if those requests have a header that the new, more secure connector doesn't recognize.

 

One way to know (and solve the error) is to modify the cf/tomcat side to go back to allowing any header, as it always did. (And since cf's ajp port is a non-public one in nearly all firewall setups, that's not a risk of some public exposure.)

 

The way to tell the connector to allow that is to modify the cf runtime/conf/server.xml file (in cf's cfusion folder or a sibling instance folder if you created one). In that file, find the ajp connector (with the same ajp port and secret that is listed in that workers.properties file). On that line, add an attribute:

 

allowedRequestAttributesPattern=". *"

 

You would need to restart CF after that.

 

It may well be this alone will be your solution. (And a difference in Apache rather than CF could also be contributing to why that's an issue on the prod server and not the others, with regard to this second point above.)

 

Let us know if any of the above get you going. If not, at least we will have ruled them out. 

 

Finally, FWIW, I did a blog post with much more detail on that cf update and these ajp connector changes, at:

https://www.carehart.org/blog/client/index.cfm/2020/3/20/how_and_why_sites_may_break_after_Mar_2020_CF_updates

 

One last thing: just be aware that Adobe doesn't formally support Coretto, only the Oracle jvm (which they've licensed for us and is available from the cf downloads site). I have many blog posts on the topic of updating the jvm in cf, with the link to that and more, for anyone wanting more info. 

1 reply

Charlie Arehart
Community Expert
Charlie ArehartCommunity ExpertCorrect answer
Community Expert
July 16, 2020

Pete, the 403 could be happening for an entirely different reason than you are anticipating, with perhaps a very simple solution.

 

I know you said that you felt the cf instances were equally configured, but you show being on cf2018 update 10, which came out just this week. That could be a key factor, as I will explain.

 

First, are you saying that your dev and staging machines are at the same cf update level?

 

And either way, did you run the wsconfig upgrade after that? And if so are you sure that the mod_jk.so file modified by that tool is indeed the one pointed to by your mod_jk.conf or whatever conf file points to it? (Does it have a july mod date?) If it's not updated, that can cause one kind of error, because of security improvements to this "ajp connector" between apache and cf (or iis and cf, as well). As another confirmation, does your workers.properties file (as pointed to also by those conf files) have a secret line (not just a monitoringsecret line)?

 

Second, even if both cf and the wsconfig WERE properly updated and DO have that secret, another security aspect of that updated ajp connector upgrade is that cf (technically the tomcat underlying it) will now reject requests (with a 403) if those requests have a header that the new, more secure connector doesn't recognize.

 

One way to know (and solve the error) is to modify the cf/tomcat side to go back to allowing any header, as it always did. (And since cf's ajp port is a non-public one in nearly all firewall setups, that's not a risk of some public exposure.)

 

The way to tell the connector to allow that is to modify the cf runtime/conf/server.xml file (in cf's cfusion folder or a sibling instance folder if you created one). In that file, find the ajp connector (with the same ajp port and secret that is listed in that workers.properties file). On that line, add an attribute:

 

allowedRequestAttributesPattern=". *"

 

You would need to restart CF after that.

 

It may well be this alone will be your solution. (And a difference in Apache rather than CF could also be contributing to why that's an issue on the prod server and not the others, with regard to this second point above.)

 

Let us know if any of the above get you going. If not, at least we will have ruled them out. 

 

Finally, FWIW, I did a blog post with much more detail on that cf update and these ajp connector changes, at:

https://www.carehart.org/blog/client/index.cfm/2020/3/20/how_and_why_sites_may_break_after_Mar_2020_CF_updates

 

One last thing: just be aware that Adobe doesn't formally support Coretto, only the Oracle jvm (which they've licensed for us and is available from the cf downloads site). I have many blog posts on the topic of updating the jvm in cf, with the link to that and more, for anyone wanting more info. 

/Charlie (troubleshooter, carehart. org)
    P
    peterw1996572Author
    Participating Frequently
    July 16, 2020

    Thanks Charlie, 

    I'll go through all these suggestions to see if that fixes the 403 errors.

    I should have mentioned I was having the same issue on Coldfusion 2018 Update 9 and the earlier version of Coretto, I updated both after the recent HackMyCf alerts, also hoping that might resolve the issue.

    I didn't rebuild the connectors this time as the documentation stated:  

    "Post installation, we recommend rebuilding or reconfiguring your connector.

    Note: This holds true only if you have applied Update 10 without applying Update 8."

     

    I did have issues with the connector after upgrading to 8 or 9 (I might have done the last 2 at the same time) and had to rebuild the connectors then.

     

    I'm sure there is a configuration difference with my production server, wether it's Apache, Coldfusion, Tomcat or something else I have no idea. I'll double check everything is updated to the same version down to the build number.

     

    I've used Coretto on this server for a while as the official Java versions for Coldfusion provided by Adobe are a bit slow to be released, but I'll try switching back to the officially supported version once 11.0.8 becomes available here:

    https://www.adobe.com/support/coldfusion/downloads.html 

     

    I'll post back here once I've given everything suggested a try.

    Charlie Arehart
    Community Expert
    Charlie ArehartCommunity Expert
    Community Expert
    July 16, 2020

    Fair enough (on your having already updated the connector after update 8). I just was noting that since you were on update 10, this whole matter WAS potentially a factor. It is interesting that you say you did not have it between 8 and 10. I've not heard of anyone else with any Apache connector issues unique to 10, but it's only been 2 days, so time will tell.

     

    And as for Java, yep, sadly Adobe can be a bit slow about getting the Java downloads onto that page. Still no 11.0.8 there, though it too has been only 2 days since that came out also. Fo course, many people don't really want to jump to new versions in the first days anyway, leaving others to suffer the bleeding edge. 🙂 But sure, for those who DO want a new update ASAP, it's too bad that they can't get them ASAP there.

     

    FWIW, I will say that I have compared the binaries of the files there and from Oracle, and they are identical. And since the license which we agree to is in the installer, that means that we're agreeing to the same license either way. I know some (including from Adobe) assert that we "should use the installers from Adobe", but if they're the same--and we can get them from the Oracle site sooner, I just point that out as an option for some to consider.

     

    Please do let us know how you get on with the other issue.

    /Charlie (troubleshooter, carehart. org)
    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices