OK, this is what I was originally writing before BKBK's last respond and my reply to him.
I have new info report--and I DO believe it will be the solution for anyone (like the OP, Ian) who needs to support calling into the add-on service from some IPV6 address--which the "ipaccess" feature (and that jetty-ipaccess.xml file) does not allow you to whitelist. Apologies that it's a long reply. Lot's to cover/clarify.
TLDR; 1) in the jetty/start.ini file, add to the end a new line (--module=inetaccess, which enables that module) and comment out the existing ipaccess line (#--module=ipaccess, which we will no longer use), and 2) define a jetty-inetaccess.xml (in the \jetty\etc\ folder) with the contents I show below--which WILL allow whitelisting/blacklisting ipv6 or ipv4 addresses (and more). You may find you need to also 3) modify the jetty start.ini to comment out the jetty.http.host line (for reasons I will explain) or use the approach BKBK offered just above to modify the jetty-http.xml). I will explain the relationship of this last point to this whitelist matter, which is not obvious.
1) Indeed, let me point out first that in my initial reply to the OP, Ian, I added as one workaround how an alternative might be to use a hosts file to have the localhost resolve to an ipv4 address. I have since updated that first reply, as there's more to that than meets the eye., and I think it's worth a moment of our time here also.
To be clear, the issue of the jetty whitelist feature we're discussing is NOT about the IP address (or host name) used on a URL to call INTO the add-on service. Instead it's about the IP address FROM WHICH such request is made. That's a key distinction to keep in mind when testing things related to this! 🙂 It's also easy to lose track of even when you're aware of it, as happened to me more than once today.
1b) And as some may need to hear it: let's clarify that all this discussion of whitelisting IPs has NOTHING to do with the ip address of the clients making calls to your CFML code which may then use CF features to call upon the jetty/add-in service, like cfsearch/cfindex/cfcollection for Solr and cfhtmltopdf for pdfG. We're talking about the ip address of the CF server that is connecting to that jetty/add-on service.
That said, as has been shown in previous replies here, you can also DEMONSTRATE calling into the jetty service using a URL that names the server running the jetty service and uses its port. See BKBK's previous replies and screenshots for examples of that.
2) Here's another important point before I discuss the "solution". When it comes to wanting to investigate "what's happening" (when things fail related to this whitelisting), note that there is an available "request log" in the jetty logs folder (formally with the name format of [yyyy_mm_dd]_request.log).. And in that log you can see in its first column the ip address FROM WHICH a request is made. That's key.
And it's when THAT shows an ipv6 address , such as pehaps [0:0:0:0:0:0:0:1], that the default whitelist feature would fail--because that would not match the 127.0.0.1 there by default. As important, note that this jetty request line will also show the STATUS code returned to this request--which will be a 403 for requests that fail this whitelist check (or due to the blacklist check).
2a) I suspect in Ian's situation (as for many), it's that his machine which is running CF had on the CF Admin "Solr" page its "Solr Server" value set to the default of "localhost"--but his machine resolves that hostname to ::1. Why is that important? As I noted in my revision to the first reply today, I find that when a request is made TO an ipv6 address, the receiving server sees the request as coming FROM an ipv6 address. And so his request would be sent to the add-on service as if it's from his ipv6 address (that 0:0:0:0:0:0:0:1 I mentioned).
And I confirmed this in my own jetty request log--along with it getting a 403, because that "from address" doesn't match the 127.0.0.1 that Adobe puts into that jetty-ipaccess.xml file's whitelist value by default. Yet if one tries to modify that whitelist to add either 0:0:0:0:0:0:0:1 or ::1, the add-on sevice won't start (as discussed earlier today) because this jetty ipaccess module simply does NOT allow ipv6 addresses.
3) And before I offer the new solution, I'll remind readers that I had proposed a couple of alternatives to Ian originally. He's not yet confirmed if he tried them.
One is simply changing the "solr server" value in the CF admin (Solr page) from "localhost" to 127.0.0.1 (when CF and the add-on service are on the same machine). Again I am finding that if you make the call TO an ipv4 address, that causes the recipient to see the request come FROM an ipv4 address, in this case 127.0.0.1--which matches the default whitelist. (Again, you can prove it yourself looking in the jetty request log.
4) But there may well be folks who will be setting up the CF and Solr (add-on) service on different machines, and those may use IPV6, such that they will really PREFER to somehow allow use of ipv6 addresses to be whitelisted. And it seems I have come up with the solution for that. (It was hard-going, as I didn't readily find it discussed ANYWHERE, with regard to Jetty--except in the context of writing java code to cause Jetty to allow it, which most here would NOT want to do. Or now I can add that, like BKBK, I found discussions of XML that looked like what he offered--but it didn't work.)
So what's the solution? Change from using the jetty "ipaccess" module to the jetty "inetaccess" module, which DOES support whitelisting or blacklisting ipv4 and IPV6 files. Then configure the associated xml file for that. How does one do these? Pretty easily, actually. There are just two steps.
5) Step 1: In the jetty/start.ini file, go to the end of the file and add a new line:
--module=inetaccess
That is key to enables that different module (and it's a step BKBK was missing in his last reply.
I wouild also recommend commenting out the existing ipaccess line, so that all access is controlled by this module. That's easily done. You should find it listed as the current final line in the start.ini file. Just put a hash/pound sign in front of it:
#--module=ipaccess
While it makes sense to have only one module in control of this access, the only negative to this is that some will read Adobe and other resources that propose changing that jetty-ipaccess.xml file...and such changes will be ignored once this ipaccess module is disabled (just like I reported to BKBK that his proposed new inetaccess xml file was being ignored by Jetty because he'd not yet enabled the module that uses it.)
I think the benfits will outweigh the risk--at least for those who want/need ipv6 control of whitelist/blacklisting. And who knows, perhaps Adobe will see the value in this and switch to using this instead. That could take time to happen, of course.
6) Step 2: Then define a new jetty-inetaccess.xml (in the \jetty\etc\ folder) with contents like I show below--which WILL allow whitelisting/blacklisting ipv6 or ipv4 addresses (and more). Of course, change it to use the IP addresses you need, for the originating servers that will be calling into your jetty/add-on service (remember to use the jetty request log to confirm what values are coming int and getting 403's). Here is a version of the file that worked for me:
<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "https://jetty.org/configure_10_0.dtd">
<Configure id="Server" class="org.eclipse.jetty.server.Server">
<Call name="insertHandler">
<Arg>
<New id="InetAccessHandler" class="org.eclipse.jetty.server.handler.InetAccessHandler">
<Call name="include">
<Arg>
<Array type="java.lang.String">
<Item>127.0.0.1</Item>
<Item>::1</Item>
</Array>
</Arg>
</Call>
<Call name="exclude">
<Arg>
<Array type="java.lang.String">
<!--<Item></Item>-->
</Array>
</Arg>
</Call>
</New>
</Arg>
</Call>
</Configure>
And BKBK, note how different that is from the one you proposed. I'll repeat: I had found one like you did, but I got the error which I said (in my reply to you) that I got when trying yours. This one does not get errors. More important, if you make any "incorrect" change (like incorrect xml, or changing the name of some element), you would find this one WOULD get errors when the add-on service started.
And of course you do need to restart the add-on service for these changes to take effect.
6a) Before moving on, you'll notice that I have commented out the element for the blacklist (what is referred to in this file and the inetaccess module as an "exclusion" rather than a blacklisting--perhaps a nod to changing norms regarding such terminology). I showed this in case one does not want to blacklist/exclude but only whitelist/include. To be clear, once you list an include, then ONLY requests from the listed ip addresses will be allowed. Others would get that 403 error in the log and on-screen.
6b) Of course, if you wanted to allow calls into jetty from some other IP address, you could add them as another "item" in the first "include" list. For example, I was testing calling into one machine running the add-on service from another, and for that to work I had to add its ip address, in my case:
<Item>192.168.68.58</Item>
As for how to know the ip address of that other server, course you could just do a command-line ipconfig (or the *nix equivalent, ifconfig) to get that (for whatever network device makes the connection), but I'll remind you again that you can find it just as easily being reported in that first column of that jetty request log, if you make a request to this add-on service from that other server and it's rejected with a 403.
6c) But what if you do NOT see your request (from another server) showing up in the jetty request log--as a 403, or even at all? Well, you may have found that when you ATTEMPTED the request from the other server, you didn't get any 403 error shown but instead the request just hung.
That would be because you probably have to open the firewall on the add-on service to ALLOW such a call in to the add-on service port from another server. That's beyond the scope of this disucssion, but I share it before someone says "I made all these changes and it's still not working for me". Of course, if there's some other problem with anything I reported, I welcome feedback.
6d) But what if it was indeed that the address for that other server was an ipv6 address? Indeed, we would want to add another "item" element...but in terms of what to put in as the value, well, this is where things can get tricky, especially for those not familiar with ipv6 addresses. (Things were easy with the "::1" for a localhost/loopback address.)
Here again, one may be tempted to just go to that other server and do an ipconfig/ifconfig to get the ipv6 address (for whatever network device made the connection). But beware, if you put that into the xml file it may fail to be allowed as you'd expect. Let me share an example.
I went to the other server from which I was making the request (and I had used in the call to the solr server the ipv6 ip address of the CF add-on service server), and I did an ipconfig and found the ip address reported to be:
fe80::4115:17a4:6371:7229%6
And I put that into the xml file as another "item"...but the request still was blocked (with a 403, as tracked in that jetty request log).
So I'll say again: the best thing to do to get the ip address FROM WHICH a request is made is to look in the jetty request log at that first column. When I did that, it showed the ip address instead as:
fe80:0:0:0:4115:17a4:6371:7229%27
That's quite different from the one above that I got from the ipconfig. It's similar, butnotice for instance the ":0:0:0:" where before there was just "::". Then of course the closing % values are different. I'll note elaborate on ipv6 details. But I AM saying that until I put the SECOND value into the XML file, it was NOT properly whitelisted:
<Item>fe80:0:0:0:4115:17a4:6371:7229%27</Item>
Hope that helps folks.
6f) Before wrapping up discussion of the inetaccess module, I will point out that there are indeed other things you can specify in these "item" values, including ip address CIDR values and ranges. I'll leave it with pointing you to the docs for more, as this is already a blog-length reply!
Note that these address values are technically instances of an "InetAddressSet" java class, and the (brief) docs showing examples of other kinds of item values are available here, for the Jetty 9 version that recent CF versions have included.
7) Finally, before wrapping up there's another thing some may readers may find helpful with regard to a DIFFERENT aspect of how the CF Jetty service (or any jetty service) may be configured. (Again, I had already started writing this before BKBK's note, and what I offer will be a bit different than his proposal to tweak the jetty-http.xml file, which is of course a workable option.)
When it comes to calls into the jetty (add-on) service, note that there is YET ANOTHER configuration aspect which relates to what ip address (and port) jetty LISTENS on, meaning what IP addresses you can CALL INTO the service--which is quite different from the whitelist feature, which is instead to control what IP addresses you can CALL FROM.
This is important to understand because sometimes when you may be testing various URLs used to call into the jetty service, the ip addresses or domain names will ultimately reach the server using some ip address (or a hostname that resolves to one), and whether the jetty service is willing to "listen" for requests to that ip address depends on this other configuration. Let me explain with examples.
7a) If you look in that jetty start.ini file (referred to previously in this post and thread), you will find among its values a line called "jetty.http.host", and you may well find it preconfigured to have this value:
jetty.http.host=127.0.0.1
That means that jetty has been configured to ONLY listen for requests either TO that IP or for a hostname that RESOLVES to that IP. This is another reason that one may find a failure in calling into jetty. We talked before about how if you're using localhost and your server resolves that to ::1, then that's the request you'll try to reach...and this host value will reject that (differently from the whitelist).
So could you change it to ::1? Well, yes. But then it would ONLY accept requests on that address (calls INTO that address). That could trip up some OTHER request made to jetty.
7c) So what to do if you DO want to let jetty "listen" for calls into more than one ip address (whether ipv4 or ipv6)?
Well, sadly you can't list more than one address on this line...and you can't list two of the lines.
So in fact, in BKBK's previous reply he showed how you one option would to switch gears and use the jetty-http.xml file to name two "connectors" that listen on the different IPs (to which requests could come into this server). That's certainly an option. See his reply for more details.
But I'll share one other option which may suit some folks: if you simply comment out that jetty.http.host line, that will allow jetty to listen to requests on ANY incoming address (again, this is not about the address FROM which a request comes, but the one TO which a request comes). To do that, again just comment it out:
#jetty.http.host=127.0.0.1
In doing that, now jetty will listen to requests coming into ANY ip address which the server has, again whether ipv4 or ipv6, so that could include 127.0.0.1, ::1, and indeed others (as you would find from an ipconfig/ifconfig done on the jetty server.)
7c) Now, could someone contend/ask, "well isn't this then the only solution that someone needs" to solve the original problem?
Well, maybe.
First, note that the currently implenented ipaccess module still limits where requests can come FROM. Remember, the original problem Ian presented was wanting to whitelist an ipv6 address--which that module can't do. And I surmised it was because indeed the localhost value on his CF machine resolved to ::1. And the ipaccess whitelist would block that.
So could he instead JUST comment out both this jetty.http.host and the ipaccess module?
Well, yes.
But then you'd be leaving yourself open to relying SOLELY on your firewall to protect you...and you could conceivably have bad-guy calls come into jetty (and solr and pdfg) from somewhere INSIDE your network.
And in fact THAT is why the default value for this jetty.http.host is 127.0.0.1--the presumption is that you ONLY want to allow requests that come INTO that ip address...and generally one can only request that ip address if they are ON the server where jetty is installed.
I realize all this can make your head swim. I hope it makes sense if you read this post carefully, perhaps a couple of times. 🙂
8) Like I said, it's taken me a long time (hours) just to write this up (carefully), not to mention the hours I spent exploring the problem and finding the solution (when it was really hard to find). Of course, now the AI agents will soon find this thread and offer to people THIS XML as the solution to the problem. OK, I'll have done my job.
And you who have read through to this point get to be like explorers of a cavern who get to say you were there when it was discovered. Of course, it's an arduous journey descending into a new cavern. Hope it was worth the trip. Future folks will find the answer presented more succeinctly by the AI agents. And sure, I could have made this far more brief, but as is my wont I wanted to explain things, to try to help others who would take this ball and run with it. I love challenges like this!
And as always, if I have made any mistakes, let me know. Soon I would want to turn this into a blog post--to help those who don't read this forum, and may need the info before the AI bots consume and regurgitate it.
Looking forward to what Ian, BKBK, and anyone else may have to say.
/Charlie (troubleshooter, carehart. org)
18
Replies
AdChoices