mirror of
https://github.com/andwati/zitadel.git
synced 2026-10-18 05:52:51 +00:00
docs: remove typos (#11240)
removed typos from the doc pages Fixes: #11234
This commit is contained in:
Federico Coppede
+2
-2
@@ -6,8 +6,8 @@ The documentation is part of the ZITADEL monorepo and uses **pnpm** and **Nx** f
|
||||
|
||||
## Quick Start
|
||||
|
||||
Run the following commands from the repositorys root directory to install all dependencies needed.
|
||||
Using Corepack makes sure you have the pnpm version intalled that is declared in [](../package.json).
|
||||
Run the following commands from the repositories root directory to install all dependencies needed.
|
||||
Using Corepack makes sure you have the pnpm version installed that is declared in [](../package.json).
|
||||
|
||||
```bash
|
||||
corepack enable
|
||||
|
||||
@@ -6,7 +6,7 @@ This page describes the options you have when writing ZITADEL actions scripts.
|
||||
|
||||
## Language
|
||||
|
||||
ZITADEL interpretes the scripts as JavaScript.
|
||||
ZITADEL interprets the scripts as JavaScript.
|
||||
Make sure your scripts are ECMAScript 5.1(+) compliant.
|
||||
Go to the [goja GitHub page](https://github.com/dop251/goja) for detailed reference about the underlying library features and limitations.
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ title: Objects
|
||||
- `nickName` *string*
|
||||
- `displayName` *string*
|
||||
- `preferredLanguage` *string*
|
||||
In [RFC 5646](https://www.rfc-editor.org/rfc/rfc5646) fromat
|
||||
In [RFC 5646](https://www.rfc-editor.org/rfc/rfc5646) format
|
||||
- `email` *string*
|
||||
- `isEmailVerified` *boolean*
|
||||
- `phone` *string*
|
||||
@@ -71,7 +71,7 @@ title: Objects
|
||||
- `displayName` *string*
|
||||
- `avatarKey` *string*
|
||||
- `preferredLanguage` *string*
|
||||
In [RFC 5646](https://www.rfc-editor.org/rfc/rfc5646) fromat
|
||||
In [RFC 5646](https://www.rfc-editor.org/rfc/rfc5646) format
|
||||
- `gender` *number*
|
||||
<ul><li>0: unspecified</li><li>1: female</li><li>2: male</li><li>3: diverse</li></ul>
|
||||
- `email` *string*
|
||||
@@ -101,7 +101,7 @@ title: Objects
|
||||
- `nickName` *string*
|
||||
- `displayName` *string*
|
||||
- `preferredLanguage` *string*
|
||||
In [RFC 5646](https://www.rfc-editor.org/rfc/rfc5646) fromat
|
||||
In [RFC 5646](https://www.rfc-editor.org/rfc/rfc5646) format
|
||||
- `email`
|
||||
- `email` *string*
|
||||
- `isEmailVerified` *boolean*
|
||||
|
||||
@@ -84,7 +84,7 @@ After each iteration of load-test, we should consult the [Flowchart](#after-test
|
||||
|
||||
#### Scale {#scale}
|
||||
|
||||
An outcome of scale means that the service hit some kind of resource limit, like CPU or RAM which can be increased. In such cases we increase the suggested parameter and rerun the load-test for the same target. On the next test we should analyse if the increase in scale resulted in a performance improvement proportional to the scale parameter. For example if we scale from 1 to 2 containers, it might be reasonable to expect a doubling of iterations / sec. If such an increase is not noticed, there might be another bottleneck or unlying issue, such as locking.
|
||||
An outcome of scale means that the service hit some kind of resource limit, like CPU or RAM which can be increased. In such cases we increase the suggested parameter and rerun the load-test for the same target. On the next test we should analyze if the increase in scale resulted in a performance improvement proportional to the scale parameter. For example if we scale from 1 to 2 containers, it might be reasonable to expect a doubling of iterations / sec. If such an increase is not noticed, there might be another bottleneck or underlying issue, such as locking.
|
||||
|
||||
#### Potential issues {#potential-issues}
|
||||
|
||||
|
||||
@@ -3,7 +3,7 @@ title: oidc session benchmark of Zitadel v2.70.0
|
||||
sidebar_label: oidc session
|
||||
---
|
||||
|
||||
The test implementats [Support for (OIDC) Standard in a Custom Login UI flow](https://zitadel.com/docs/guides/integrate/login-ui/oidc-standard).
|
||||
The test implements [Support for (OIDC) Standard in a Custom Login UI flow](https://zitadel.com/docs/guides/integrate/login-ui/oidc-standard).
|
||||
|
||||
The tests showed that querying the user takes too much time because Zitadel ensures the projection is up to date. This performance bottleneck must be resolved.
|
||||
|
||||
|
||||
@@ -108,7 +108,7 @@ no additional parameters required
|
||||
|
||||
#### Response modes
|
||||
|
||||
ZITADEL supports the following `response_mode` values. When no response mode is requested, the response mode is choosen based on the configured Response Type of the application.
|
||||
ZITADEL supports the following `response_mode` values. When no response mode is requested, the response mode is chosen based on the configured Response Type of the application.
|
||||
As per [OpenID Connect Core 1.0, Section 3.1.2.1](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest):
|
||||
|
||||
> The use of this parameter is NOT RECOMMENDED when the Response Mode that would be requested is the default mode specified for the Response Type.
|
||||
|
||||
@@ -300,7 +300,7 @@ curl -X POST "https://${DOMAIN}/scim/v2/${ORG_ID}/Users" \
|
||||
|
||||
</details>
|
||||
<details>
|
||||
<summary>`GET /Users/{id}`: Retrive a known user</summary>
|
||||
<summary>`GET /Users/{id}`: Retrieve a known user</summary>
|
||||
|
||||
```bash
|
||||
curl -G "https://${DOMAIN}/scim/v2/${ORG_ID}/Users/${USER_ID}" \
|
||||
|
||||
@@ -123,7 +123,7 @@ https://github.com/zitadel/zitadel-go/blob/next/example/app/templates/profile.ht
|
||||
|
||||
You will need to provide some values for the program to run:
|
||||
- `domain`: Your ZITADEL custom domain, e.g. my-domain.zitadel.cloud
|
||||
- `key`: Random secret string. Used for symmetric encryption of state parameters, cookies and PCKE.
|
||||
- `key`: Random secret string. Used for symmetric encryption of state parameters, cookies and PKCE.
|
||||
- `clientID`: The clientID provided by ZITADEL
|
||||
- `redirectURI`: The redirectURI registered at ZITADEL
|
||||
- `port`: The port on which the API will be accessible, default it 8089
|
||||
|
||||
@@ -65,7 +65,7 @@ yarn add @zitadel/react
|
||||
### Create and configure the auth service
|
||||
|
||||
The @zitadel/react package provides a `createZitadelAuth()` function which sets some defaults and initializes the underlying [oidc-client-ts](https://github.com/authts/oidc-client-ts) `UserManager` class.
|
||||
You can overwrite all the defaults with the aguments you pass to `createZitadelAuth()`.
|
||||
You can overwrite all the defaults with the arguments you pass to `createZitadelAuth()`.
|
||||
|
||||
Export the object returned from `createZitadelAuth()`
|
||||
|
||||
|
||||
@@ -66,7 +66,7 @@ npm install --save @zitadel/vue
|
||||
### Create and configure the auth service
|
||||
|
||||
The @zitadel/vue package provides a `createZITADELAuth()` function which sets some defaults and calls the underlying [vue-oidc-client packages](https://github.com/soukoku/vue-oidc-client) `createOidcAuth()` function.
|
||||
You can overwrite all the defaults with the aguments you pass to `createZITADELAuth()`.
|
||||
You can overwrite all the defaults with the arguments you pass to `createZITADELAuth()`.
|
||||
|
||||
Export the object returned from `createZITADELAuth()`
|
||||
|
||||
|
||||
@@ -52,7 +52,7 @@ You can optionally configure the following settings.
|
||||
A useful default will be filled if you don't change anything.
|
||||
|
||||
**Scopes**: The scopes define which scopes will be sent to the provider, `openid`, `profile`, and `email` are prefilled.
|
||||
This informations will be taken to create/update the user within ZITADEL.
|
||||
This information will be taken to create/update the user within ZITADEL.
|
||||
ZITADEL ensures that at least the `openid`-scope is always sent.
|
||||
|
||||
<GeneralConfigDescription provider_account="GitLab account" />
|
||||
|
||||
@@ -32,7 +32,7 @@ You will have to paste it in the Google Cloud Platform later.
|
||||
1. Go to the Google Cloud Platform and choose your project: [https://console.cloud.google.com/apis/credentials](https://console.cloud.google.com/apis/credentials)
|
||||
2. Click on "+ CREATE CREDENTIALS" and choose "OAuth client ID"
|
||||
3. Choose "Web application" as application type and give a name
|
||||
4. [Paste the ZITADEL Callback URL you copied before](#open-the-google-identity-provider-template) to the Authorised redirect URIs
|
||||
4. [Paste the ZITADEL Callback URL you copied before](#open-the-google-identity-provider-template) into the authorized redirect URIs
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -19,7 +19,7 @@ The easiest way to do so is [by following the Docker Compose installation guide]
|
||||
:::
|
||||
|
||||
:::caution
|
||||
Beware that this example configuration neighter supports LDAPS nor StartTLS.
|
||||
Beware that this example configuration neither supports LDAPS nor StartTLS.
|
||||
We highly recommend to enable LDAPS or StartTLS in your production setup.
|
||||
Otherwise, your users passwords are sent in clear text through the wire.
|
||||
:::
|
||||
|
||||
@@ -129,7 +129,7 @@ When setting up the new Login app for OIDC, ensure it meets the following requir
|
||||
- The OIDC Proxy sets `x-zitadel-public-host` which is the host, your Login app is deployed to `ex. login.example.com`.
|
||||
- The OIDC Proxy sets `x-zitadel-instance-host` which is the host of your instance `ex. test-hdujwl.zitadel.cloud`.
|
||||
|
||||
You can review an example implementation of a middlware [here](https://github.com/zitadel/zitadel/blob/main/apps/login/src/middleware.ts).
|
||||
You can review an example implementation of a middleware [here](https://github.com/zitadel/zitadel/blob/main/apps/login/src/middleware.ts).
|
||||
|
||||
#### Deploy to Vercel
|
||||
|
||||
|
||||
@@ -486,7 +486,7 @@ You have successfully registered a new U2F to the user.
|
||||
### Check User
|
||||
|
||||
To be able to check the Universal Second Factor (U2F) you need a user check and a webAuthN challenge.
|
||||
In the creat session request you can check for the user and directly initiate the webAuthN challenge.
|
||||
In the create session request you can check for the user and directly initiate the webAuthN challenge.
|
||||
|
||||
For U2F you can choose between "USER_VERIFICATION_REQUIREMENT_PREFERRED" and "USER_VERIFICATION_REQUIREMENT_DISCOURAGED" for the challenge.
|
||||
Best practice is using discouraged, as this doesn't require the user to enter a PIN. With `preferred` the user might be prompted for the PIN, but it is not necessary.
|
||||
|
||||
@@ -214,7 +214,7 @@ Once a key was activated and deactivated (by activation of the next key) deletio
|
||||
|
||||
- Until access and ID tokens are expired. See [OIDC token lifetimes](/docs/guides/manage/console/default-settings#oidc-token-lifetimes-and-expiration).
|
||||
- ID tokens may be used as `id_token_hint` in authentication and end-session requests. The hint typically doesn't expire, but becomes invalid once the key is deleted.
|
||||
It might be desired to keep keys around long enough to minimalize user impact.
|
||||
It might be desirable to keep keys around long enough to minimize user impact.
|
||||
|
||||
### Rotation example
|
||||
|
||||
|
||||
@@ -165,7 +165,7 @@ This request allows you only to setup a user with password authentication at the
|
||||
By specifying the roles you can define, which permission the user should have within ZITADEL.
|
||||
Per default the user will automatically get "ORG_OWNER".
|
||||
|
||||
<img src="/docs/img/guides/solution-scenarios/register-team-graphic.png" alt="Setup Organiation with Admin User Graphic"/>
|
||||
<img src="/docs/img/guides/solution-scenarios/register-team-graphic.png" alt="Setup Organization with Admin User Graphic"/>
|
||||
|
||||
#### Example Request
|
||||
|
||||
|
||||
@@ -41,7 +41,7 @@ This includes:
|
||||
|
||||
All the information is filled out as an example, and to connect with any other environment you only have to change the
|
||||
used domain, for example "example.com" with "zitadel.cloud".
|
||||
Lastly, upload the certificate used to sign the reponses, provided for you under the
|
||||
Lastly, upload the certificate used to sign the responses, provided for you under the
|
||||
URL \{your_instance_domain}/saml/v2/certificate.
|
||||
|
||||
Then just press the button "Create" and the connection on Auth0 is configured.
|
||||
|
||||
@@ -421,10 +421,10 @@ Doing similar request you can:
|
||||
|
||||
### Request an ID token example
|
||||
|
||||
In the following example we exchange the intitial opaque access token to a new ID token. The usefulness of this is up to the imagination of the reader, but it demonstrates the weird behavior of requesting an ID token, as defined by the RFC.
|
||||
In the following example we exchange the initial opaque access token to a new ID token. The usefulness of this is up to the imagination of the reader, but it demonstrates the weird behavior of requesting an ID token, as defined by the RFC.
|
||||
|
||||
:::info
|
||||
You can also obtain an ID token in the `id_token` response field by requestion an access token and the `openid` scope.
|
||||
You can also obtain an ID token in the `id_token` response field by requesting an access token and the `openid` scope.
|
||||
:::
|
||||
|
||||
```bash
|
||||
@@ -871,7 +871,7 @@ And again the access token claims:
|
||||
|
||||
### Other usage examples
|
||||
|
||||
Above we gave some of the most staightforward usecases. Of course, you can combine these examples to:
|
||||
Above we gave some of the most straightforward use cases. Of course, you can combine these examples to:
|
||||
|
||||
- Impersonate and change the token type
|
||||
- Impersonate and change scope
|
||||
@@ -901,4 +901,4 @@ In the [instance event list](/docs/concepts/eventstore/overview) the `User imper
|
||||
## Finishing notes
|
||||
|
||||
The current implementation of the Token Exchange grant was our first iteration on the subject.
|
||||
We love to hear feedback from our user! This is a [GitHub discussion](https://github.com/zitadel/zitadel/discussions/7624) opened specifically for this pupose.
|
||||
We love to hear feedback from our user! This is a [GitHub discussion](https://github.com/zitadel/zitadel/discussions/7624) opened specifically for this purpose.
|
||||
|
||||
@@ -119,7 +119,7 @@ curl --request POST \
|
||||
where
|
||||
|
||||
- `grant_type` must be set to `urn:ietf:params:oauth:grant-type:jwt-bearer`
|
||||
- `scope` should contain any [Scopes](/apis/openidoauth/scopes) you want to include, but must include `openid` and `urn:zitadel:iam:org:project:id:zitadel:aud` to acces the ZITADEL APIs. For this example include `profile`.
|
||||
- `scope` should contain any [Scopes](/apis/openidoauth/scopes) you want to include, but must include `openid` and `urn:zitadel:iam:org:project:id:zitadel:aud` to access the ZITADEL APIs. For this example include `profile`.
|
||||
- `assertion` is the encoded value of the JWT that was signed with your private key from the prior step
|
||||
|
||||
You should receive a successful response with `access_token`, `token_type` and time to expiry in seconds as `expires_in`.
|
||||
|
||||
@@ -76,7 +76,7 @@ curl --request POST \
|
||||
```
|
||||
|
||||
The response will give you a list of aggregate types. The type is what the aggregate is called in ZITADEL itself (technical).
|
||||
You can also find a translation for the aggregae to better reflect it for an enduser perspective.
|
||||
You can also find a translation for the aggregate to better reflect it for an enduser perspective.
|
||||
|
||||
The following example shows you the aggregate type for the user.
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ When you configure your default settings, you can set the following:
|
||||
- **Organizations**: A list of your organizations
|
||||
- [**Features**](#features): Feature Settings let you try out new features before they become generally available. You can also disable features you are not interested in.
|
||||
- [**Notification settings**](#notification-settings): Setup Notification and Email Server settings for initialization-, verification- and other mails. Setup Twilio as SMS notification provider.
|
||||
- [**Login Behavior and Access**](#login-behavior-and-access): Multifactor Authentication Options and Enforcement, Define whether Passwordless authentication methods are allowed or not, Set Login Lifetimes and advanced behavour for the login interface.
|
||||
- [**Login Behavior and Access**](#login-behavior-and-access): Multifactor Authentication Options and Enforcement, Define whether Passwordless authentication methods are allowed or not, Set Login Lifetimes and advanced behavior for the login interface.
|
||||
- [**Identity Providers**](#identity-providers): Define IDPs which are available for all organizations
|
||||
- [**Password Complexity**](#password-complexity): Requirements for Passwords ex. Symbols, Numbers, min length and more.
|
||||
- [**Password Expiry**](#password-expiry): Set an expiry for passwords. After the expiration, a user will be prompted to change their password during the next login.
|
||||
@@ -56,7 +56,7 @@ We recommend setting your Branding and SMTP settings initially as it will comfor
|
||||
|
||||
|
||||
|
||||
In the Branding settings, you can upload you Logo for the login interface, set your own colors for buttons, background, links, and choose between multiple behavours. You don't need to be an expert as those settings can all be set without any knowledge of CSS.
|
||||
In the Branding settings, you can upload you Logo for the login interface, set your own colors for buttons, background, links, and choose between multiple behaviors. You don't need to be an expert as those settings can all be set without any knowledge of CSS.
|
||||
|
||||
| Setting | Description |
|
||||
| ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
@@ -68,7 +68,7 @@ In the Branding settings, you can upload you Logo for the login interface, set y
|
||||
|
||||
Make sure you click the "Apply configuration" button after you finish your configuration. This will ensure your design is visible for your customers.
|
||||
|
||||
Branding settings applied on you instance act as a default for all your organizations. If you need custom branding on a organization take a look at our guide under [organization settiong](./organizations#branding).
|
||||
Branding settings applied on you instance act as a default for all your organizations. If you need custom branding on a organization take a look at our guide under [organization setting](./organizations#branding).
|
||||
|
||||
## Notification settings
|
||||
|
||||
@@ -147,7 +147,7 @@ The Login Policy defines how the login process should look like and which authen
|
||||
|
||||
<img
|
||||
src="/docs/img/guides/console/loginpolicy.png"
|
||||
alt="Login Bahaviour and Access"
|
||||
alt="Login Behavior and Access"
|
||||
width="800px"
|
||||
/>
|
||||
|
||||
@@ -180,7 +180,7 @@ There are two different types one is depending on the device (e.g. Fingerprint,
|
||||
|
||||
### Multifactor (MFA)
|
||||
|
||||
In the multifactors section you can configure what kind of multifactors should be allowed. For passwordless to work, it's required to enable U2F (Universial Second Factor) with PIN. There is no other option at the moment.
|
||||
In the multifactors section you can configure what kind of multifactors should be allowed. For passwordless to work, it's required to enable U2F (Universal Second Factor) with PIN. There is no other option at the moment.
|
||||
Multifactors:
|
||||
|
||||
- U2F (Universal Second Factor) with PIN, e.g FaceID, WindowsHello, Fingerprint, Hardwaretokens like Yubikey
|
||||
@@ -296,7 +296,7 @@ With this setting you are able to configure your privacy policy, terms of servic
|
||||
|
||||
On register each user has to accept these policies.
|
||||
|
||||
This policy can be also be overriden by your organizations.
|
||||
This policy can be also be overridden by your organizations.
|
||||
|
||||
When focused on an input field you can see the language attribute, which can then be integrated into your link.
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ import ManagerDescription from "../../../concepts/structure/_manager_description
|
||||
<ManagerDescription name="ManagerDescription" />
|
||||
|
||||
To configure managers in ZITADEL go to the resource where you like to add it (e.g Instance, Organization, Project, GrantedProject).
|
||||
In the right part of the console you can finde **MANAGERS** in the details part. Here you have a list of the current managers and can add a new one.
|
||||
In the right part of the console you can find **MANAGERS** in the details part. Here you have a list of the current managers and can add a new one.
|
||||
|
||||
<img alt="Managers" src="/docs/img/guides/console/managers.png" width="200px" />
|
||||
|
||||
@@ -39,7 +39,7 @@ import AddManager from "./_add_manager.mdx";
|
||||
| Project Owner Viewer | PROJECT_OWNER_VIEWER | View everything within a project. |
|
||||
| Project Owner Global | PROJECT_OWNER_GLOBAL | Same as PROJECT_OWNER, but in the global organization. |
|
||||
| Project Owner Viewer Global | PROJECT_OWNER_VIEWER_GLOBAL | Same as PROJECT_OWNER_VIEWER, but in the global organization. |
|
||||
| Project Grant Owner | PROJECT_GRANT_OWNER | Same as PROJECT_OWNER but for a granted proejct. |
|
||||
| Project Grant Owner | PROJECT_GRANT_OWNER | Same as PROJECT_OWNER but for a granted project. |
|
||||
|
||||
## Configure roles
|
||||
|
||||
|
||||
@@ -59,7 +59,7 @@ Users that you create within your organization will be suffixed with this domain
|
||||
|
||||
You can improve the user experience, by suffixing users with a domain name that is in your control.
|
||||
If the "validate org domains" settings in the [Domain Settings](./default-settings#domain-settings) is set to true, you have to prove the ownership of your domain, by DNS or HTTP challenge.
|
||||
If the setting is set to false, the created domain will automatically be set to verifed.
|
||||
If the setting is set to false, the created domain will automatically be set to verified.
|
||||
|
||||
An organization can have multiple domain names, but only one domain can be primary.
|
||||
The primary domain defines which login name ZITADEL displays to the user, and what information gets asserted in access_tokens (`preferred_username`).
|
||||
@@ -105,7 +105,7 @@ Those settings are the same as your default settings.
|
||||
|
||||
> Note: that the following links, redirect to default settings to omit redundancy.
|
||||
|
||||
- [**Login Behavior and Access**](./default-settings#login-behaviour-and-access): Multifactor Authentication Options and Enforcement, Define whether Passwordless authentication methods are allowed or not, Set Login Lifetimes and advanced behavour for the login interface.
|
||||
- [**Login Behavior and Access**](./default-settings#login-behaviour-and-access): Multifactor Authentication Options and Enforcement, Define whether Passwordless authentication methods are allowed or not, Set Login Lifetimes and advanced behavior for the login interface.
|
||||
- [**Identity Providers**](./default-settings#identity-providers): Define IDPs which are available for all organizations
|
||||
- [**Password Complexity**](./default-settings#password-complexity): Requirements for Passwords ex. Symbols, Numbers, min length and more.
|
||||
- [**Lockout**](./default-settings#lockout): Set the maximum attempts a user can try to enter the password or any (T)OTP method. When the number is exceeded, the user gets locked out and has to be unlocked.
|
||||
|
||||
@@ -42,7 +42,7 @@ Now select the roles you want this organization to use and save.
|
||||
This enables you to lock a certain organization out of a feature if you don't want their users to use it.
|
||||
You can learn more about roles [here](./roles).
|
||||
|
||||
Organizations can then create authorizations for their users on their own. The project is shown them seperated from their own projects.
|
||||
Organizations can then create authorizations for their users on their own. The project is shown them separated from their own projects.
|
||||
|
||||
<img
|
||||
alt="Granted project"
|
||||
|
||||
@@ -45,7 +45,7 @@ Now, make the action hook into the [external authentication flow](/apis/actions/
|
||||
|
||||
<!-- TODO: ## Test if your action works -->
|
||||
|
||||
New users automatically are assiged a role now if they register by authenticating with an external identity provider.
|
||||
New users automatically are assigned a role now if they register by authenticating with an external identity provider.
|
||||
|
||||
## What's next?
|
||||
|
||||
|
||||
@@ -25,8 +25,8 @@ Upload your logo for the chosen theme, as soon as it is uploaded the preview on
|
||||
### Colors
|
||||
|
||||
In the next part you can configure your colors.
|
||||
Background colour is self-explanatory, the primary color will be used for buttons, links and some highlights.
|
||||
The warn color is used for all the error messages and warnings and the font colour for texts.
|
||||
Background color is self-explanatory, the primary color will be used for buttons, links and some highlights.
|
||||
The warn color is used for all the error messages and warnings and the font color for texts.
|
||||
|
||||
### Font
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
ZITADEL can send messages to users via different notification providers, such as SMS, SMTP, or Webhook (HTTP Provider).
|
||||
While you can add multiple providers to different channels, messages will only be delivered via the actived provider.
|
||||
While you can add multiple providers to different channels, messages will only be delivered via the active provider.
|
||||
Message and notification texts can be [customized](./texts) for an instance or for each organization.
|
||||
|
||||
## SMS providers
|
||||
|
||||
@@ -9,7 +9,7 @@ Currently, the following restrictions are available:
|
||||
|
||||
- *Disallow public organization registrations* - If restricted, only users with the role IAM_OWNERS can create new organizations. The endpoint */ui/login/register/org* returns HTTP status 404 on GET requests, and 409 on POST requests.
|
||||
- *AllowedLanguages* - The following rules apply if languages are restricted:
|
||||
- Only allowed languages are listed in the OIDC discovery endpoint */.well-kown/openid-configuration*.
|
||||
- Only allowed languages are listed in the OIDC discovery endpoint */.well-known/openid-configuration*.
|
||||
- Login UI texts are only rendered in allowed languages.
|
||||
- Notification message texts are only rendered in allowed languages.
|
||||
- Custom Texts can be created for disallowed languages as long as ZITADEL supports that language. Therefore, all texts can be customized before allowing a language.
|
||||
|
||||
@@ -16,7 +16,7 @@ This guide introduces you to the grouping and structuring of ZITADEL projects wh
|
||||
The journey of this guide starts with creating an Organization, the outermost layer of ZITADEL within your instance, as it is the vessel for projects, roles, applications and users.
|
||||
Creation can be done from [ZITADEL Console](https://${CUSTOM_DOMAIN}.zitadel.cloud/ui/console/orgs/create). You can choose your current account for the organization owner or create a new one.
|
||||
|
||||
Depending on your Software Development Life Cycle (SDLC) you can create multiple organizations or projects to keep your applications environments seperated.
|
||||
Depending on your Software Development Life Cycle (SDLC) you can create multiple organizations or projects to keep your applications environments separated.
|
||||
|
||||
### Custom domain
|
||||
|
||||
|
||||
@@ -104,7 +104,7 @@ Go to the "Advanced" section, per default login with phone number should be allo
|
||||
|
||||
## Embedding ZITADEL in an iFrame
|
||||
|
||||
To maximise the security during login and in the Console UI, ZITADEL follows security best practices by setting a
|
||||
To maximize the security during login and in the Console UI, ZITADEL follows security best practices by setting a
|
||||
Content-Security-Policy (CSP), X-Frame-Options and cookies with SameSite Lax:
|
||||
|
||||
```
|
||||
|
||||
@@ -91,7 +91,7 @@ In such case, Zitadel shall be entitled to suspend the processing until the infr
|
||||
### Confidentiality obligations
|
||||
|
||||
Zitadel shall ensure that any person that it authorizes to process Customer Data (including Zitadel’s staff, agents and sub-processors) (an “Authorized Person”) shall be subject to a strict duty of confidentiality (whether a contractual duty or a statutory duty) and shall not permit any person to process the Customer Data that is not under such a duty of confidentiality.
|
||||
Zitadel shall ensure that all Authorised Persons process the Customer Data only as necessary for the Permitted Purpose.
|
||||
Zitadel shall ensure that all Authorized Persons process the Customer Data only as necessary for the Permitted Purpose.
|
||||
|
||||
### Technical and organizational measures
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ This policy clarifies how we handle requests for feature prioritization and deve
|
||||
Shaping of the roadmap and prioritization of features is done by ZITADEL.
|
||||
You are welcome to give feedback on the [roadmap](https://zitadel.com/roadmap) and we are happy to [accept upstream pull requests](https://github.com/zitadel/zitadel/CONTRIBUTE.md) for ZITADEL.
|
||||
|
||||
In case you can't contribute directly to the open source version of ZITADEL, but want to accelerate development, we may develop the feature on request, under the conditions layed out in this policy.
|
||||
In case you can't contribute directly to the open source version of ZITADEL, but want to accelerate development, we may develop the feature on request, under the conditions laid out in this policy.
|
||||
|
||||
Features that will be part of the publicly available ZITADEL [repositories](https://github.com/zitadel/), ZITADEL Cloud, or optional components to our products that might be available only under a commercial license.
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@ status: stable
|
||||
|
||||
## Overview
|
||||
|
||||
[Hono](https://hono.dev) is a small, simple, and ultrafast web framework for the Edges that works on Cloudflare Workers, Fastly Compute, Deno, Bun, Vercel, Netlify, AWS Lambda, Lambda@Edge, and Node.js. This example demonstrates how to integrate **Zitadel** using the **[OAuth 2.0 PKCE flow](/docs/concepts/pkce)** to authenticate users securely and maintain sessions across your Hono application.
|
||||
[Hono](https://hono.dev) is a small, simple, and ultra fast web framework for the Edges that works on Cloudflare Workers, Fastly Compute, Deno, Bun, Vercel, Netlify, AWS Lambda, Lambda@Edge, and Node.js. This example demonstrates how to integrate **Zitadel** using the **[OAuth 2.0 PKCE flow](/docs/concepts/pkce)** to authenticate users securely and maintain sessions across your Hono application.
|
||||
|
||||
#### Auth library
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ sidebar_label: Python Django
|
||||
<table>
|
||||
<tr>
|
||||
<td width="100px">
|
||||
<img width="100px" src="/docs/img/tech/django.png" alt="phyton logo"/>
|
||||
<img width="100px" src="/docs/img/tech/django.png" alt="python logo"/>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://www.djangoproject.com/" target="_blank">Django</a> is a high-level <a href="https://www.python.org">Python</a> web framework that encourages rapid development and clean, pragmatic design.
|
||||
|
||||
@@ -6,8 +6,8 @@ sidebar_label: Python Flask
|
||||
<table>
|
||||
<tr>
|
||||
<td width="100px">
|
||||
<img width="100px" src="/docs/img/tech/flask.svg" alt="phyton logo" className="hideonlight"/>
|
||||
<img width="100px" src="/docs/img/tech/flasklight.svg" alt="phyton logo" className="hideondark"/>
|
||||
<img width="100px" src="/docs/img/tech/flask.svg" alt="python logo" className="hideonlight"/>
|
||||
<img width="100px" src="/docs/img/tech/flasklight.svg" alt="python logo" className="hideondark"/>
|
||||
</td>
|
||||
<td>
|
||||
<a href="https://flask.palletsprojects.com/en/3.0.x/" target="_blank">Flask</a> is a lightweight and easy-to-use microframework for <a href="https://www.python.org">Python</a> web development.
|
||||
|
||||
@@ -4,13 +4,13 @@ sidebar_label: HTTP/2 Support
|
||||
---
|
||||
|
||||
ZITADEL follows a strict API first approach and makes heavy use of the modern API framework called [gRPC](https://grpc.io/).
|
||||
Besides gRPC all APIs are also available in an openapi Rest fashion as well as in gRPC-web for compatibilty towards browser integrations.
|
||||
Besides gRPC all APIs are also available in an openapi Rest fashion as well as in gRPC-web for compatibility towards browser integrations.
|
||||
|
||||
To make use of gRPC it is vital to allow your clients to communicate with ZITADEL with [HTTP/2](https://en.wikipedia.org/wiki/HTTP/2).
|
||||
|
||||
Sometimes you need to configure explicitly that you want to use HTTP/2 if you run ZITADEL behind a reverse proxy and below you should find examples for different vendors and projects.
|
||||
|
||||
Furthermore it is important to notice that by default HTTP/2 is always encrypted, but if you want to run ZITADEL without TLS from your reverse proxy or service mesh this is possible through [h2c](https://httpd.apache.org/docs/2.4/howto/http2.html).
|
||||
Oftentimes when you run ZITADEL inside a service mesh, or a servelerss offering (e.g. Google Cloud Run, Knative, ...) you will need h2c.
|
||||
Oftentimes when you run ZITADEL inside a service mesh, or a serverless offering (e.g. Google Cloud Run, Knative, ...) you will need h2c.
|
||||
|
||||
You can read more about ZITADEL's [TLSs modes here](/self-hosting/manage/tls_modes).
|
||||
|
||||
@@ -99,7 +99,7 @@ The following table describes the milestones that are sent to the endpoints:
|
||||
| An authentication succeeded for the first time on an instance. | This is the first authentication with the instances automatically created admin user during the instance setup, which can be a human or a machine. |
|
||||
| A project is created for the first time in a virtual instance. | The ZITADEL project that is automatically created during the instance setup is omitted. |
|
||||
| An application is created for the first time in a virtual instance. | The applications in the ZITADEL project that are automatically created during the instance setup are omitted. |
|
||||
| An authentication succeeded for the first time in a virtal instances application. | This is the first authentication using a ZITADEL application that is not created during the instance setup phase. |
|
||||
| An authentication succeeded for the first time in a virtual instances application. | This is the first authentication using a ZITADEL application that is not created during the instance setup phase. |
|
||||
| A virtual instance is deleted. | This data point is sent when a virtual instance is deleted via ZITADELs system API |
|
||||
|
||||
|
||||
|
||||
@@ -13,4 +13,4 @@ To configure your service that fronts Zitadel please have a look at the vendors
|
||||
## Things to look out for when fronting Zitadel Cloud
|
||||
|
||||
- Cache-control - Zitadel Cloud uses a CDN to globally distribute data. Please try to avoid overriding this header as it may lead to sideeffects
|
||||
- Rate Limits - Zitadel Cloud uses a combination of static and dynamic rate limits. If you recieve occasional 429 headers you are rate limited.
|
||||
- Rate Limits - Zitadel Cloud uses a combination of static and dynamic rate limits. If you receive occasional 429 headers you are rate limited.
|
||||
|
||||
@@ -57,5 +57,5 @@ TLS:
|
||||
Beware that ZITADEL uses HTTP/2 for all its connections.
|
||||
If you are using the mode `external` or `disabled` make sure to verify h2c compatibility.
|
||||
|
||||
- [Read more abouth how ZITADEL utilizes HTTP/2](/self-hosting/manage/http2).
|
||||
- [Read more about how ZITADEL utilizes HTTP/2](/self-hosting/manage/http2).
|
||||
- [Explore some concrete proxy configuration examples for ZITADEL](/self-hosting/manage/reverseproxy/reverse_proxy).
|
||||
|
||||
@@ -11,7 +11,7 @@ However, to improve day-two-operations,
|
||||
we recommend you run the init phase and the setup phase
|
||||
separately using `zitadel init` and `zitadel setup` respectively.
|
||||
Both the init and the setup phases are idempotent,
|
||||
meaning you can run them as many times as you want whithout unexpectedly changing any state.
|
||||
meaning you can run them as many times as you want without unexpectedly changing any state.
|
||||
Nevertheless, they just __need__ to be run at certain points in time, whereas further runs are obsolete.
|
||||
The init phase has to run once over the full ZITADEL lifecycle, before the setup and runtime phases run first.
|
||||
The setup phase has to run each time a new ZITADEL version is deployed.
|
||||
|
||||
@@ -10,7 +10,7 @@ Date: 2023-10-14
|
||||
|
||||
## Description
|
||||
|
||||
Due to storage optimisations ZITADEL changes the behavior of sequences.
|
||||
Due to storage optimizations ZITADEL changes the behavior of sequences.
|
||||
This change improves command (create, update, delete) performance of ZITADEL.
|
||||
|
||||
Sequences are no longer unique inside an instance.
|
||||
@@ -26,7 +26,7 @@ As soon as the release version is published, we will include the version here.
|
||||
## Mitigation
|
||||
|
||||
If you use the ListEvents API to scrape events use the creation date instead of the sequence.
|
||||
If you use sequences on a list of objects it's no longer garanteed to have unique sequences across the list.
|
||||
If you use sequences on a list of objects it's no longer guaranteed to have unique sequences across the list.
|
||||
Therefore it's recommended to use the change data of the objects instead.
|
||||
|
||||
## Impact
|
||||
|
||||
@@ -11,7 +11,7 @@ Date: Calendar week 41/42 2023
|
||||
## Description
|
||||
|
||||
Migrating to version >= 2.39 from < 2.39 will cause down time during setup starts and the new version is started.
|
||||
This is caused by storage optimisations which replace the `eventstore.events` database table with the new `eventstore.events2` table.
|
||||
This is caused by storage optimizations which replace the `eventstore.events` database table with the new `eventstore.events2` table.
|
||||
All existing events are migrated during the execution of the `zitadel setup` command.
|
||||
New events will be inserted into the new `eventstore.events2` table. The old table `evetstore.events` is renamed to `eventstore.events_old` and will be dropped in a future release of ZITADEL.
|
||||
|
||||
|
||||
@@ -90,10 +90,10 @@ We understand that these advisories may include breaking changes, and we aim to
|
||||
<td>
|
||||
<a href="./advisory/a10004">A-10004</a>
|
||||
</td>
|
||||
<td>Sequence uniquenes</td>
|
||||
<td>Sequence uniqueness</td>
|
||||
<td>Breaking Behavior Change</td>
|
||||
<td>
|
||||
Due to storage optimisations ZITADEL changes the behavior of sequences.
|
||||
Due to storage optimizations ZITADEL changes the behavior of sequences.
|
||||
This change improves command (create, update, delete) performance of ZITADEL.
|
||||
Sequences are no longer unique inside an instance.
|
||||
From now on sequences are upcounting per aggregate id.
|
||||
@@ -111,7 +111,7 @@ We understand that these advisories may include breaking changes, and we aim to
|
||||
<td>Expected downtime during upgrade</td>
|
||||
<td>
|
||||
Migrating to versions >= 2.39 from < 2.39 will cause down time during setup starts and the new version is started.
|
||||
This is caused by storage optimisations which replace the `eventstore.events` database table with the new `eventstore.events2` table.
|
||||
This is caused by storage optimizations which replace the `eventstore.events` database table with the new `eventstore.events2` table.
|
||||
All existing events are migrated during the execution of the `zitadel setup` command.
|
||||
New events will be inserted into the new `eventstore.events2` table. The old table `evetstore.events` is renamed to `eventstore.events_old` and will be dropped in a future release of ZITADEL.
|
||||
</td>
|
||||
@@ -194,7 +194,7 @@ We understand that these advisories may include breaking changes, and we aim to
|
||||
<td>
|
||||
<a href="./advisory/a10012">A-10012</a>
|
||||
</td>
|
||||
<td>Tncreased transaction duration for projections</td>
|
||||
<td>Increased transaction duration for projections</td>
|
||||
<td>Breaking Behavior Change</td>
|
||||
<td>
|
||||
In version 2.63.0 we've increased the transaction duration for projections to resolve outdated projections or dead-locks.
|
||||
|
||||
@@ -23,7 +23,7 @@ To make sure, that your new settings will trigger, please restart your mobile ph
|
||||
|
||||
**Settings > Safari > Advanced > Experimental Features > disable: „SameSite strict enforcement (ITP)“**
|
||||
|
||||
|
||||
|
||||
|
||||
**Settings > Safari > disable: "Block All cookies"**
|
||||
|
||||
|
||||
Reference in New Issue
Block a user