Inspiring

Question

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

Forum|Forum|5 months ago
September 3, 2025
2 replies
1057 views

I need to limited access to the SOLR web application to localost. The server it is running on has both IPv4 and IPv6 and in the jerrty/etc/jetty-ipaccess.xml in this section:

<Item>::1</Item>

</Array>

</Set>

When I add IPV6 I get a error when I try to restart jetty. So I cannot lock it down.

Any ideas?

BKBK

Community Expert

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):

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>

Restart the ColdFusion 2025 Add-On service.
Restart ColdFusion 2025.
In the ColdFusion Administrator, navigate to the 'Solr Server' page and confirm the Solr port number (8997).
Open the URL http://127.0.0.1:8997/solr/ in a browser. The result is as expected:
Check ColdFusion's logs and jetty/logs/ and confirm there are no errors.

BKBK

Community Expert

Suggestions:

Test with 0:0:0:0:0:0:0:1 in place of ::1 in the above jetty/etc/jetty-ipaccess.xml setting.
After the chnage, make sure you restart both the Add-On service and the ColdFusion service.

Charlie Arehart

Community Expert

BKBK, nope, neither works (not ::1 nor 0:0:0:0:0:0:0:1).

Let's clarify a few things, for everyone's sake. And I think I may see why you are experiencing things differently.

1) First, just to be clear: while he was asking about CF2023, and you are talking about CF2025, the issue is the same for each (at least since the April 2025 CF updates that incorporated the changes in the configuration of the add-on service/jetty/solr/pdfg to rely on this jetty-ipaccess.xml file).

As for why it seems "ok" for you to specify a ipv6 value in that whitelist, I have a couple of thoughts.

2a) First I'd propose a test for you to try: change the value of the whitelist to use ONLY 127.0.0.2 (or any random ip) and restart your add-on service. Then try to visit that localhost:8997 url. (Folks on CF2023 would use 8995, while folks on CF2021 would use 8993.)

The point here is that you SHOULD get an error rejecting that request, if the whitelist is protecting you. If you do not get an error, then your jetty-ipaccess.xml is not doing the protection it should.(And so jetty may not even be loading it let alone verifying it as we're experiencing. And I share below the error we see in the jetty logs.)

And there could be two reasons for that happening for you.

2b) One is that I notice your screenshot of the solr dashboard, it shows one of the values as -Dsolr.solr.home=multicore. From my experience, that's the value one gets if you have implemented the separate add-on installer, in which case of course you need to be editing the jetty-ipaccess.xml within the etc subfolder where THAT was installed. By default, it would be /ColdFusion2025Add-onServices.

Sadly, that solr dashboard does not confirm for us what folder the Solr is running in, beyond that jvm arg. (FWIW, with respect to the Jetty implemented within a CF2025 folder, the value would instead show -Dsolr.solr.home=C:\ColdFusion2025\cfusion\jetty\multicore

2c) Second, along the same lines, in the root of the jetty folder (whereever it's installed) there will be a start.ini. In that file. In that file, do you see a line indicating this:

--module=ipaccess

You should. In a default CF install of Jetty (at least since those April updates), it's the last line of that file. But of course it doesn't need to be last. It DOES need to not be commented (that start.ini file uses pound signs as comments).

Again, sadly the solr dashboard does not show anywhere a confirmation of this. That's why I started with the test in my point 2a.

3) Finally, just to clarify for Ian and anyone else following along, when things fail as he and I have experienced, not only do we find the add-on service won't start (and that localhost call to the add-on service/jetty/solr/pdfg port will fail), but also in the jetty/logs folder, the one called [yyyy_mm_dd].stderror.log will report the error as "Invalid IP address pattern: ::1" (when attempting what Ian reported originally).

Ian, can you confirm you see that error?

4) If you do see that error, again (as I reported originally), this is not an Adobe problem: it's a jetty problem. And to be clear, Adobe chose (starting with cf9) to bundle the solr feature (technically the add-on service which it's a part of) as an implementation atop Jetty, which is itself another app server implemented within CF. (And in CF11 they also implemented the PDFG feature, for cfhtmltopdf, on the same jetty. Both solr and pdfg are implemented as "web apps" within Jetty. It was never clear why they didn't do it via Tomcat instead.)

It's only when the Jetty project chooses to solve this ipv6 problem in jetty-ipaccess.xml (or there becomes some other way to limit Jetty by ipv6 addresses) that the error will no longer occur.

(As an update since posting this reply, I do think I have found the solution. See my next reply.)

In nay case, BKBK, I will again be very curious to hear what you find when you do the test in my point 2a above, and what you find with respect to points 2b and 2c. Even just as a sanity check for you. 🙂

5) Along those lines (for those following along), when one DOES have this jetty-ipaccess.xml set to whitelist some IP address but your request does NOT come from that (like if it's set to 127.0.0.1 but yuor machine running CF makes that request via IPV6), and you then try to visit the localhost:[jettyport] page (whether you add "/solr" on the URL or not), the error you get for CF2025's add-on service will simply be "HTTP ERROR 403 Forbidden". But the error for CF2023's add-on service will be "HTTP ERROR 500 java.lang.IllegalArgumentException: Invalid IP address: <the ip you tried to use, or the ip the hostname resolved to>".

I suspect that difference has something to do with other aspects of Jetty configuration, like that ipaccess module I referred to in point 2c. Anyway, I offer those also in case others get the error and search for it, so that they may find this discussion.

Hope it proves helpful.

/Charlie (troubleshooter, carehart. org)

Charlie Arehart

Community Expert

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.

/Charlie (troubleshooter, carehart. org)

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded