- Is there a limit to the size of kong config or to number of plugins?
- How the number of plugins affect the performance?
- Is patching of any plugin in config is done in thread-safe manner?
Is there a limit to the size of kong config or to number of plugins?
No, they are stored in dynamic structures, limited by your memory, there is no hardcoded limit.
How the number of plugins affect the performance?
The more plugins you have enabled in your kong.conf file, the more database calls Kong needs to perform. This becomes noticeable when your Kong nodes are cold (i.e. when the data has not been fetched from the DB and cached in memory yet). Enabling in kong.conf only the plugins you are actually using in your entities can speed up cold instances…
Is patching of any plugin in config is done in thread-safe manner?
Not sure I understand the question. Lua code runs using coroutines, so they are based on cooperative multitasking. There are no multi-threading issues involved: each Kong worker, running in a separate Nginx thread, has its own Lua virtual machine instance.
Hi Hisham,
Let me describe you my problem.
I am facing a security issue here if my jwt token is stolen by someone. Like someone just copies my jwt and pastes it in his url then he will be able to login effectively impersonating me.
To solve that issue, I put IP-restriction plugin for each currently logged in user. So now, even if someone steals my jwt he will not be able to login using it as ip-restriction whitelist does not contain his IP address. Thus I solved the external theft problem.
But another issue is that, that if someone who is logged in using his jwt (means his IP is in ip-restriction whitelist) and then he steals my jwt. Now he will be able to impersonate me because he has a valid JWT (that is mine, not his) and an IP listed in whitelist.
I am eagerly looking out to solve this issue. If in case you can help me I will highly appreciate it.
Thanks and regards,
Rohit
You need to rethink your security model. Associating JWTs to IPs is not a reliable way to do it.
The client connects to the authorization server (1) and obtains a token (2), which is then used to authenticate to your APIs (3). If the communication in these three steps is encrypted via HTTPS, only these three parties ever have access to the token.
Also, access tokens should be short-lived. Refresh tokens, on the other hand, can be longer-lived. Read more about it here: