chore: refactored rate-limit docs, added endpoint-based page and over… #1896
Conversation
| IP address as a key criterion, allowing Ory to identify and block requests originating from suspicious or malicious sources. | ||
| 2. By analyzing request patterns and incorporating factors like source IP, Ory can effectively differentiate between legitimate | ||
| user traffic and potentially harmful bot activity. | ||
|
|
There was a problem hiding this comment.
I think this lacks certain clarification, as in the Project based rate limits we also distinguish based on certain paths/endpoints.
Maybe we should rephrase this as Project Tier based Rate Limits vs System/Global Endpoint based, which i would describe as system guardrails that work in tandem with the project tiers, but are global and unless specified in a contract, are the global maximum regardless of project tier.
|
|
||
| ## Introduction | ||
|
|
||
| This page provides a comprehensive explanation of Ory's Project-Based Rate Limiting. These limits are designed to ensure fair |
There was a problem hiding this comment.
| This page provides a comprehensive explanation of Ory's Project-Based Rate Limiting. These limits are designed to ensure fair | |
| This page provides a comprehensive explanation of Ory's Project Tier-Based Rate Limiting. These limits are designed to ensure fair |
| Project-Based Rate Limits analyze incoming requests across your entire project and consider factors such as: | ||
|
|
||
| - **Project Plan:** Different plans (Developer, Production, Growth, Enterprise) have different rate limit thresholds. | ||
| - **Environment:** Limits may vary between Production, Staging, and Workspace environments. |
There was a problem hiding this comment.
This is not fully true, the difference between development and stage is mostly in features, and not rates. We had situations where clients would change their projects from dev to stage in hopes to increase their limits which caused confusion.
There was a problem hiding this comment.
| - **Environment:** Limits may vary between Production, Staging, and Workspace environments. | |
| - **Environment:** Limits are low for Development and Staging environments, and high for Production environments. |
maybe this?
what is a workspace env? does that mean the difference of rate limit on workspace/project level?
| | | `/relation-tuples/check` | 800 | 18000 | | ||
| | | `GET /admin/identities` | 20 | 600 | | ||
| | | `*` | 400 | 9000 | | ||
| | **Staging** | `/sessions/whoami` | 10 | 30 | |
There was a problem hiding this comment.
staging has currently the same rates as dev, therefore i dont think it make sense to repeat that here. Clients already did assume that staging has more rates than developer in the past, so this need to be clarified better
| ### Workspace Rate Limit | ||
|
|
||
| For all projects in a workspace, the rate limit is the same as for the production environment of your plan. For example, on the | ||
| Production plan, the rate limit would be 80 rps on the `/sessions/whoami` path for all projects combined in the workspace. |
There was a problem hiding this comment.
Are you sure about that? Clients had a single workspace with both prod and dev projects, and they had ratelimit keys based only on the project tier. Our envoy based config has no information about workspaces, only project data
|
|
||
| Endpoint-Based Rate Limits are precise controls applied to individual API endpoints within your Ory projects. Unlike Project-Based | ||
| Rate Limits, which govern overall project request volumes, Endpoint-Based Rate Limits focus on safeguarding specific | ||
| functionalities against abuse. |
There was a problem hiding this comment.
I would rephrase this as system wide rules, which are menat to protect the system, and are a global limit which unless stated in an enterprise contract, cannot be broken regardless of project tier
Related Issue or Design Document
Checklist
If this pull request addresses a security vulnerability,
I confirm that I got approval (please contact [email protected]) from the maintainers to push the changes.
Further comments