[IP Restriction]: PATCH issue

Questions
1

Hi Team,

I’m Varun, a Software Engineer at SAP. We use Kong Gateway(v0.11.0) for our Developer Portal. Currently, I’m doing POC on IP Restriction plugin and I found few things as follows:

  1. As per documentation to enable this plugin on Consumer we have to use /plugins end-point as follows:
    curl -X POST http://kong:8001/consumers/{consumer}/plugins
    –data “name=ip-restriction”

    –data “config.whitelist=54.13.21.1”
    –data “config.whitelist=143.1.0.0/24”

I was expecting 54.13.21.1 and CIDR range 143.1.0.0/24 to be whitelisted but only one of them was whitelisted.
I figured to whitelist multiple IPs/CIDR(s) we have to pass it as comma-separated values. I’m yet to test it but I think we can just update the documentation.

  1. Documentation states whitelist and blacklist models are mutually exclusive in their usage so I tried PATCH on existing ip-restriction plugin on consumer with whitelisted restriction as follows:
    {
    “created_at”: 1565828153415,
    “config”: {
    “whitelist”: [
    “152.12.34.56/32”
    ]
    },
    “id”: “8ebf1933-dec1-43e9-bd46-704aa459cbd3”,
    “name”: “ip-restriction”,
    “enabled”: true,
    “consumer_id”: “c18c2004-d0df-487e-a087-ada3bfbdaf14”
    }

Now, PATCH call to blacklist
curl -X PATCH
http://localhost:8001/consumers/{consumer_id}/plugins/{plugin_id}
-H ‘content-type: application/x-www-form-urlencoded’
-d config.blacklist=152.12.34.56%2F32

Response:
{
“created_at”: 1565828153415,
“config”: {
“blacklist”: [
“152.12.34.56/32”
],
“whitelist”: [
“152.12.34.56/32”
]
},
“id”: “8ebf1933-dec1-43e9-bd46-704aa459cbd3”,
“name”: “ip-restriction”,
“enabled”: true,
“consumer_id”: “c18c2004-d0df-487e-a087-ada3bfbdaf14”
}

I see both blacklisted and whitelisted CIDR notation.
So, how does it work in this case?

Thanks,
Varun

2

Answer:

  1. I tried this with next branch of Kong and it seems like it is already fixed.
  2. I tried this too with next branch and got:
{
  "message": "schema violation (only one of these fields must be non-empty: 'config.whitelist', 'config.blacklist')",
     "name": "schema violation",
     "code": 2
   "fields": {
      "@entity": ["only one of these fields must be non-empty: 'config.whitelist', 'config.blacklist'"]
   },
 }

So it seems like these are already fixed (I remember doing those lately):



Those might have something to do about it.

The 0.11.0 sure may have these issues. Though we have not considered them big enough to backport fixes to those quite old releases (and make new 0.11.x release).