Implement rate limiting based on host ip with python plugin but without auth hook

Support Operation and Testing
, ,
1

We have implemented host ip based rate limiting using python plugin with auth hook and its working fine. The issue is that if there is anything wrong with the plugin, all clients start getting 403, which is wrong.
We experienced this recently in production and we had to take the whole tyk implementation away from system. here is the link to that Error with middleware in one gateway while other pods are working fine

I understand that auth hook is required to create a session in first place but is there a way that we can implement this without the auth hook so that users don’t get 403 if there is something wrong with middleware.

2

You should be able to do the same auth check in a pre-request plugin. We have a blog about a similar process in Java Script that could help.

3

I don’t think this will work due to this

I tried setting ‘x-tyk-authorization’ to host ip and setting up the session and token in pre hook, but it keeps on looking for the IP in redis to do authorization.

Looks like there is no way to implement rate limiting based on IP without doing any kind of authorization

4

That’s true, there is still a pending issue Runtime error when calling get_data from Python middleware - #8 by Lohanna_Sarah with the Python get_data API.

The alternative is to use Golang plugin or program a separate connection to Redis then modify the key

Coming back to this, would ensuring one gateway starts before the others not mitigate this?

Also, could you explain more about why you feel a 403 output when there is a plugin error is wrong? My thinking would be if there is a plugin error that is critical to the API request, surely you would want to block authentication and mitigate any kind of security risk. Or would it be the status of the error you are more concerned about?

5

The whole point of authentication just to implement rate limiting seems wrong.

  • If there are any plugin related errors, system should generate 500 and not 403
  • The thing is that our backend is already doing authentication, now if I am getting 403 from my rate-limiting system, it just adds to confusion
6

The whole point of authentication just to implement rate limiting seems wrong.

We do have API rate limiting on the API level. IP-based rate limits need the IP to be tracked. Which requires some kind of persistent storage, hence Redis.

If there are any plugin related errors, system should generate 500 and not 403

I can’t replicate this. The 403s are auth failed responses. If there is a plugin error, the status code is always 500. Maybe if you share your gateway version and plugin code, I could reproduce it.

7

In our case, we are getting 403s. It may be due to the fact that enable_coprocess_auth is set to true.

enable_coprocess_auth: true

Can a session be created with python plugin without auth?

8

Still doesn’t occur in my environment.

No, as far as I know.

But you could set the authentication to use the authToken and utilize the gateway Keys API in a pre-request middleware call to create a custom key (/tyk/keys/{keyID}) in Redis for the identified IP address

The value of the key returned in the response body

{
  "key": "base64encoded value of {"org":"<org_id>","id":"<custom key id> e.g. 172.x.x.x","h":"<hash_key_function>e.g. murmur64"}"
}

Hope this helps.