mirror of
https://github.com/Unleash/unleash.git
synced 2025-08-13 13:48:59 +02:00
Fix more pagination issues
This commit is contained in:
parent
6ee0715fab
commit
a20e28db88
@ -10,8 +10,8 @@ Unleash provides a set of APIs to give you full programmatic control over your f
|
||||
|
||||
| API | Used by | Primary use case |
|
||||
|---------------|---------|---|
|
||||
| **Client API** | Server-side SDKs | Fetch all feature flag configurations. |
|
||||
| **Frontend API** | Client-side SDKs | Fetch evaluated feature flags for a specific [Unleash Context](/reference/unleash-context). |
|
||||
| **Client API** | Server-side SDKs | Fetch feature flag configurations. |
|
||||
| **Frontend API** | Client-side SDKs | Fetch enabled feature flags for a specific [Unleash Context](/reference/unleash-context). |
|
||||
| **Admin API** | [Admin UI](#the-unleash-admin-ui), internal tooling, and third-party [integrations](/reference/integrations) | Access and manage all resources within Unleash, such as context, environments, events, metrics, and users. |
|
||||
|
||||
## API authentication and tokens
|
||||
@ -21,8 +21,8 @@ All Unleash APIs require authentication using an [API token](/reference/api-toke
|
||||
### Token types
|
||||
|
||||
Unleash supports four types of API tokens:
|
||||
- **Client tokens**: Used to connect server-side SDKs, Unleash Edge, and the Unleash Proxy to the Client API. They are typically scoped to a specific project and environment.
|
||||
- **Frontend tokens**: Used to connect client-side SDKs to the Frontend API or Unleash Edge. These tokens are designed to be publicly accessible and have limited permissions.
|
||||
- **Client tokens**: Used to connect server-side SDKs, Unleash Edge, and the Unleash Proxy to the Client API. Can be scoped to a specific project and environment.
|
||||
- **Frontend tokens**: Used to connect client-side SDKs to the Frontend API or Unleash Edge. These tokens are designed to be publicly accessible and have limited permissions. Can be scoped to a specific project and environment.
|
||||
- **Personal access tokens**: Tied to a specific user account. They are useful for testing, debugging, or providing temporary access to tools and scripts that need to interact with the Admin API.
|
||||
- **Service account tokens**: The recommended method for providing API access to integrations, automation tools, and other non-human users. Service accounts provide a more secure and manageable way to grant Admin API access.
|
||||
|
||||
@ -36,7 +36,7 @@ Ensure that the client token has access to the same project and environment (or
|
||||
|
||||
### Create an API token
|
||||
|
||||
Depending on your permissions, you can create API tokens in the Unleash Admin UI in three ways:
|
||||
Depending on your permissions, you can create API tokens in the Unleash Admin UI in four ways:
|
||||
|
||||
- **Admin settings > Access control > API access**: for client or frontend tokens; requires the Admin root role, or a custom root role with API token permissions.
|
||||
- **Admin settings > Service accounts > New service account**: for creating a service account and assigning a token.
|
||||
|
@ -1,6 +1,7 @@
|
||||
---
|
||||
title: How to do A/B testing using feature flags
|
||||
title: Implement A/B testing using feature flags
|
||||
slug: /feature-flag-tutorials/use-cases/a-b-testing
|
||||
pagination_next: feature-flag-tutorials/use-cases/ai
|
||||
---
|
||||
|
||||
Feature flags are a great way to run A/B or multivariate tests with minimal code modifications, and Unleash offers built-in features that make it easy to get started. In this tutorial, we will walk through how to do an A/B test using Unleash with your application.
|
||||
|
@ -1,6 +1,5 @@
|
||||
---
|
||||
title: How to use feature flags with AI
|
||||
slug: /feature-flag-tutorials/use-cases/ai
|
||||
title: Experiment with AI using feature flags
|
||||
---
|
||||
|
||||
Hello,
|
||||
|
@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Create a feature flag
|
||||
title: Create and configure a feature flag
|
||||
description: 'This guide shows you how to create feature flags in Unleash and how to add constraints, segments, variants, and more.'
|
||||
slug: /how-to-create-feature-flag
|
||||
pagination_next: how-to/how-to-schedule-feature-releases
|
||||
|
@ -1,5 +1,5 @@
|
||||
---
|
||||
title: How to do trunk-based development using feature flags
|
||||
title: Implement trunk-based development using feature flags
|
||||
slug: /feature-flag-tutorials/use-cases/trunk-based-development
|
||||
---
|
||||
|
||||
|
@ -1,6 +1,7 @@
|
||||
---
|
||||
title: How to implement user management, access controls, and auditing with feature flags
|
||||
title: Implement user management, access controls, and auditing with feature flags
|
||||
slug: /feature-flag-tutorials/use-cases/user-management-access-controls-auditing
|
||||
pagination_next: feature-flag-tutorials/use-cases/security-compliance
|
||||
---
|
||||
|
||||
Feature flags are a game-changer for how software teams build, test, and release products. They enable you to roll out new features with confidence, manage risk, and keep your software development agile and secure.
|
||||
|
@ -1,5 +1,5 @@
|
||||
---
|
||||
title: 'Google'
|
||||
title: 'Set up SSO with Google'
|
||||
description: Set up SSO for Unleash with Google.
|
||||
---
|
||||
|
||||
|
@ -1,6 +1,7 @@
|
||||
---
|
||||
title: Set up SSO with OpenID Connect
|
||||
description: Set up SSO for Unleash with OpenID Connect.
|
||||
pagination_next: how-to/how-to-add-sso-saml
|
||||
---
|
||||
|
||||
:::note Availability
|
||||
|
@ -2,9 +2,21 @@
|
||||
title: How to create API Tokens
|
||||
---
|
||||
|
||||
Depending on your [permissions](../reference/api-tokens-and-client-keys#api-token-permissions), you can create API tokens in the Unleash Admin UI in three ways:
|
||||
All Unleash APIs require authentication using an [API token](/reference/api-tokens-and-client-keys). The type of token you use depends on the API you are accessing and your specific use case.
|
||||
|
||||
### Token types
|
||||
|
||||
Unleash supports four types of API tokens:
|
||||
- **Client tokens**: Used to connect server-side SDKs, Unleash Edge, and the Unleash Proxy to the Client API. Can be scoped to a specific project and environment.
|
||||
- **Frontend tokens**: Used to connect client-side SDKs to the Frontend API or Unleash Edge. These tokens are designed to be publicly accessible and have limited permissions. Can be scoped to a specific project and environment.
|
||||
- **Personal access tokens**: Tied to a specific user account. They are useful for testing, debugging, or providing temporary access to tools and scripts that need to interact with the Admin API.
|
||||
- **Service account tokens**: The recommended method for providing API access to integrations, automation tools, and other non-human users. Service accounts provide a more secure and manageable way to grant Admin API access.
|
||||
|
||||
### Create an API token
|
||||
|
||||
Depending on your permissions, you can create API tokens in the Unleash Admin UI in four ways:
|
||||
|
||||
- **Admin settings > Access control > API access**: for client or frontend tokens; requires the Admin root role, or a custom root role with API token permissions.
|
||||
- **Settings > API access** inside a project: for project-specific client or frontend tokens; permitted for project Members or users with a [corresponding root role](../reference/api-tokens-and-client-keys#api-token-permissions).
|
||||
- **Admin settings > Service accounts > New service account**: for creating a service account and assigning a token.
|
||||
- **Settings > API access** [inside a project]: for project-specific client or frontend tokens; permitted for project Members or users with a corresponding root role.
|
||||
- **Profile > View profile settings > Personal API tokens**: for personal access tokens.
|
||||
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Environment Import & Export
|
||||
title: Environment import and export
|
||||
---
|
||||
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
---
|
||||
title: How to schedule feature releases
|
||||
title: Schedule feature releases
|
||||
---
|
||||
import ApiRequest from '@site/src/components/ApiRequest'
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Set up Okta provisioning
|
||||
pagination_next: how-to/how-to-setup-provisioning-with-okta
|
||||
pagination_next: how-to/how-to-setup-provisioning-with-entra
|
||||
---
|
||||
|
||||
:::note Availability
|
||||
|
@ -1,5 +1,6 @@
|
||||
---
|
||||
title: Quickstart
|
||||
pagination_next: topics/what-is-a-feature-flag
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
|
@ -137,8 +137,9 @@ be44368985f7fb3237c584ef86f3d6bdada42ddbd63a019d26955178
|
||||
|
||||
## Create an API token
|
||||
|
||||
Depending on your [permissions](#api-token-permissions), you can create API tokens in the Unleash Admin UI in three ways:
|
||||
Depending on your [permissions](#api-token-permissions), you can create API tokens in the Unleash Admin UI in four ways:
|
||||
- **Admin settings > Access control > API access**: for client or frontend tokens; requires the Admin root role, or a custom root role with [API token permissions](#api-token-permissions).
|
||||
- **Admin settings > Service accounts > New service account**: for creating a service account and assigning a token.
|
||||
- **Settings > API access** inside a project: for project-specific client or frontend tokens; permitted for project Members or users with a [corresponding root role](#api-token-permissions).
|
||||
- **Profile > View profile settings > Personal API tokens**: for [personal access tokens](#personal-access-tokens).
|
||||
|
||||
|
@ -25,7 +25,7 @@ For each login event, it lists:
|
||||
|
||||
Login history events are kept for 336 hours (14 days). Events older than this retention period are automatically deleted and cannot be recovered. If you need to retain login event information for a longer period, consider periodically [downloading login history](#download-login-history).
|
||||
|
||||
# Download login history
|
||||
## Download login history
|
||||
|
||||
To download the login history, go to the login history page and click **Download login history**.
|
||||
|
||||
|
@ -12,4 +12,4 @@ You can have only one active invite token at any given time. If an active token
|
||||
|
||||
As an Admin, you can create, update, and delete invite tokens through the Unleash Admin UI in **Admin settings > User config > Users > Create invite link**.
|
||||
|
||||
Alternatively, you can use [Admin API](../reference/api/unleash/public-signup-tokens.tag.mdx) to manage the public invite token.
|
||||
Alternatively, you can use the [Admin API](../reference/api/unleash/public-signup-tokens.tag.mdx) to manage the public invite token.
|
@ -211,8 +211,7 @@ Once you have the role set up, you can assign it to individual users inside a pr
|
||||
|
||||
### Project permissions
|
||||
|
||||
You can assign the following project permissions. These permissions are valid across all of the [project](./projects)'s
|
||||
environments.
|
||||
You can assign the following project permissions. These permissions are valid across all of the [project](./projects)'s environments.
|
||||
|
||||
#### API tokens
|
||||
| Permission Name | Description |
|
||||
@ -323,7 +322,7 @@ Groups themselves do not grant permissions. To be functional, a group must eithe
|
||||
A user can belong to multiple groups, and each group a user belongs to can have a different role assigned to it on a specific project.
|
||||
If a user gains permissions for a project through multiple groups, they will inherit the most permissive set of permissions from all their assigned group roles for that project.
|
||||
|
||||
## User group SSO integration
|
||||
## Set up group SSO syncing
|
||||
|
||||
:::note Availability
|
||||
|
||||
@ -331,23 +330,17 @@ If a user gains permissions for a project through multiple groups, they will inh
|
||||
|
||||
:::
|
||||
|
||||
User groups also support integration with your Single Sign-On (SSO) provider. This allows you to automatically assign
|
||||
users to groups when they log in through SSO. Check out [_how to set up group SSO
|
||||
sync_](../how-to/how-to-set-up-group-sso-sync.md) for a step-by-step walkthrough.
|
||||
You can integrate user groups with your single sign-on (SSO) provider to automatically manage user assignments.
|
||||
Note that this just-in-time process updates groups only when a user logs in, which differs from a full provisioning system like [SCIM](/how-to/how-to-setup-provisioning-with-okta) that syncs all user information proactively.
|
||||
|
||||
Users that have been added to a group through your SSO provider will be automatically removed next time they log in if
|
||||
they've been removed from the SSO group. Users that have been manually added to the group will not be affected.
|
||||
When a user logs in through SSO, they are automatically added to or removed from a user group based on their SSO group membership. Manually added users are not affected by the SSO sync.
|
||||
|
||||
To enable group sync, you'll need to set two fields in your SSO provider configuration options:
|
||||
To enable group syncing, you configure two settings in your SSO provider configuration:
|
||||
|
||||
- **enable group syncing**:
|
||||
- **Enable group syncing**: Turns the feature on.
|
||||
- **Group field JSON path**: A JSON path expression that points to the field in your SSO token response that contains the user's groups.
|
||||
|
||||
Turns on group syncing. This is disabled by default.
|
||||
|
||||
- **group field JSON path**
|
||||
|
||||
A JSON path that should point to the groups field in your token response. This should match the exact field returned
|
||||
by the provider. For example, if your token looks like this:
|
||||
For example, if your token response looks like this, you would set the Group field JSON path to `groups`:
|
||||
|
||||
```json
|
||||
{
|
||||
@ -366,12 +359,26 @@ To enable group sync, you'll need to set two fields in your SSO provider configu
|
||||
"nonce": "0394852-3190485-2490358"
|
||||
}
|
||||
```
|
||||
You need to set the "Group Field JSON path" to "groups".
|
||||
|
||||
After you enable syncing, you must link the SSO group names to the corresponding user group.
|
||||
|
||||
Once you've enabled group syncing and set an appropriate path, you'll need to add the SSO group names to the Unleash
|
||||
group. This can be done by navigating to the Unleash group you want to enable sync for and adding the SSO group names to
|
||||
the "SSO group ID/name" property.
|
||||
|
||||
### Configure SSO group sync
|
||||
|
||||
You must be an Admin in Unleash to perform these steps.
|
||||
|
||||
1. Go to **Admin settings > Single sign-on**. Select your integration and click **Enable Group Syncing**.
|
||||
2. in **Group Field JSON Path**, enter the JSON path for the groups field in your token response.
|
||||
3. Click **Save**.
|
||||
4. Go to **User config > Groups** and select the user group you want to sync and click **Edit**.
|
||||
5. Add the exact SSO group names or IDs you want to link to the group.
|
||||
6. Click **Save**.
|
||||
|
||||
The next time a user who belongs to one of the linked SSO groups logs in, they are automatically added to the user group. If they have been removed from the SSO group, their access will be revoked on their next login.
|
||||
|
||||
[^1]: The project-level permission is still required for the [**create/overwrite variants
|
||||
** (PUT)](/reference/api/unleash/overwrite-feature-variants) and [**update variants
|
||||
** (PATCH)](/reference/api/unleash/patch-feature-variants) API endpoints, but it is not used for anything
|
||||
|
@ -2,7 +2,6 @@
|
||||
title: What is a feature flag and why are feature flags used?
|
||||
slug: /what-is-a-feature-flag
|
||||
description: Feature flags let you control software features in real time, enabling safer deployments, better testing, and faster innovation.
|
||||
pagination_next: understanding-unleash/the-anatomy-of-unleash
|
||||
toc_max_heading_level: 2
|
||||
---
|
||||
|
||||
|
@ -127,4 +127,10 @@ If you are using Unleash Edge, CORS headers are typically configured via command
|
||||
|
||||
You can use the `curl` command-line tool to inspect the response headers from your Unleash instance and verify the CORS configuration. Replace `<host>` and `<endpoint>` with your Unleash server URL and a relevant API endpoint (e.g., the frontend API endpoint).
|
||||
|
||||
```bash
|
||||
|
||||
## I don't see an Unleash feature in the Admin UI
|
||||
|
||||
If a documented Unleash feature isn't showing up in your Admin UI, check the following:
|
||||
|
||||
- Is the feature included in your [Unleash plan and version](/availability)?
|
||||
- Is the feature in beta? If so, reach out to us to get early access.
|
@ -2,28 +2,29 @@
|
||||
title: Configuring Unleash to run over HTTPS
|
||||
---
|
||||
|
||||
Preferred methods for setting up HTTPS in self-hosted instances, from highly recommended to those requiring more caution:
|
||||
This guide outlines several methods for enabling HTTPS in your self-hosted Unleash instance.
|
||||
|
||||
## Load Balancer
|
||||
## Load balancer
|
||||
|
||||
The recommended and most robust method is to use a load balancer.
|
||||
|
||||
The best choice is to use a load balancer.
|
||||
A load balancer from a cloud provider renews the HTTPS certificates for you and keeps the data safe when it moves between the internet and your server.
|
||||
Also, your cloud provider's private network between your load balancer and the application is already encrypted.
|
||||
|
||||
## Sidecar
|
||||
|
||||
If you're using something like Kubernetes and need HTTPS to be handled right next to your Unleash app, use a sidecar pattern.
|
||||
|
||||
This method keeps the HTTPS handling separate from the Unleash application logic.
|
||||
Tools like [Istio](https://istio.io/), [Envoy](https://www.envoyproxy.io/), [HAProxy](https://www.haproxy.org/), or [Nginx](https://www.nginx.com/) can help by automatically updating certificates.
|
||||
|
||||
## Manual SSL termination in Unleash
|
||||
|
||||
Approach manual SSL termination within Unleash with caution.
|
||||
This direct control method over the SSL setup adds complexity and a maintenance burden that can be challenging to manage.
|
||||
Manually terminating SSL directly within the Unleash application should be avoided. This method introduces unnecessary complexity and high maintenance burden for managing certificates and ensuring secure configurations.
|
||||
|
||||
If you insist on having Unleash do HTTPS termination for you, you'll need to set that up yourself using:
|
||||
* http://expressjs.com/en/5x/api.html#app.listen
|
||||
* https://nodejs.org/api/https.html#httpscreateserveroptions-requestlistener
|
||||
If you must configure Unleash to handle HTTPS termination directly, you'll need to set it up using:
|
||||
- http://expressjs.com/en/5x/api.html#app.listen
|
||||
- https://nodejs.org/api/https.html#httpscreateserveroptions-requestlistener
|
||||
|
||||
Example:
|
||||
```javascript
|
||||
|
@ -18,7 +18,7 @@ const cardsData = [
|
||||
description:
|
||||
'Explore best practices and step-by-step tutorials to help you integrate Unleash into your stack.',
|
||||
icon: <TutorialsIcon />,
|
||||
href: '/feature-flag-tutorials/use-cases/gradual-rollout',
|
||||
href: '/topics/feature-flags/feature-flag-best-practices',
|
||||
},
|
||||
{
|
||||
title: 'SDKs',
|
||||
|
Loading…
Reference in New Issue
Block a user