Yeah, I thought about the extra param option, but we would need to keep that in sync around all the other /api/a.1 /api/a.2 /api/a.3 since we are trying to use /api/b as a reusable cloud managed library of functionality between everything.
For our use-case. I tried the ‘Modify Headers’ options on both sides to remove the X-Forwarded-For to no avail. I am guessing on the on the /api/a side the X-Forwarded-For happens after the Endpoint Designer. And on the /api/b side the enable_ip_whitelisting/allowed_ips happens before the Endpoint Designer.
We may end up going w/ a ‘secret’ in the param.
I’m just alerting the fact that there is a chance of injecting that straight in tyk is right on the front lines (or azure loadbalancing, dns round robining, etc.). Maybe there should be a feature to have two whitelists – end clients that can connect to the api (the way it is happening now with allowed_ips) and devices that can connect to the api (allowed_remote_addr, i.e. the LBs, nginxes, localhost, etc.). Or if an untainted remoteAddr were available in request in middleware/virtual endpoint I would be able to make my own decisions via code for this particular use case.