Option to deactivate apiHost validation, to allow forwarding to localhost

[Zahikusa]

trafficstars

We are using ReactorCloudFoundryClient to connect to the CF-API.

Version used:

    <dependency>
      <groupId>org.cloudfoundry</groupId>
      <artifactId>cloudfoundry-client-reactor</artifactId>
      <version>5.6.0.RELEASE</version>
    </dependency>

We provide this class with its connection context by building an instance of DefaultConnectionContext:

private DefaultConnectionContext getDefaultConnectionContext() {
    return DefaultConnectionContext.builder()
        .apiHost(config.getApiEndpoint())
        .build();
  }

As you can see, the builder reads the property apiHost from our app-config.

The CF-ApiEndpoint we want to connect to changes depending on the current target-environment. The application that implements ReactorCloudFoundryClient doesn't know about this environment though. Instead, we send all http-traffic to a second, locally running application which knows about the current target environment.

For the above mentioned use-case, we have to set apiHost to localhost:4201, so the traffic is forwarded to our second, environment-aware application.

Using this setup, the following exception occurs upon building the DefaultConnectionContext instance: IllegalArgumentException: "API hostname http://localhost:4201 is not correctly formatted (e.g. 'api.local.pcfdev.io')"

Looking at the call-stack, it seems like this method checkForValidApiHost() in AbstractRootProvider is causing the issue for us:

    @Check
    public final void checkForValidApiHost() {
        Matcher matcher = HOSTNAME_PATTERN.matcher(this.getApiHost());
        if (!matcher.matches()) {
            throw new IllegalArgumentException(String.format("API hostname %s is not correctly formatted (e.g. 'api.local.pcfdev.io')", this.getApiHost()));
        }
    }

We already considered multiple options to workaround this limitation in the apiHost-string-syntax, but so far we couldn't find any working solution sadly.. Do you guys maybe know a way to get around this validation-step of the apiHost property? Or is there any chance that we can disable this validation if needed, maybe through an additional building-param?

Thanks already for any help about this matter!

[dmikusa]

A couple of possibilities:

1. Did you try just changing localhost to 127.0.0.1? The regex just seems to want two . separated blocks. An IP address satisfies that.
2. You could add a DNS record for anything, so long as it has at least one dot in it. Ex: api.fake.example.com, foo.bar, etc... Again, the actual DNS doesn't matter, the regex just wants you to have a dot in the name for some reason. Whatever DNS entry you set up have it resolve to 127.0.0.1.

The easiest way to change the DNS would be to edit the /etc/hosts file on your machine and add an entry for the record. You could add it through a DNS server you control too though, so long as it lets you return 127.0.0.1 as the IP for that ANAME record.

Let me know if one of those works for you. Thanks

[Zahikusa]

A couple of possibilities:

1. Did you try just changing localhost to 127.0.0.1? The regex just seems to want two . separated blocks. An IP address satisfies that.
2. You could add a DNS record for anything, so long as it has at least one dot in it. Ex: api.fake.example.com, foo.bar, etc... Again, the actual DNS doesn't matter, the regex just wants you to have a dot in the name for some reason. Whatever DNS entry you set up have it resolve to 127.0.0.1.

The easiest way to change the DNS would be to edit the /etc/hosts file on your machine and add an entry for the record. You could add it through a DNS server you control too though, so long as it lets you return 127.0.0.1 as the IP for that ANAME record.

Let me know if one of those works for you. Thanks

Thanks @dmikusa-pivotal, we are successfully using the workaround suggested by you for now. There's a bit of additional onboarding overhead because every developer has to add this entry to their hosts-file, but it works. ;)

I think an opt-in option to disabled this apiHost-validator could still make sense for setups similar to the one we are using. But this probably does not have much priority on your side since I didn't find any other user with the same problem.

[dmikusa]

Glad it's working for you.

I think an opt-in option to disabled this apiHost-validator could still make sense for setups similar to the one we are using. But this probably does not have much priority on your side since I didn't find any other user with the same problem.

Yes, we can leave this open as a feature request. I think my thought would be to just remove the regex validation. It doesn't seem to be adding any real value. If you have a minute and want to submit a PR. I could certainly expedite merging it. Otherwise, it'll be a low priority due to the limited impact, and we'll try to work it in at some point.