@stevenroose @berkes Rate-limiting makes sense here, but need to check carefully that interactive use cases like GitNex client apps are not impacted.

@stevenroose @berkes one request per 5sec possibly a bit tight for interactive use, at the same time one spam issue comment every 5 seconds already quite a lot

Follow

@codeberg @stevenroose rate-limiting based on a combination of session (ID in headers?), IP and 'user' often works.

X/session/minute
Y/user/minute
Z/IP/minute

Where Z > X, Z > Y. And Y > X.

For rails, I always use github.com/jeremy/rack-ratelim. There might be something in go, that can be integrated in gitea. Or agnostic proxy that is as flexible and tunable.

Though a proxy has no knowledge of things like 'user' or 'customer'.

@codeberg also note that typically, rate limiting for GET request can be an order of magnitute more lenient than for PUT/patch/POST/DELETE.

E.g. where you say: per IP we allow 100.000 read (GET) requests per hour, but only 100 writes (post etc ) per hour.

Sign in to participate in the conversation
Bitcoin Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!