mirror of
https://github.com/Unleash/unleash.git
synced 2024-12-22 19:07:54 +01:00
70499dc1d4
## About the changes When edge is configured to automatically generate tokens, it requires the token to be present in all unleash instances. It's behind a flag which enables us to turn it on on a case by case scenario. The risk of this implementation is that we'd be adding load to the database in the middleware that evaluates tokens (which are present in mostly all our API calls. We only query when the token is missing but because the /client and /frontend endpoints which will be the affected ones are high throughput, we want to be extra careful to avoid DDoSing ourselves ## Alternatives: One alternative would be that we merge the two endpoints into one. Currently, Edge does the following: If the token is not valid, it tries to create a token using a service account token and /api/admin/create-token endpoint. Then it uses the token generated (which is returned from the prior endpoint) to query /api/frontend. What if we could call /api/frontend with the same service account we use to create the token? It may sound risky but if the same application holding the service account token with permission to create a token, can call /api/frontend via the generated token, shouldn't it be able to call the endpoint directly? The purpose of the token is authentication and authorization. With the two tokens we are authenticating the same app with 2 different authorization scopes, but because it's the same app we are authenticating, can't we just use one token and assume that the app has both scopes? If the service account already has permissions to create a token and then use that token for further actions, allowing it to directly call /api/frontend does not necessarily introduce new security risks. The only risk is allowing the app to generate new tokens. Which leads to the third alternative: should we just remove this option from edge? |
||
|---|---|---|
| .. | ||
| api/legacy/unleash | ||
| integrations | ||
| sdks | ||
| activation-strategies.md | ||
| api-tokens-and-client-keys.mdx | ||
| archived-toggles.md | ||
| banners.md | ||
| change-requests.md | ||
| custom-activation-strategies.md | ||
| dependent-features.md | ||
| environments.md | ||
| event-log.md | ||
| event-types.mdx | ||
| feature-flag-naming-patterns.mdx | ||
| feature-toggle-types.md | ||
| feature-toggle-variants.md | ||
| feature-toggles.mdx | ||
| front-end-api.md | ||
| impression-data.md | ||
| login-history.md | ||
| maintenance-mode.mdx | ||
| network-view.mdx | ||
| notifications.md | ||
| playground.mdx | ||
| project-collaboration-mode.md | ||
| projects.md | ||
| public-signup.mdx | ||
| rbac.md | ||
| search-operators.md | ||
| segments.mdx | ||
| service-accounts.md | ||
| sso.md | ||
| stickiness.md | ||
| strategy-constraints.md | ||
| strategy-variants.md | ||
| tags.md | ||
| technical-debt.md | ||
| unleash-context.md | ||
| whats-new-v4.md | ||