ControlFilter check fails when client IP is IPv6

[UweTrottmann]

Since about 2021-08-26 the GoogleAppEngineControlFilter check fails for IPv6 addresses (sent as caller_ip, called clientIp in the CheckRequestInfo API) with below INVALID_ARGUMENT error. If the IP address is IPv4 requests seem to succeed just fine.

I'm not sure if this is due to this library not meeting a new requirement by the Google service control API or if the API itself is faulty. In the last case I hope you can forward this or let me know where to report it!

This is also reported by another user on Stack Overflow: https://stackoverflow.com/questions/69073149/invalid-caller-ip-in-google-cloud-endpoints-based-api

com.google.api.control.Client check: direct send of a check request service_name: "PROJECT_ID.appspot.com"
operation {
  operation_id: "3dcc5224-6451-4f31-9292-ef8dc368fcfa"
  operation_name: "1.PROJECT_ID_appspot_com.REDACTED"
  consumer_id: "project:PROJECT_ID"
  start_time {
    seconds: 1631048821
    nanos: 604000000
  }
  end_time {
    seconds: 1631048821
    nanos: 604000000
  }
  labels {
    key: "servicecontrol.googleapis.com/caller_ip"
    value: "[2800:a4:12a8:6e00:f445:4509:7d7f:32df]"
  }
  labels {
    key: "servicecontrol.googleapis.com/user_agent"
    value: "ESP"
  }
  labels {
    key: "servicecontrol.googleapis.com/service_agent"
    value: "EF_JAVA/1.0.13"
  }
}
 failed
com.google.api.client.http.HttpResponseException: 400
{
  "error": {
    "code": 400,
    "message": "Check request for service \u003credacted_3rd_party_service\u003e has invalid caller_ip value: [2800:a4:12a8:6e00:f445:4509:7d7f:32df]",
    "errors": [
      {
        "message": "Check request for service \u003credacted_3rd_party_service\u003e has invalid caller_ip value: [2800:a4:12a8:6e00:f445:4509:7d7f:32df]",
        "domain": "global",
        "reason": "badRequest"
      }
    ],
    "status": "INVALID_ARGUMENT"
  }
}

at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.newExceptionOnError(AbstractGoogleClientRequest.java:456)
at com.google.api.client.googleapis.services.AbstractGoogleClientRequest$1.interceptResponse(AbstractGoogleClientRequest.java:321)
at com.google.api.client.http.HttpRequest.execute(HttpRequest.java:1067)
at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:419)
at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:352)
at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.execute(AbstractGoogleClientRequest.java:469)
at com.google.api.control.Client.check(Client.java:205)
at com.google.api.control.ControlFilter.doFilter(ControlFilter.java:249)
at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:193)
at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1601)

[abhideep]

Facing the same issue on an Endpoint that was working fine until a month back. Haven't changed anything or deployed a new version so either something changed behind the scenes or a new requirement was added that has not been documented.

[rouberol]

Same issue since end of August. Any news ?

[UweTrottmann]

It appears it was an API issue. No further reports since around 2021-09-10.

[abhideep]

Curious, did you change something in your API definition to make this go away?

Still seeing the exception on our API

[UweTrottmann]

@abhideep I did deploy a new App Engine version 2 days before, but I doubt it is related (only updated App Engine SDK and not e.g. this library). Did not deploy a new service configuration.

[Co-OnlyOne]

Same here, we still got the exception... Probably caused by the brackets in IP address collected

[daswass]

This is still an issue after having upgraded from Java 8 to Java 17. Was there a solution found that cause the issue to be closed?

[UweTrottmann]

I can confirm that I'm seeing this again as I'm testing after migrating to the Java 11 runtime with legacy bundled services.

Note that the request will pass on to the next filter (e.g. it is not blocked) after com.google.api.control.ControlFilter#doFilter because it allows it to continue if checkResponse is null, which happens in this case.