Highlighted

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

New Here ,
Jul 16, 2020

Copy link to clipboard

Copied

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
Adobe Community Professional
Correct answer by Charlie Arehart | Adobe Community Professional

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. 

TOPICS
Connector, Server administration

Views

177

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more

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

New Here ,
Jul 16, 2020

Copy link to clipboard

Copied

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
Adobe Community Professional
Correct answer by Charlie Arehart | Adobe Community Professional

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. 

TOPICS
Connector, Server administration

Views

178

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Jul 16, 2020 0
Adobe Community Professional ,
Jul 16, 2020

Copy link to clipboard

Copied

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_...

 

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 (server troubleshooter, carehart.org)

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Jul 16, 2020 1
New Here ,
Jul 16, 2020

Copy link to clipboard

Copied

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.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Jul 16, 2020 0
Adobe Community Professional ,
Jul 16, 2020

Copy link to clipboard

Copied

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 (server troubleshooter, carehart.org)

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Jul 16, 2020 0
New Here ,
Jul 17, 2020

Copy link to clipboard

Copied

Right, so first off I've been a bit of a fool.

 

The reason my dev and staging environments were still working is I'd not updated them to update 10, they were in fact on update 5 still (I know how dumb that was, let's move on from that)

 

Updating dev and staging to 10 "broke" the .htaccess rules, which suddenly all made more sense.

 

From your linked article Charlie, the TLDR: point 3 was the solution:

 

allowedRequestAttributesPattern=". *"

 

Updating my server xml has got my .htaccess rules working.

Points 1 and 2 I had to apply to dev+staging as I updated them from 5->10 (via 8 requiring the connector upgrade)

 

So as usual your blog had the answers. Out of curiousity when did you add the allowedRequestAttributesPattern to the post, as I've visited it before for points 1&2 but may simply have glossed over point 3 as I'd not run into the .htaccess issue until recently.

I had posted this on server fault as well, I'll update that question (regarding my dev/local update mistake) and I'll comment back to this post: https://serverfault.com/questions/1025440/coldfusion-2018-htaccess-file-rewriterule-not-working-for-...

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Jul 17, 2020 0
Adobe Community Professional ,
Jul 17, 2020

Copy link to clipboard

Copied

Great to hear, both that you solved the problem and that my suggestion helped.
 
Thanks for the kind regards, and for marking it as the answer. (Sadly, it's not a shorter answer for folks to regard going forward, but that's because at the time I couldn't have known for sure that WAS your answer, given what you'd shared. I had to build up to it). 

 

And understandable on your discovery that the other servers had simply not been updated. That's part of why I had to make my first points: I've found in my work that getting people to check their assumptions often helps explain seeming "inexplicable" problems. 🙂

 

Finally, about my late March blog post, and when I added that "third point" about the allowedrequestattributespattern, if you mean to ask was it recently, no. I think it was a few weeks later, in early May. (I couldn't find the page on web.archive.org, and my old blog software doesn't track update dates.)

 

That said, I am giving thought to either updating that post or creating a new one to make the bottom line changes more clrar and succinct. (Even the tldr and the sister Adobe portal post I did, which was "shorter", are still just too long for most modern readers, I think--or for someone in a panic.)

 

Like my answer here, I share all the details to help as much those who aree trying to understand things, beyond just fixing them. I just need to find a way to balance "the least you need to know", especially in this matter. 🙂

/Charlie (server troubleshooter, carehart.org)

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Jul 17, 2020 0
New Here ,
Jul 17, 2020

Copy link to clipboard

Copied

> getting people to check their assumptions often helps explain seeming "inexplicable" problems. 

that's the same advice I give everyone when helping out... easy to forget one's own advice

 

Even the tldr and the sister Adobe portal post I did, which was "shorter", are still just too long for most modern readers, I think--or for someone in a panic

 

I appriciate being able to understand it, at least to a better degree than I did before, once I'd got the dev server corrected it didn't take long to repeat the solution on staging and ultimately live. The tldr; did help.
I know what you mean about being in a "panic", but knowing why something happens as well as what to do is certainly worthwhile (especially if you find the same problem later down the line, as I did with points 1+2 on staging)

Thanks again!

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Jul 17, 2020 0