Rate Limiting

[Teodor]

Intro

Rate limiting is essential for managing incoming requests to a server, preventing abuse, and ensuring stability. It controls the rate at which users can make requests, typically by setting limits per session or IP address within a set time frame.

Our flexible rate limiting for Server Connect API actions allows you to enable this feature globally, specify duration and points per user/IP, and customize points for logged-in users. You can also adjust points for specific routes and actions, such as consuming more points for failed login attempts to prevent abuse.

NOTE: Rate Limiting is only available for NodeJS

Global Rate Limiting

To enable rate limiting open the Server Connect settings:

Click Rate Limit:

And Enable Rate Limiting:

You can see two options here - duration and points. By default one request equals one point, so the user can have as many requests as defined for the specific duration:

Be careful with the limits you set, especially for public facing pages with many server actions on them. For example - If you have 5 server actions that execute on page load, this means each time you request the page, 5 points will be consumed by the user, so set these wisely.

You can se different (more generous) limits for the logged in users on your site. If you choose to set rate limits for them enable the Logged In Users option:

Select the Security Provider used for logging users in and set the duration and limits for them:

Custom Rate Limiters

You can also define custom rate limiters in Server Connect and use them instead of the global one. That's useful when you need to have different rate limits for different actions.

Open Globals in the Server Connect panel and you will see the Rate Limiters:

Right click the Rate Limiters and add a new one:

Give the rate limiter a name:

And you can find its properties in the Properties panel. By default one request equals one point, so the user can have as many requests as defined for the specific duration. Here you can also set the block duration (in seconds) - this is the duration that user should be blocked after reaching the limit:

You can define as many custom rate limiters as you need:

Consume Action

You can use the Consume step in your Server Actions to set custom Consume points after specific steps/actions.

In your server action add a new step, after the step you want to set the custom consume points:

Select Consume Rate Limiter:

Then select the Rate Limiter which points this step should consume:

This can be the Global one, defined in Server Connect Global Settings or any of the Custom Rate Limiters you create in Server Connect panel:

Enter the amount of points this action should consume:

You can enter a status and custom message to be returned, when the rate is exceeded:

Enable the Throw option to throw an error when the rate limit is exceeded:

Overriding Limits per Route

You can override the default Rate Limits per route. All you need to do is to select your Server Action, click Settings and set the amount of points it should consume. Set 0 if you want to disable rate limiting for this server action:

These are the basics of Rate Limiting in Wappler.

[scott]

Interesting. Any thoughts on connecting this to the Security Provider so we could set different rates based on groups? i.e. an Admin or Staff member would consume more than a Regular member would.

[Teodor]

Well i am not sure this makes much sense it’s more for security protection than limiting your users.

[scott]

Just thinking about how to implement this properly. Looks like I can use the Consume in Library actions and set it to zero for Admin and Staff that might have a higher number of actions than regular members.

Question @Teodor: What hapens if someone hits the rate limit? Is there a message displayed to the user or do they just get an error page of some kind ?

[Teodor]

Yes they see “Too many requests” error

[scott]

haha that was fun! I hit the limit! However, the error is in the network tab, not on the page. Is there something that we would need to do to display it to the user?

Maybe I could do something with the 429 error via a response.

[Teodor]

You can return the error the same way as any other error message.

[patrick]

We can perhaps have some retry or special event on the serverconnect component to handle the rate limit responses. Currently you just have to handle it as an error.

[brad]

I'm not clear on why someone would want to limit their users? There is no way I would want to limit our staff from using our dashboards. What happens when they reach the limit and how long before they can use the site again?

I likely just don't understand this feature. I just don't get why you would limit usage?

[scott]

A Denial of Service (DOS) attaack is one reason. Another is to lessen the load on the server if you have a very popular event happening and you want to prevent people from refreshing the page constantly.

The default setting is 100 sever actions in 60 seconds. That's an awful lot of activity in a short time for one user. But those numbers are adjustable and you can have a second set of numbers if the user is logged in.

Try it like I did and you will see how really hard it is to reach that limit. I had to work at it by quickly refreshing my page repeatedly.

The restriction lasts as long as whatever duration you set, in the default setting 60 seconds. So, if you manage to hit the limit, you would be prevented from seeing the results of server actions for that amount of time.

The reality is that you should very very rarely see this ever take effect, its a safeguard to protect your site/project in case something happens.