Inspiring

Question

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

Forum|Forum|6 months ago
September 3, 2025
2 replies
1125 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.

BKBK

Community Expert

Your logs don't disprove what I said. Why must it always be this way between us? Dude, I gave you the specific steps to show why what you offered in your jetty-inetaccess.xml is NOT the solution AND IS NOT WORKING, at least with respect to the problem of supporting requests FROM an ipv6 address.

Again, try blacklisting that ipv6 address (shown in your log) using your xml. Is it blocked? Until you do that, your offered xml is more confusing to matters than helpful.

I tried to be very clear and helpful in my reply to you. I explained why your jetty-http.xml alone was allowing what you're seeing. (But that's NOT proving the ipb6 whitelist/blacklist you propose is working.)

And I feared that despite my best efforts there, you'd only see red at my temerity to question you. Read it again, or don't. I'm done with this, regarding your proposed jetty-inetaccess.xml solution. Hell, you even posted your reply after my very long response with the working jetty-inetaccess.xml (including proof that it's working), but you make no reference or comment on it here.

I just hope discerning readers carefully consider all that's been said.

Charlie, it's not just about my logs. It's about a whole demonstration of the whitelisting solution I proposed:

Jetty restarting without any issues;
URL access to Solr via 127.0.0.1;
URL access to Solr via ::1;
request.log showing the Solr requests were successful;
stderrout.log showing there were no errors.

Let me recap.

The original post from @iclark3509 reported that he had attempted to whitelist 127.0.0.1 and ::1 using a setting in jetty-ipaccess.xml. As a result, he couldn't restart Jetty.

You replied, saying that you had had the same experience. Namely, that Jetty wouldn't start when you attempted to whitelist 127.0.0.1 and ::1 in jetty-ipaccess.xml. Hence, the problem at hand was how to whitelist 127.0.0.1 and ::1, and get Jetty to start.

The solution I proposed does two things:

It points out that jetty-ipaccess.xml (the configuration file you and @iclark3509 had used) is not the correct XML file for the job.
It provides two correct configuration files to use, namely, jetty-inetaccess.xml and jetty-http.xml.

It is in my solution that the files jetty-inetaccess.xml and jetty-http.xml appear for the very first time in this thread. Hours later, you posted suggestions that expanded on the methods I had used. You took the idea and ran with it in different directions, including blacklisting (besides the original whitelisting) and the use of Jetty's module system.

That can only be a good thing for the forum. In fact, as I have often said, I appreciate and encourage the exchange and cross-fertilization of ideas. Very much so.

However, unfairness, backhandedness and insincerity may rub me the wrong way. In this forum, at least, you have the habit of unfairly dragging down or decrying the opinion of others, and then to provide what you consider the authoritative opinion. On occasion you've even gone as far as to ask participants to refrain from posting until you do so.
(I shall respond to your points about the use of Jetty modules in a separate post.)

I strive to be tolerant, respectful and professional. What I won't stand is someone being condescending, unfair and disingenuous.

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