Cold Fusion 2023 Restrict access to SOLR web app to localhost on server with IPV6

Hi @iclark3509 and @Charlie Arehart ,

I attempted to reproduce the error you are talking about, but was unable to.
Here are the steps I followed (on ColdFusion 2025 Update 3 installed on Windows 10):

1.   In the file jetty/etc/jetty-ipaccess.xml replace the default element
   

   <Set name="white">
   		  <Array type="String">
   			<Item></Item>
   		  </Array>
   		</Set>

   with
   

   <Set name="white">
   		  <Array type="String">
   		   <Item>127.0.0.1</Item>
   		   <Item>::1</Item>
   		  </Array>
   		</Set>

2.  Restart the ColdFusion 2025 Add-On service.
3.  Restart ColdFusion 2025.
4.  In the ColdFusion Administrator, navigate to the 'Solr Server' page and confirm the Solr port number (8997).
   

    

5.  Open the URL http://127.0.0.1:8997/solr/ in a browser. The result is as expected:
   

    

6.  Check ColdFusion's logs and jetty/logs/ and confirm there are no errors.
    

Yep, I'd experienced the same. And when I looked into it some weeks ago, it seemed this was an unfortunate limitation in Jetty, not something of Adobe's doing. There are a couple of potential workarounds.

First, since you're wanting to define ::1, is it that localhost on the cf machine resolves to that?  If so, had you considered just changing the "Solr Server" page in the cf admin? While the "Solr Host Name" field there does DEFAULT to localhost, note that despite the name of the field you CAN change that "solr host name" specify an ip address instead, such as 127.0.0.1. That would work for some folks.

As for the related "pdf service" page in the CF admin, while it has a pre-defined "localhost" service, note that it's "host name" field is configured by default to a value of 127.0.0.1 (this despite the field's name implying that it might accept only host names). That one works with the default jetty-ipaccess.xml file, since that is the IP address that's whitelisted (and it's ipv4).

Finally, if one somehow needed to, they could use a hosts file on the cf machine to define some hostname that resolved to an ipv4 address. But that should be unnecessary.

Update since posting: I want to refine that last statement. When I wrote it, I was falling into the mistaken presumption (easy to make) that the whitelist and blacklist were about the IP being CALLED, when instead they are about the IP FROM WHICH THE CALL is made.

 

But it so happens that when you DO make a call TO an IPv6 address (or use a host/domain that resolves to one), the destination IS given the IPv6 address for the machine FROM which the call was made. So technically using a hosts file that defined some host that resolved to 127.0.0.1 WOULD change the request to come from the machine's ipv4 address...which for many would resolve to 127.0.0.1

 

But the rest of what I said above still applies: the problem is that if in your environment, your CF server might be on some machine that presents to the add-on service an ipv6 address, which would fail to meet the whitelist above--and the challenge is how to allow for that. (Besides the workarounds above, see more I later discovered in subsequent replies below.)

Let us know, Ian, if the suggestion above works for you, or not.