### What
This PR makes the rate limit for user creation and simple login (our
password based login) configurable in the same way you can do
metricsRateLimiting.
### Worth noting
In addition this PR adds a `rate_limit{endpoint, method}` prometheus
gauge, which gets the data from the UnleashConfig.
### What
The heaviest requests we serve are the register and metrics POSTs from
our SDKs/clients.
This PR adds ratelimiting to /api/client/register, /api/client/metrics,
/api/frontend/register and /api/frontend/metrics with a default set to
6000 requests per minute (or 100 rps) for each of the endpoints.
It will be overrideable by the environment variables documented.
### Points of discussion
@kwasniew already suggested using featuretoggles with variants to
control the rate per clientId. I struggled to see if we could
dynamically update the middleware after initialisation, so this attempt
will need a restart of the pod to update the request limit.
This PR replaces references to _addons_ in the docs with references to
_integrations_.
In doing so, I have also:
- moved `/reference/addons` documents into `/reference/integrations`
- combined the previous "Addons" and "Integrations" categories into a
new "Integrations" category
- added redirects from all the old addons pages to their new locations
I have updated the wording, but have not changed things such as API
paths, event names, etc, because these will not change at the moment
(maybe a breaking change to schedule for v6?).
---------
Co-authored-by: Tymoteusz Czech <2625371+Tymek@users.noreply.github.com>
Fix issues uncovered when reviewing integrations list and form.
- YouTube CSP
- Text content and formatting
- Margins
- Update old integration icons
- Fix headers in dark theme
As requested in
[Linear](https://linear.app/unleash/issue/2-1147/unleash-cloud-make-keepalive-configurable)
this PR makes the serverKeepAliveTimeout configurable via the
SERVER_KEEPALIVE_TIMEOUT environment variable. This was already
configurable when starting Unleash programmatically, but it's nice to
have as an env variable as well
### What
Since 3ed4aeba5c, we've updated the
segment limits and added separate limits for pro and enterprise. This PR
updates the docs with the new limits.
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
## About the changes
Make it explicit that eventHook is no longer an option in v5, the
migration should be to
https://docs.getunleash.io/reference/addons/webhook which is already
linked in the docs since v4
## About the changes
Update `passord` documentation with `password`. Note this was not a typo
but just Norwegian:
https://dictionary.cambridge.org/dictionary/english-norwegian/password
```shell
grep passord * -R -l | grep -v .git | grep -v dist | grep -v v3 | xargs sed -i 's/passord/password/g'
```
The script above avoids updating v3 because of legacy reasons
Related to #1265
This PR updates the docs to clarify that we don't support multi-host
strings in the databaseUrl configuration variable.
The docs used to just mention that we accept libpq strings, but as
reported in #3221, we **don't** support multi-host strings.
I did some digging and found that this is because [node-postgres -- the
library we use to connect to postgres -- itself does not support
multi-host
strings](https://github.com/brianc/node-postgres/issues/2308).
To fix this, we would need to replace the library we use or otherwise
wrap it. While this would be a better long-term solution, we don't have
the capacity to it right now. But we can update the docs to better
reflect reality.
## About the changes
- Updates the segment information on top to be clearer - No longer an
experimental feature, but we do have some limits in place;
- Also updates the documentation to better reflect this;
Co-authored-by: @thomasheartman
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
Co-authored-by: Gastón Fournier <gaston@getunleash.ai>
## What
Adds environment variable equivalents for remaining authentication
options.
Also reformats the list silghtly.
## Why
Because the `AUTH_TYPE` and `AUTH_ENABLE_API_TOKEN` variables hadn't
been previously mentioned and we get questions about this from time to
time.
The reformat is primarily for using `monospace font` where appropriate.
## About the changes
This makes response time with app names enabled for everyone but also
kept a way of turning it off (kill switch) in case it cause some issues
because of misconfigured app names
* This PR adds a configurable maxAge header to the CORS middleware. This
allows the preflight request to be cached so that we can reduce the
request load on our end for the frontend clients starting to utilise the
frontend api.
## What
This (admittedly massive) PR updates the "physical" documentation
structure and fixes url inconsistencies and SEO problems reported by
marketing. The main points are:
- remove or move directories : advanced, user_guide, deploy, api
- move the files contained within to the appropriate one of topics,
how-to, tutorials, or reference
- update internal doc links and product links to the content
- create client-side redirects for all the urls that have changed.
A number of the files have been renamed in small ways to better match
their url and to make them easier to find. Additionally, the top-level
api directory has been moved to /reference/api/legacy/unleash (see the
discussion points section for more on this).
## Why
When moving our doc structure to diataxis a while back, we left the
"physical' files lying where they were, because it didn't matter much to
the new structure. However, that did introduce some inconsistencies with
where you place docs and how we organize them.
There's also the discrepancies in whether urls us underscores or hyphens
(which isn't necessarily the same as their file name), which has been
annoying me for a while, but now has also been raised by marketing as an
issue in terms of SEO.
## Discussion points
The old, hand-written API docs have been moved from /api to
/reference/api/legacy/unleash. There _is_ a /reference/api/unleash
directory, but this is being populated by the OpenAPI plugin, and mixing
those could only cause trouble. However, I'm unsure about putting
/legacy/ in the title, because the API isn't legacy, the docs are. Maybe
we could use another path? Like /old-docs/ or something? I'd appreciate
some input on this.
