Rate limiting websocket messages

awiteb commented

2024-07-07 16:00:50 +02:00

Owner

Now, the websocket server is not rate limiting the messages. This can be a
problem if a user sends a lot of messages in a short period of time. This can be
used to spam the server and cause a denial of service.

I think about storing the connection ratelimit data in the SocketUserData
struct, and then check if the user has reached the limit before handling its
message.

Now, the websocket server is not rate limiting the messages. This can be a problem if a user sends a lot of messages in a short period of time. This can be used to spam the server and cause a denial of service. I think about storing the connection ratelimit data in the `SocketUserData` struct, and then check if the user has reached the limit before handling its message.

awiteb added the

labels 2024-07-07 16:00:50 +02:00

awiteb commented

2024-07-07 16:01:48 +02:00

Author

Owner

@Amjad50, what do you think is better, using limit and period_secs from the ratelimit section in the config file, or creating a new configuration for the websocket rate limit?

@Amjad50, what do you think is better, using `limit` and `period_secs` from the `ratelimit` section in the config file, or creating a new configuration for the websocket rate limit?

Amjad50 commented

2024-07-07 16:47:21 +02:00

Member

it seems fine to use the same config file, since its the server config. why would you want to use a new file specifically for rate limiting?

Also, if this is per connection, maybe its better to include this in the name, like connection_ratelimit.

it seems fine to use the same config file, since its the server config. why would you want to use a new file specifically for rate limiting? Also, if this is per connection, maybe its better to include this in the name, like `connection_ratelimit`.

Amjad50 commented

2024-07-07 16:51:28 +02:00

Member

Another thing I thought about, would it be interesting idea to also add limit to number of connections? I know ws is light and we can handle many, but just to fend against half open connections attacks

awiteb commented

2024-07-07 16:52:55 +02:00

Author

Owner

why would you want to use a new file specifically for rate limiting?

Not new file, new configuration, like you say connection_ratelimit under ratelimit section.

So the new configurations will be

connection_limit under ratelimit section
connection_period_secs under ratelimit section

> why would you want to use a new file specifically for rate limiting? Not new file, new configuration, like you say `connection_ratelimit` under `ratelimit` section. So the new configurations will be - `connection_limit` under `ratelimit` section - `connection_period_secs` under `ratelimit` section

awiteb commented

2024-07-07 16:54:11 +02:00

Author

Owner

Another thing I thought about, would it be interesting idea to also add limit to number of connections? I know ws is light and we can handle many, but just to fend against half open connections attacks

There is an issue for this: #11

> Another thing I thought about, would it be interesting idea to also add limit to number of connections? I know ws is light and we can handle many, but just to fend against half open connections attacks There is an issue for this: https://git.4rs.nl/OxideTalis/oxidetalis/issues/11

🚀 1

Amjad50 commented

2024-07-07 16:56:55 +02:00

Member

So the new configurations will be

connection_limit under ratelimit section

connection_period_secs under ratelimit section

The current configuration is

[ratelimit]
enable = true
limit = 1500
period_secs = 60

So it would be like this?

[ratelimit]
enable = true
connection_limit = 1500
connection_period_secs = 60

or keep the old fields and add these new ones?

> So the new configurations will be > > - `connection_limit` under `ratelimit` section > - `connection_period_secs` under `ratelimit` section > The current configuration is ```toml [ratelimit] enable = true limit = 1500 period_secs = 60 ``` So it would be like this? ```toml [ratelimit] enable = true connection_limit = 1500 connection_period_secs = 60 ``` or keep the old fields and add these new ones?

awiteb commented

2024-07-07 17:01:31 +02:00

Author

Owner

So it would be like this?

[ratelimit]
enable = true
connection_limit = 1500
connection_period_secs = 60

No, it will be:

[ratelimit]
enable = true
# For http requests
limit = 1500
period_secs = 60
# For websocket messages
connection_limit = 1500
connection_period_secs = 60

> So it would be like this? > ```toml > [ratelimit] > enable = true > connection_limit = 1500 > connection_period_secs = 60 > ``` No, it will be: ```toml [ratelimit] enable = true # For http requests limit = 1500 period_secs = 60 # For websocket messages connection_limit = 1500 connection_period_secs = 60 ```

Amjad50 commented

2024-07-07 17:04:34 +02:00

Member

ah, sorry got confused
then, I think we can put them separate, and we can even use the same structure to make it clear which is websocket and which is http, the name connection isn't clear, something like this

[ratelimit.http]
limit = 1500
period_secs = 60

[ratelimit.websocket]
limit = 1500
period_secs = 60

ah, sorry got confused then, I think we can put them separate, and we can even use the same structure to make it clear which is websocket and which is http, the name `connection` isn't clear, something like this ``` [ratelimit.http] limit = 1500 period_secs = 60 [ratelimit.websocket] limit = 1500 period_secs = 60 ```

🚀 1

awiteb commented

2024-07-07 17:07:13 +02:00

Author

Owner

and we can even use the same structure to make it clear which is websocket and which is http

I like this, agreed

> and we can even use the same structure to make it clear which is websocket and which is http I like this, agreed

awiteb added

and removed

labels 2024-07-16 15:42:58 +02:00

Rate limiting websocket messages #12