Custom abuse limits

[gewenyu99]

👋 Hi friends,

Having configurable rate limits has been a long-standing issue for Appwrite. See: #2953

As Appwrite matures, this issue has bubbled to the top of our concerns, and we've come up with a plan to address this problem.

As always, we're looking to discuss our ideas thoroughly with the community to make sure the solution fits everyone's unique development needs. We'll actively monitor this discussion until Feb. 4th. Everyone's comments will be combined and turned into an RFC and implemented in a later release.

Here's the current proposal from the team as a basis for discussion.

Custom abuse limit

The ability to customize abuse limits has become an important issue for Appwrite Cloud users. Everyone's apps have different needs and definitions for what constitutes as "abusive". Some apps might expect users to delete or create hundreds or thousands of documents at a time. Other apps might expect hundreds of users to share the same IP through an VPN. Appwrite should be flexible enough to let developers decide what is "abusive".

Auth abuse limits

Authentication rate limits are used for security.

• Cannot be disabled, could cause serious security vulnerabilities
• Limited customization (limited range of values for attempts and time)
• Allow customization of “Abuse keys”, see below sections for explanation.
• Some want to disable rate limits during development. This is a separate issue, maybe we can add a toggle for a project to be on "development mode"

Resource abuse limits

Resource abuse limits are less for security and more to prevent abusive behavior like spamming endpoints to make them slow, writing or deleting large amounts of data to make projects run out of resources, etc.

Limits are applied to Client SDKs, Server SDKs with API keys are not limited.

For each resource, you can configure the following for a rate limit.

• Enabled/disabled
• Attempts - How many attempts before you hit a limit?
  • For Cloud, there will be a ceiling to protect Cloud Databases. As we expand our plans and infrastructure, we can raise this upper limit slowly.
  • For self-hosted, this limit can be configurable for each self-hosted instance through an environment variable.
• Time - Time range to allow the defined number of attempts

Below are the different configurable parts of a resource limit.

Per resource

You can define abuse limit behavior for these top-level resources. This means you configure abuse behavior for the entire collection or bucket, instead of configuring per endpoint for the sake of simplicity.

• Functions
• Buckets
• Collections
• Other products introduced later, like messaging or hosting.

Per action (multiple answers)

Define limits on all of the following actions (or have multiple).

• Create
• Read
• Update
• Delete

Abuse keys

Abuse limits are applied to each unique abuse key. Abuse keys are created with an AND operator between them, multiple rules allowed for or functionality.

You can create abuse keys with the following:

• Per IP
• Per user ID
• Per user email
• Per user phone
• Per request method
• Per request hostname
• Per request URL
• Per request path
• Per request param

Example

So, for example, you can have the following abuse key:

• Resource: Buckets
• Action: Create
• Abuse keys: Per user ID, Per IP
• Attempts: 100
• Time: 60 minutes

This limits you to 100 file uploads per hour, for each user ID or for each unique IP

Ways to configure

1. Using a wizard/card in the console, you can find the wizard/card in each resources' settings.
2. Using a Server SDK API
3. Using Appwrite.json

Let us know what you like and what you'd like to change. We'll try to engage in the discussions to get to the bottom of your unique needs.

[Kilo-Loco]

These improvements to Appwrite sound amazing and should definitely help with the existing limitations. My biggest concerns are around the DX of newcomers to Appwrite:

• Awareness: Highlighting the fact that the default limitations are set when a new user is getting up and running.
• Ease of configuration: When a user does want to change the default settings, they should be guided with examples as to what limitations are recommended for common workflows.
• Testing: How will these configurable limits be tested by the developer before shipping to production?

Flexibility and scalability are major factors that should be addressed, but we also need to make sure it's not at the expense of making Appwrite accessible to developers of all skill levels.

[gewenyu99]

Highlighting the fact that the default limitations are set when a new user is getting up and running.

I think this is something we could work on adding to the overview of each product.

[DH-555]

I think best approach could be something like Cloudflare is doing: rate limit rules.

This way you get a huge flexibility and you're able to block exactly what you want to.

In other words, you can set a rule to block an user per IP address if it hits 100 requests per second in the login endpoint, but you can define the rule to block instead per IP address per account/email. You can also set conditions based on the user agent, IP address, etc. This is pretty good for applications like when you're having a network from a company. That way you can whitelist the company network IP address or set up a custom rate limit for such specific IP address.

You can also setup the cooldown for example.
That way you have a huge flexibility and it's easy to setup and understand at the same time. There could be predefined ones for endpoints like login.

Example:

I think It's important to highlight in database adding custom limits to the amount of documents you can retrieve with one single request, since it's not the same doing 10 requests to get 10 document with each request than doing 10 requests to get 200000 documents with each request, so basically setting a limit for the Query.limit() query server-sided

[Kilo-Loco]

I really like how this flow is laid out in an easy to read format. Plain English end result that makes it easy to understand exactly what will happen and when. Just need that pink design

[DH-555]

Yes, also to comment, it would be great to have some kind of logs or stats like a graph on rate limits so you can have more insights to see if they're effective or if they're blocking traffic that should not been blocked

[DH-555]

Also, regarding configuring through appwrite.json, etc, I think it's a bit unnecessary, but it's more of a personal preference 😅

Maybe it's useful for someone 🤷

[gewenyu99]

This is similar to the direction we're thinking, we might start with something much simpler than this first time around, but this is really good suggestion to have.

[gewenyu99]

Yes, also to comment, it would be great to have some kind of logs or stats like a graph on rate limits so you can have more insights to see if they're effective or if they're blocking traffic that should not been blocked

This is really good feedback, will take into account!

[sonicviz]

Great idea, good to see.

The main issue I ran into so far was the email limits with cloud AW which impacted testing when you're iterating on some registration/signup flows or other login initialisation testing requirements.

Some want to disable rate limits during development. This is a separate issue, maybe we can add a toggle for a project to be on "development mode"

Yes, please. Like Stripe has a test mode for their API. I ended up installed local docker AW and turning off the rate limit for Auth for testing.

As for resource, doing more testing now on those aspects so will keep this in mind while testing for any feedback.

[gewenyu99]

Thanks!

[gewenyu99]

Taking these ideas and moving them forward with the team. An RFC will be written later and added to our road map. Thanks all for your input!

[DerLeole]

Any updates on this?

[ammarfaris]

@gewenyu99

[ammarfaris]

is there any update on this? @gewenyu99