diff --git a/docs/README.md b/docs/README.md index d6007fbeb..4b2fdf129 100644 --- a/docs/README.md +++ b/docs/README.md @@ -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 diff --git a/docs/docs/apis/actions/introduction.md b/docs/docs/apis/actions/introduction.md index 98309c819..d7aa91471 100644 --- a/docs/docs/apis/actions/introduction.md +++ b/docs/docs/apis/actions/introduction.md @@ -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. diff --git a/docs/docs/apis/actions/objects.md b/docs/docs/apis/actions/objects.md index bbde0f22d..c0feab78a 100644 --- a/docs/docs/apis/actions/objects.md +++ b/docs/docs/apis/actions/objects.md @@ -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* - `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* diff --git a/docs/docs/apis/benchmarks/index.mdx b/docs/docs/apis/benchmarks/index.mdx index a0979f008..2707a0ef0 100644 --- a/docs/docs/apis/benchmarks/index.mdx +++ b/docs/docs/apis/benchmarks/index.mdx @@ -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} diff --git a/docs/docs/apis/benchmarks/v2.70.0/oidc_session/index.mdx b/docs/docs/apis/benchmarks/v2.70.0/oidc_session/index.mdx index 94fd83f11..dbb4d772d 100644 --- a/docs/docs/apis/benchmarks/v2.70.0/oidc_session/index.mdx +++ b/docs/docs/apis/benchmarks/v2.70.0/oidc_session/index.mdx @@ -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. diff --git a/docs/docs/apis/openidoauth/endpoints.mdx b/docs/docs/apis/openidoauth/endpoints.mdx index 919e54822..7fa80e8bc 100644 --- a/docs/docs/apis/openidoauth/endpoints.mdx +++ b/docs/docs/apis/openidoauth/endpoints.mdx @@ -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. diff --git a/docs/docs/apis/scim2.md b/docs/docs/apis/scim2.md index c4a9a98a9..d60d70097 100644 --- a/docs/docs/apis/scim2.md +++ b/docs/docs/apis/scim2.md @@ -300,7 +300,7 @@ curl -X POST "https://${DOMAIN}/scim/v2/${ORG_ID}/Users" \
-`GET /Users/{id}`: Retrive a known user +`GET /Users/{id}`: Retrieve a known user ```bash curl -G "https://${DOMAIN}/scim/v2/${ORG_ID}/Users/${USER_ID}" \ diff --git a/docs/docs/examples/login/go.md b/docs/docs/examples/login/go.md index ed4f9ba61..658380017 100644 --- a/docs/docs/examples/login/go.md +++ b/docs/docs/examples/login/go.md @@ -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 diff --git a/docs/docs/examples/login/react.md b/docs/docs/examples/login/react.md index 61a9151ea..14510941b 100644 --- a/docs/docs/examples/login/react.md +++ b/docs/docs/examples/login/react.md @@ -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()` diff --git a/docs/docs/examples/login/vue.mdx b/docs/docs/examples/login/vue.mdx index 481af212c..328891b87 100644 --- a/docs/docs/examples/login/vue.mdx +++ b/docs/docs/examples/login/vue.mdx @@ -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()` diff --git a/docs/docs/guides/integrate/identity-providers/gitlab.mdx b/docs/docs/guides/integrate/identity-providers/gitlab.mdx index 55650a37b..69cb81b88 100644 --- a/docs/docs/guides/integrate/identity-providers/gitlab.mdx +++ b/docs/docs/guides/integrate/identity-providers/gitlab.mdx @@ -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. diff --git a/docs/docs/guides/integrate/identity-providers/google.mdx b/docs/docs/guides/integrate/identity-providers/google.mdx index 182a2dc74..08bb69ca0 100644 --- a/docs/docs/guides/integrate/identity-providers/google.mdx +++ b/docs/docs/guides/integrate/identity-providers/google.mdx @@ -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 ![Google OAuth App Registration](/img/guides/google_oauth_app_registration.png) diff --git a/docs/docs/guides/integrate/identity-providers/openldap.mdx b/docs/docs/guides/integrate/identity-providers/openldap.mdx index efba37fe9..74474812c 100644 --- a/docs/docs/guides/integrate/identity-providers/openldap.mdx +++ b/docs/docs/guides/integrate/identity-providers/openldap.mdx @@ -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. ::: diff --git a/docs/docs/guides/integrate/login-ui/login-app.mdx b/docs/docs/guides/integrate/login-ui/login-app.mdx index 56a72b9c0..d9628b487 100644 --- a/docs/docs/guides/integrate/login-ui/login-app.mdx +++ b/docs/docs/guides/integrate/login-ui/login-app.mdx @@ -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 diff --git a/docs/docs/guides/integrate/login-ui/mfa.mdx b/docs/docs/guides/integrate/login-ui/mfa.mdx index 7814df1ef..79f01c7a3 100644 --- a/docs/docs/guides/integrate/login-ui/mfa.mdx +++ b/docs/docs/guides/integrate/login-ui/mfa.mdx @@ -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. diff --git a/docs/docs/guides/integrate/login/oidc/webkeys.md b/docs/docs/guides/integrate/login/oidc/webkeys.md index e4099c98c..79678af12 100644 --- a/docs/docs/guides/integrate/login/oidc/webkeys.md +++ b/docs/docs/guides/integrate/login/oidc/webkeys.md @@ -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 diff --git a/docs/docs/guides/integrate/onboarding/b2b.mdx b/docs/docs/guides/integrate/onboarding/b2b.mdx index a976da71e..189250e2b 100644 --- a/docs/docs/guides/integrate/onboarding/b2b.mdx +++ b/docs/docs/guides/integrate/onboarding/b2b.mdx @@ -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". -Setup Organiation with Admin User Graphic +Setup Organization with Admin User Graphic #### Example Request diff --git a/docs/docs/guides/integrate/services/auth0-saml.md b/docs/docs/guides/integrate/services/auth0-saml.md index f05e6166d..ca6a65be6 100644 --- a/docs/docs/guides/integrate/services/auth0-saml.md +++ b/docs/docs/guides/integrate/services/auth0-saml.md @@ -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. diff --git a/docs/docs/guides/integrate/token-exchange.mdx b/docs/docs/guides/integrate/token-exchange.mdx index 5cd589cf0..663fae553 100644 --- a/docs/docs/guides/integrate/token-exchange.mdx +++ b/docs/docs/guides/integrate/token-exchange.mdx @@ -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. diff --git a/docs/docs/guides/integrate/zitadel-apis/access-zitadel-apis.md b/docs/docs/guides/integrate/zitadel-apis/access-zitadel-apis.md index 697832461..46c4ee71f 100644 --- a/docs/docs/guides/integrate/zitadel-apis/access-zitadel-apis.md +++ b/docs/docs/guides/integrate/zitadel-apis/access-zitadel-apis.md @@ -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`. diff --git a/docs/docs/guides/integrate/zitadel-apis/event-api.md b/docs/docs/guides/integrate/zitadel-apis/event-api.md index 1c9ec8237..96055bbe7 100644 --- a/docs/docs/guides/integrate/zitadel-apis/event-api.md +++ b/docs/docs/guides/integrate/zitadel-apis/event-api.md @@ -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. diff --git a/docs/docs/guides/manage/console/default-settings.mdx b/docs/docs/guides/manage/console/default-settings.mdx index 7fa42965d..448596c71 100644 --- a/docs/docs/guides/manage/console/default-settings.mdx +++ b/docs/docs/guides/manage/console/default-settings.mdx @@ -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 ![Private Labeling](/img/console_private_labeling.png) -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 Login Bahaviour and Access @@ -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. diff --git a/docs/docs/guides/manage/console/managers.mdx b/docs/docs/guides/manage/console/managers.mdx index cc571f7a2..04140c89a 100644 --- a/docs/docs/guides/manage/console/managers.mdx +++ b/docs/docs/guides/manage/console/managers.mdx @@ -8,7 +8,7 @@ import ManagerDescription from "../../../concepts/structure/_manager_description 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. Managers @@ -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 diff --git a/docs/docs/guides/manage/console/organizations.mdx b/docs/docs/guides/manage/console/organizations.mdx index af1ee14a7..47ce2a7fd 100644 --- a/docs/docs/guides/manage/console/organizations.mdx +++ b/docs/docs/guides/manage/console/organizations.mdx @@ -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. diff --git a/docs/docs/guides/manage/console/projects.mdx b/docs/docs/guides/manage/console/projects.mdx index a7abda1ed..8391f0fbe 100644 --- a/docs/docs/guides/manage/console/projects.mdx +++ b/docs/docs/guides/manage/console/projects.mdx @@ -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. Granted project -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? diff --git a/docs/docs/guides/manage/customize/branding.md b/docs/docs/guides/manage/customize/branding.md index c5ec0a883..23dfd0125 100644 --- a/docs/docs/guides/manage/customize/branding.md +++ b/docs/docs/guides/manage/customize/branding.md @@ -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 diff --git a/docs/docs/guides/manage/customize/notification-providers.mdx b/docs/docs/guides/manage/customize/notification-providers.mdx index 3bd1b358e..f09baf43f 100644 --- a/docs/docs/guides/manage/customize/notification-providers.mdx +++ b/docs/docs/guides/manage/customize/notification-providers.mdx @@ -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 diff --git a/docs/docs/guides/manage/customize/restrictions.md b/docs/docs/guides/manage/customize/restrictions.md index b99d409b1..660dd2b77 100644 --- a/docs/docs/guides/manage/customize/restrictions.md +++ b/docs/docs/guides/manage/customize/restrictions.md @@ -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. diff --git a/docs/docs/guides/solution-scenarios/b2c.mdx b/docs/docs/guides/solution-scenarios/b2c.mdx index 7dd3528f6..9ca944d10 100644 --- a/docs/docs/guides/solution-scenarios/b2c.mdx +++ b/docs/docs/guides/solution-scenarios/b2c.mdx @@ -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 diff --git a/docs/docs/guides/solution-scenarios/configurations.mdx b/docs/docs/guides/solution-scenarios/configurations.mdx index 873dfcd03..9040525a3 100644 --- a/docs/docs/guides/solution-scenarios/configurations.mdx +++ b/docs/docs/guides/solution-scenarios/configurations.mdx @@ -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: ``` diff --git a/docs/docs/legal/data-processing-agreement.mdx b/docs/docs/legal/data-processing-agreement.mdx index 78f14aa73..bc7a7bb4c 100644 --- a/docs/docs/legal/data-processing-agreement.mdx +++ b/docs/docs/legal/data-processing-agreement.mdx @@ -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 diff --git a/docs/docs/legal/policies/feature-development-policy.md b/docs/docs/legal/policies/feature-development-policy.md index 7e94f6050..d0c681c01 100644 --- a/docs/docs/legal/policies/feature-development-policy.md +++ b/docs/docs/legal/policies/feature-development-policy.md @@ -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. diff --git a/docs/docs/sdk-examples/hono.mdx b/docs/docs/sdk-examples/hono.mdx index fd1589f10..740788cef 100644 --- a/docs/docs/sdk-examples/hono.mdx +++ b/docs/docs/sdk-examples/hono.mdx @@ -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 diff --git a/docs/docs/sdk-examples/python-django.mdx b/docs/docs/sdk-examples/python-django.mdx index 8c7b3a889..daecc7403 100644 --- a/docs/docs/sdk-examples/python-django.mdx +++ b/docs/docs/sdk-examples/python-django.mdx @@ -6,7 +6,7 @@ sidebar_label: Python Django
- phyton logo + python logo Django is a high-level Python web framework that encourages rapid development and clean, pragmatic design. diff --git a/docs/docs/sdk-examples/python-flask.mdx b/docs/docs/sdk-examples/python-flask.mdx index d443d0b26..816bf2e9a 100644 --- a/docs/docs/sdk-examples/python-flask.mdx +++ b/docs/docs/sdk-examples/python-flask.mdx @@ -6,8 +6,8 @@ sidebar_label: Python Flask - + @@ -194,7 +194,7 @@ We understand that these advisories may include breaking changes, and we aim to - +
- phyton logo - phyton logo + python logo + python logo Flask is a lightweight and easy-to-use microframework for Python web development. diff --git a/docs/docs/self-hosting/manage/http2.mdx b/docs/docs/self-hosting/manage/http2.mdx index 6a342381a..d00e65679 100644 --- a/docs/docs/self-hosting/manage/http2.mdx +++ b/docs/docs/self-hosting/manage/http2.mdx @@ -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). diff --git a/docs/docs/self-hosting/manage/production.md b/docs/docs/self-hosting/manage/production.md index 98296281e..182df8927 100644 --- a/docs/docs/self-hosting/manage/production.md +++ b/docs/docs/self-hosting/manage/production.md @@ -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 | diff --git a/docs/docs/self-hosting/manage/reverseproxy/zitadel_cloud/zitadel_cloud.mdx b/docs/docs/self-hosting/manage/reverseproxy/zitadel_cloud/zitadel_cloud.mdx index ed074373b..dc917ad1e 100644 --- a/docs/docs/self-hosting/manage/reverseproxy/zitadel_cloud/zitadel_cloud.mdx +++ b/docs/docs/self-hosting/manage/reverseproxy/zitadel_cloud/zitadel_cloud.mdx @@ -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. diff --git a/docs/docs/self-hosting/manage/tls_modes.mdx b/docs/docs/self-hosting/manage/tls_modes.mdx index c77b02272..2732f4001 100644 --- a/docs/docs/self-hosting/manage/tls_modes.mdx +++ b/docs/docs/self-hosting/manage/tls_modes.mdx @@ -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). diff --git a/docs/docs/self-hosting/manage/updating_scaling.md b/docs/docs/self-hosting/manage/updating_scaling.md index b5bdff789..2f604895a 100644 --- a/docs/docs/self-hosting/manage/updating_scaling.md +++ b/docs/docs/self-hosting/manage/updating_scaling.md @@ -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. diff --git a/docs/docs/support/advisory/a10004.md b/docs/docs/support/advisory/a10004.md index ed5e8fabe..a00da5abf 100644 --- a/docs/docs/support/advisory/a10004.md +++ b/docs/docs/support/advisory/a10004.md @@ -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 diff --git a/docs/docs/support/advisory/a10005.md b/docs/docs/support/advisory/a10005.md index d414167c9..b10d108fe 100644 --- a/docs/docs/support/advisory/a10005.md +++ b/docs/docs/support/advisory/a10005.md @@ -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. diff --git a/docs/docs/support/technical_advisory.mdx b/docs/docs/support/technical_advisory.mdx index a5f0e323d..11eacc86e 100644 --- a/docs/docs/support/technical_advisory.mdx +++ b/docs/docs/support/technical_advisory.mdx @@ -90,10 +90,10 @@ We understand that these advisories may include breaking changes, and we aim to A-10004 Sequence uniquenesSequence uniqueness Breaking Behavior Change - 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 Expected downtime during upgrade 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. A-10012 Tncreased transaction duration for projectionsIncreased transaction duration for projections Breaking Behavior Change In version 2.63.0 we've increased the transaction duration for projections to resolve outdated projections or dead-locks. diff --git a/docs/docs/support/troubleshooting.mdx b/docs/docs/support/troubleshooting.mdx index fb08c07e4..29a8aba83 100644 --- a/docs/docs/support/troubleshooting.mdx +++ b/docs/docs/support/troubleshooting.mdx @@ -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)“** -![Same Site Strict Enforvement](/img/manuals/errors/same-site-strict.png) +![Same Site Strict Enforcement](/img/manuals/errors/same-site-strict.png) **Settings > Safari > disable: "Block All cookies"** ![Block all cookies](/img/manuals/errors/block-cookies.png)