Skip to main content
H
HC_Tech
Participant
October 23, 2019
Question

ColdFusion 2018 - HTTP Status 403 - Forbidden

  • October 23, 2019
  • 3 replies
  • 7499 views

Hello,

 

We have ColdFusion 2018 (HotFix4) running on (Windows Server 2016 - IIS).  The ColdFusion Lockdown has been installed.  The site was working fine with HTML & CFM pages, until something changed. Now only HTML pages work.  When we attempt to browse to a CFM page, we receive:

 

HTTP Status 403 - Forbidden

Description The server understood the request but refues to authorize it.

Apache Tomcat/9.0.10

 

I confirmed the Application Pool identity account has access (Read/Execute) to the CFM files.  There is an entry under "ISAPI Filters" named "tomcat' that points to (D:\CF_Install_Folder\config\wsconfig\1\isapi_redirect.dll), and this file exists.  The (wsconfig.exe) runs fine.

 

Does anyone have any idea what may be causing this issue (403 - Forbidden) for CFM pages?

 

Thank you!

    This topic has been closed for replies.

    3 replies

    T
    T27332149bvar
    Participant
    December 28, 2022

    My similar-problem was with Coldfusion2021 & Apache24 (64bit) on fresh Win11 i9 laptop.

     

    Note: "C:\ColdFusion2021\cfusion\runtime\bin\wsconfig.exe" wasn't working. It would exit immediately with no message.

     

    Problem 1: Connection unavailable
    Solution:

    Changed localhost to 127.0.0.1 in three places:
    1,2. In "C:\ColdFusion2021\cfusion\runtime\conf\server.xml":
    <Engine defaultHost="127.0.0.1" name="Catalina" jvmRoute="cfusion">
    <Host autoDeploy="false" appBase="webapps" name="127.0.0.1" unpackWARs="false">

    3. In "C:\ColdFusion2021\config\wsconfig\1\workers.properties":

    worker.cfusion.host=127.0.0.1

     

    Once this was fixed I had the 403 error.

     

    Problem 2: Status 403 Forbidden
    Solution:
    There was a missing worker.cfusion.secret setting in "C:\ColdFusion2021\config\wsconfig\1\workers.properties" i.e.
    worker.cfusion.secret=f3ae2c16-bd42-4ea1-88a9-[etc]

     

    ...but that secret key was already placed
    In "C:\ColdFusion2021\cfusion\runtime\conf\server.xml"
    <Connector protocol="AJP/1.3" port="8020" redirectPort="8453" secret="f3ae2c16-bd42-4ea1-88a9-[etc]" maxThreads="500" connectionTimeout="60000" tomcatAuthentication="false" />

     

    Once I set it everything worked again.

     

    I don't know if this will work for anyone else but I tried everything I could find in the forums before succeeding.

     

    W
    William31143467d2v6
    Participant
    July 18, 2023

    You have no idea how helpful this community has been for me! Same exact error Coldfusion 2018 Update 17. The wsconfig worker.cfusion.secret property/value was missing after the install. Either manually adding the 'secret' from the server.xml file or following Charlie's method in the link below (probably the better method), problem fixed. Thanks!

     

    https://coldfusion.adobe.com/2020/03/three-reasons-sites-may-break-fix-applying-mar-2020-update-cf2018-2016/

    B
    berniemiller
    Inspiring
    April 7, 2020

    I had the same issue after running the Lockdown tool. I ran wsconfig.exe manually and tried the Upgrade button. I have no idea what that does but it fixed the issue for me.

      A
      arshad_brody
      Participant
      April 16, 2020

      Thank You!

      I also received the 403 error after I installed the ColdFusion 2018 Performance Monitoring Toolset.

       

      Charlie Arehart
      Community Expert
      Charlie ArehartCommunity Expert
      Community Expert
      October 23, 2019

      Did you ensure that app pool identity user has access to the config/wsconfig folder you name? It needs write access for the logs it would write. And while you could do this only at the /1 folder, you may was well do it at the config/wsconfig folder above it, in case you may add still other connectors later.

      (Yes, if each site has its own app pool that uses only its own connector/numbered folder, then yes, you need only give THAT app pool identify user permission to that specific folder, if you want to be really secure about things. But really, this is not about getting access to CF code or CF settings, but just connector config files, so it may not be that critical to be so careful. I am open to correction from anyone interested.)

       

      Let us know if that change helps. BTW, you mention that applied lockdown. Did you do that just before things started to fail? Or weeks/months ago? Did you do it by hand? or by using the auto-lockdown tool new to CF2018?

      /Charlie (troubleshooter, carehart. org)
      H
      HC_TechAuthor
      Participant
      October 23, 2019

      Hello Charlie.

       

      Thanks for pointing me to the (config/wsconfig/1) folder.  We did have some incorrect permissions, which I have corrected. Fortunately, we have two CF nodes configured identically.  I mirrored the permissions between the two nodes. The second node still works fine, and I'm able compare settings between good and bad nodes.

       

      Unfortunately, I am still receiving the 403 error.  We have three IIS web sites on this server and all report the same error.  They all appear to be using the (/1) folder.

       

      During the initial build I installed the CF auto-lockdown tool (.exe) on both systems, and they continued to work fine. This was several weeks ago.  If the file permissions have changed, I have not yet been able to identify where?

      Charlie Arehart
      Community Expert
      Charlie ArehartCommunity Expert
      Community Expert
      October 23, 2019

      Have you tried making the request to the "failing sites" from the server itself, on which they run (rather than from off the server)? You may get a different and more useful error message. Assuming you still get just the 403 and no more, check the "error pages" feature in IIS for the site you are testing. Use its "edit feature settings" on the right. Is it set to show details for local and custom errors to remote users? If it is instead "custom errors" for both, switch that for a moment to detailed for local (not for remote), and try the request again from the server.

       

      If that doesn't help (or you can't or won't be able to change it), another thing you can try if the IIS Failed Request Tracing (or FRT) feature, to find more on why the requests are failing. That's too much to cover in a simple reply here, but google searching will help, or I can help via remote consulting (perhaps having all that done in minutes).

      /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