Variable scope issue ?

[Philippe Brand]

Hi,

We have developped encap to check IP address validity.
Incoming IP address is stored into a variable "requestIP", which can be either request.tcp.remoteHost, or if XFF header present, from this header (if gateway is behind web proxy).
It happens a few times where there seem to be a problem with this variable having its value changed inside a loop, which seems, at first, impossible.

Code:

Audit events when loop failing, e.g. couldnt find address 83.167.141.238 as "whitelisted", from IP list:
83.167.141.238/32
7.24.161.98/24
7.26.244.67/24
168.124.12.205/24

You can see indeed that "requestIP" seems to have changed value, or that "All access to IP" is doing internally something weird.

Incoming address on this API was indeed 83.167.141.238 but loop failed to validate it as for an unknown reason incoming IP was first set to 52.97.162.109, which is in fact another IP address used by another API.

Allowed IP parameters:

What is wrong here ?

[Philippe Brand]

Policy attached here for reference.

Attachment(s)

IP_Filtering.xml   14 KB 1 version

[Jay MacDonald]

Hi Philippe,

  What parameters are passed to the encapsulated assertion? Is that how IP_List is set? Are there other variables set by the Encass? If IP_List is passed as an argument to the Encass, is it passed as a labelled parameter or is it preset in the calling policy and passed as a string? If you export the encpasulated assertion and post that XML here it would help me understand your set up better. In the mean time I'll continue to work through the policy to see if I can find the issue.

Thanks,

JayMac

[Philippe Brand]

Hi,

Args:
IP_List, passed as string or referenced variable, doesn't matter.

83.167.141.238/32

7.24.161.98/24

7.26.244.67/24

168.124.12.205/24

IP_skip_fail: false
errorFormat: text

Please note we have also this weird behaviour if "tcp' is set instead of variable ${requestIP} in "Allow IP Address Range".
It seems to happen when there is a lot of activity on the Gateway.

Encap:

"PSEC fail with error message" is one of our custom encap which basically does the same as "OTK Fail with error messages" exept it specifically deals with HTTP error codes and custom APIs error handling. It sets error.code, error.msg, status and content-type, to be ultimately used by "Custom Error Response" assertion.

[Philippe Brand]

Hi,

After case for opened, finally dev team has been able to replicate this, and it is indeed a bug.
FYI it means that sometimes, IP filtering is not working thus rejecting legit calls.

I was told the fix would be only part of GW 10.

As this is highly sensitive, because we can't wait for v10 to be released, and because upgrade path to v10 doesn't take one day but an extensive period of time, is it possible to get a hotfix, even .jar file would do the trick, or a 9.4CR04 ?