diff --git a/.github/workflows/spellcheck.yml b/.github/workflows/spellcheck.yml
new file mode 100644
index 0000000000..a2590ac451
--- /dev/null
+++ b/.github/workflows/spellcheck.yml
@@ -0,0 +1,19 @@
+name: Spellcheck
+
+on:
+ push:
+ branches: [master]
+ pull_request:
+ branches: [master]
+
+jobs:
+ spellcheck:
+ name: Typo CI (GitHub Action)
+ runs-on: ubuntu-latest
+ timeout-minutes: 4
+ if: "!contains(github.event.head_commit.message, '[ci skip]')"
+ steps:
+ - name: TypoCheck
+ uses: typoci/spellcheck-action@master
+ env:
+ GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
\ No newline at end of file
diff --git a/.typo-ci.yml b/.typo-ci.yml
new file mode 100644
index 0000000000..87864246f5
--- /dev/null
+++ b/.typo-ci.yml
@@ -0,0 +1,40 @@
+# What language dictionaries should it use? Currently Typo CI supports:
+# de
+# en
+# en_GB
+# es
+# fr
+# it
+# pt
+# pt_BR
+dictionaries:
+ - en
+ - en_GB
+ - de
+
+# Any files/folders we should ignore?
+excluded_files:
+ - ".codecov/*"
+ - ".github/*"
+ - "build/*"
+ - "k8s/*"
+ - "*.min.css"
+ - "*.css.map"
+ - "*.min.js"
+ - "*.js.map"
+ - "package-lock.json"
+ - "package.json"
+ - ".releaserc.js"
+ - ".typo-ci.yml"
+ - ".gitignore"
+ - "go.mod"
+ - "go.sum"
+
+# Any typos we should ignore?
+excluded_words:
+ - typoci
+ - idps
+ - ZITADEL's
+
+# Would you like filenames to also be spellchecked?
+spellcheck_filenames: false
\ No newline at end of file
diff --git a/site/README.md b/site/README.md
index 280ec84bca..39a375934b 100644
--- a/site/README.md
+++ b/site/README.md
@@ -13,6 +13,6 @@ npm i
Start the server with `npm run dev`, and navigate to [localhost:3000](http://localhost:3000).
-### Honorable Mentions
+## Honorable Mentions
This project was created with the help of some components from [svelte](https://github.com/sveltejs/svelte)([MIT](https://github.com/sveltejs/svelte/blob/master/LICENSE)) as well as [site-kit](https://github.com/sveltejs/site-kit)([MIT](https://github.com/sveltejs/site-kit/blob/master/LICENSE)).
\ No newline at end of file
diff --git a/site/docs/administrate/01-console.en.md b/site/docs/administrate/01-console.en.md
index 2855f83bee..a1bba8a56b 100644
--- a/site/docs/administrate/01-console.en.md
+++ b/site/docs/administrate/01-console.en.md
@@ -6,7 +6,7 @@ title: Console
Console is the ZITADEL Graphical User Interface.
-**Users** can manage some information by their own.
+**Users** can manage some information on their own.
- profile information
- credentials
diff --git a/site/docs/administrate/02-organisations.en.md b/site/docs/administrate/02-organisations.en.md
index 8ead0848bb..c9c3968509 100644
--- a/site/docs/administrate/02-organisations.en.md
+++ b/site/docs/administrate/02-organisations.en.md
@@ -70,8 +70,7 @@ To start the domain verification click the domain name and a dialog will appear,
Organisation Domain Verify
-
-For example, create a TXT record with your DNS provider for the used domain an click verify. **ZITADEL** will then proceed an check your DNS.
+For example, create a TXT record with your DNS provider for the used domain and click verify. **ZITADEL** will then proceed an check your DNS.
-
> Do not delete the verification code **ZITADEL** will recheck the ownership from time to time
When the verification is successful you have the option to activate the domain by clicking **Set as primary**
@@ -97,8 +95,7 @@ When the verification is successful you have the option to activate the domain b
> This changes the **preferred loginnames** of your [users](administrate#Users) as indicated [here](administrate#How_ZITADEL_handles_usernames).
-Gratulations your are done! You can check this by visiting [https://console.zitadel.ch/users/me](https://console.zitadel.ch/users/me)
-
+Congratulations your are done! You can check this by visiting [https://console.zitadel.ch/users/me](https://console.zitadel.ch/users/me)
-Create a new project with name which explains what's the intended use of this project.
+Create a new project with a name which explains what's the intended use of this project.
diff --git a/site/docs/administrate/04-clients.en.md b/site/docs/administrate/04-clients.en.md
index 78d4632aee..d8ac5003b1 100644
--- a/site/docs/administrate/04-clients.en.md
+++ b/site/docs/administrate/04-clients.en.md
@@ -5,7 +5,7 @@ title: Clients
### What are clients
Clients are applications who share the same security context and interface with an "authorization server".
-For example you could have a software project existing out of a web app and a mobile app, both of these application might consume the same roles because the end user might use both of them.
+For example you could have a software project existing out of a web app and a mobile app, both of these applications might consume the same roles because the end user might use both of them.
### Manage clients
diff --git a/site/docs/administrate/05-roles.en.md b/site/docs/administrate/05-roles.en.md
index 0feb362fc7..82028b3311 100644
--- a/site/docs/administrate/05-roles.en.md
+++ b/site/docs/administrate/05-roles.en.md
@@ -4,11 +4,11 @@ title: Roles
### What are Roles
-With **roles** **ZITADEL** lets [projects](administrate#projects) define there **role based access controle**.
+With **roles** **ZITADEL** lets [projects](administrate#projects) define there **role based access control**.
-**Roles** can be consumed by the [clients](administrate#clients) which exist witing a specific [project](administrate#projects).
+**Roles** can be consumed by the [clients](administrate#clients) which exist within a specific [project](administrate#projects).
-For more information about how **roles** can be consumed have a look the the protocol specific information.
+For more information about how **roles** can be consumed, have a look the protocol specific information.
- [OpenID Connect / OAuth](integrate#How_to_consume_authorizations_in_your_application_or_service)
@@ -22,13 +22,13 @@ Each **role** consist of three fields.
| Display Name | A descriptive text for the purpose of the **Role** | User is the default role provided to each person |
| Group | The group field allows to group certain roles who belong in the same context | User and Admin in the group **default** |
-### Grantig Roles
+### Granting Roles
To give someone (or somewhat) access to a [projects](administrate#projects) resources and services **ZITADEL** provides to processes. **Roles** can be either granted to [users](administrate#Users) org to [organisations](administrate#Organisations).
#### Grant Roles to Organisations
-The possibility to grant **roles** to an [organisation](administrate#Organisations) is intented as "delegation" so that a [org](administrate#Organisations) can on their own grant access to [users](administrate#Users).
+The possibility to grant **roles** to an [organisation](administrate#Organisations) is intended as "delegation" so that a [org](administrate#Organisations) can on their own grant access to [users](administrate#Users).
For example a **service provider** could grant the **roles** user, and manager to an [org](administrate#Organisations) as soon as they purchases his service. This can be automated by utilising a [service user](administrate#Manage_Service_Users) in the **service providers** business process.
@@ -36,6 +36,6 @@ For example a **service provider** could grant the **roles** user, and manager t
#### Grant Roles to Users
-By granting **roles** to [users](administrate#Users), be it [humanes or machines](administrate#Human_vs_Service_Users), this [user](administrate#Users) recieves the authorization to access resources from a service.
+By granting **roles** to [users](administrate#Users), be it [humans or machines](administrate#Human_vs_Service_Users), this [user](administrate#Users) receives the authorization to access resources from a service.
> Screenshot here
diff --git a/site/docs/administrate/06-users.en.md b/site/docs/administrate/06-users.en.md
index 0663545ad1..770d2750f6 100644
--- a/site/docs/administrate/06-users.en.md
+++ b/site/docs/administrate/06-users.en.md
@@ -9,14 +9,14 @@ Nonetheless we treat them all the same in regard to [roles](administrate#Roles)
#### Human vs. Service Users
-The major difference between humane vs. machine [users](administrate#Users) is the type of credentials who can be used.
-With machine [users](administrate#Users) there is only a non interactive login process possible. As such we utilize “JWT as Authorization Grant”.
+The major difference between human vs. machine [users](administrate#Users) is the type of credentials who can be used.
+With machine [users](administrate#Users) there is only a non interactive logon process possible. As such we utilize “JWT as Authorization Grant”.
> TODO Link to “JWT as Authorization Grant” explanation.
### How ZITADEL handles usernames
-**ZITADEL** is built around the concept of [organisations](administrate#Organisations). Each [organisation](administrate#Organisations) has it's own pool of usernames which include human and service [users](administrate#Users).
+**ZITADEL** is built around the concept of [organisations](administrate#Organisations). Each [organisation](administrate#Organisations) has its own pool of usernames which include human and service [users](administrate#Users).
For example a [user](administrate#Users) with the username `road.runner` can only exist once the [organisation](administrate#Organisations) `ACME`. **ZITADEL** will automatically generate a "logonname" for each [user](administrate#Users) consisting of `{username}@{domainname}.{zitadeldomain}`. Without verifying the domain name this would result in the logonname `road.runner@acme.zitadel.ch`. If you use a dedicated **ZITADEL** replace `zitadel.ch` with your domain name.
If someone verifies a domain name within the organisation **ZITADEL** will generate additional logonames for each [user](administrate#Users) with that domain. For example if the domain is `acme.ch` the resulting logonname would be `road.runner@acme.ch` and as well the generated one `road.runner@acme.zitadel.ch`.
diff --git a/site/docs/administrate/07-policies.en.md b/site/docs/administrate/07-policies.en.md
index 962d9eb65e..22120393dd 100644
--- a/site/docs/administrate/07-policies.en.md
+++ b/site/docs/administrate/07-policies.en.md
@@ -4,8 +4,8 @@ title: Policies
### What are policies
-Polices are a means of enforcing certain behavior of ZITADEL.
-ZITADEL defines a default policy on the system level. However a org. owner can change these aspects within his own org.
+Policies are a means of enforcing certain behaviour of ZITADEL.
+ZITADEL defines a default policy on the system level. However an organisation owner can change these aspects within his own organisation.
Below is a list of available policies
@@ -24,7 +24,7 @@ This policy enforces passwords of users within the org. to be compliant.
### IAM Access Preference
This policy enforces, when set to true, that usernames are suffixed with the organisations domain.
-Under normal operation this policy is only false on the `global` org. so that users can choose there email as username.
+Under normal operation this policy is only false on the `global` org. so that users can choose their email as their username.
Only available for the `IAM Administrator`
> Screenshot here
diff --git a/site/docs/administrate/08-providers.en.md b/site/docs/administrate/08-providers.en.md
index 9b8638b202..e2a7a8eb4f 100644
--- a/site/docs/administrate/08-providers.en.md
+++ b/site/docs/administrate/08-providers.en.md
@@ -4,7 +4,7 @@ title: Identity Providers
### What are Identity Providers
-Identity providers or in short idp's are external systems to which **ZITADEL** can create a **federation** or use their **directory service**.
+Identity providers or in short idps are external systems to which **ZITADEL** can create a **federation** or use their **directory service**.
Normally federation uses protocols like [OpenID Connect 1.0](https://openid.net/connect/), [OAuth 2.0](https://oauth.net/2/) and [SAML 2.0](http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html).
Some examples include:
@@ -33,7 +33,7 @@ Some examples include:
### What is Identity Brokering
-ZITADEL supports the usage as identity broker, by linking multiple external idp's into one user.
+ZITADEL supports the usage as identity broker, by linking multiple external idps into one user.
With identity brokering the client which relies on ZITADEL does not need to care about the linking of identity.
### Manage Identity Providers
@@ -54,13 +54,13 @@ SAML 2.0 will follow later on.
> This is a work in progress.
Storage federation is a means of integrating existing identity storage like [LDAP](https://tools.ietf.org/html/rfc4511) and [ADDS](https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/virtual-dc/active-directory-domain-services-overview).
-With this process **ZITADEL** can authenticate users with LDAP Binding and SPNNEGO for ADDS. It is also possible to synchronize the users just-in-time or scheduled.
+With this process **ZITADEL** can authenticate users with LDAP Binding and SPNEGO for ADDS. It is also possible to synchronize the users just-in-time or scheduled.
#### Sync Settings
Here we will document all the different sync options
-- Readonly
+- Read-only
- Writeback
- just-in-time sync
- scheduled sync
diff --git a/site/docs/administrate/90-system.en.md b/site/docs/administrate/90-system.en.md
index 6ad18b691e..b8cfdef97c 100644
--- a/site/docs/administrate/90-system.en.md
+++ b/site/docs/administrate/90-system.en.md
@@ -8,16 +8,16 @@ System describes the root of ZITADEL and includes all other elements like organi
### Default Policies
-When ZITADEL is setup for the first time we establish certain default polices for the whole system.
+When ZITADEL is set up for the first time we establish certain default policies for the whole system.
> TODO Document default policy settings
### Manage Read Models
-Read Models are a way to normalize data out of the event stream for certain aspects. For example there is a model which consist of logonname and the password hash so that the login process can query that data.
+Read Models are a way to normalize data out of the event stream for certain aspects. For example there is a model which consists of logonname and the password hash so that the login process can query that data.
-All read models are eventual consistent by nature and sometimes an administrator would like to verify they are still up-to date.
-In the ZITADEL Console is a section called administration available where the admin can check all read models and there current state.
+All read models are eventually consistent by nature and sometimes an administrator would like to verify they are still up-to-date.
+In the ZITADEL Console is a section called administration available where the admin can check all read models and their current state.
There is even a possibility to regenerate a read model.
> When a read model is regenerated it might take up some time to be fully operational again
@@ -27,7 +27,7 @@ There is even a possibility to regenerate a read model.
### Secret Handling
-ZITADEL store secrets always encrypted or hashed in it's storage.
+ZITADEL stores secrets always encrypted or hashed in it's storage.
Whenever feasible we try to utilize public / private key mechanics to handle secrets.
**Encryption**
@@ -44,7 +44,7 @@ These keys are randomly generated within ZITADEL and are rotated on a regular ba
> Signing keys are stored with AES256 encryption
**TLS**
-Under normal operations ZITADEL's API nodes are located behind a reverse proxy. So the TLS Key handlings is out of context in this regard.
+Under normal operations ZITADEL's API nodes are located behind a reverse proxy. So the TLS Key handling are out of context in this regard.
However ZITADEL can use TLS keys at runtime level.
> TODO Document TLS config
diff --git a/site/docs/develop/00-overview.en.md b/site/docs/develop/00-overview.en.md
index c343979711..ec508cc0a8 100644
--- a/site/docs/develop/00-overview.en.md
+++ b/site/docs/develop/00-overview.en.md
@@ -10,7 +10,7 @@ description: …
---
ZITADEL provides three API's for different use cases. These API's are built with GRPC and then generate a REST service.
-Each services proto definition is located in the source control on GitHub.
+Each service's proto definition is located in the source control on GitHub.
As we generate the REST services and Swagger file out of the proto definition we recommend that you rely on the proto file.
We annotate the corresponding REST methods on each possible call as well as the AuthN and AuthZ requirements.
@@ -28,10 +28,10 @@ See below for an example with the call **GetMyUser**.
};
}
```
-
---
-As you can see the `GetMyUser` function is also available as REST service under the path `/users/me`.
+As you can see the `GetMyUser` function is also available as a REST service under the path `/users/me`.
+
In the table below you can see the URI of those calls.
| Service | URI |
diff --git a/site/docs/develop/02-management.en.md b/site/docs/develop/02-management.en.md
index f91e9e5086..a0af334c7a 100644
--- a/site/docs/develop/02-management.en.md
+++ b/site/docs/develop/02-management.en.md
@@ -5,7 +5,7 @@ description: …
### Management
-The management API is as the name states the interface where systems can mutate IAM objects like, organisations, projects, clients, user and so on if they have the necessary access rights.
+The management API is as the name states the interface where systems can mutate IAM objects like, organisations, projects, clients, users and so on if they have the necessary access rights.
| Service | URI |
|:--------|:----------------------------------------------------------------------------------------------------------------------------------------------------|
diff --git a/site/docs/documentation/01-priciples.en.md b/site/docs/documentation/01-priciples.en.md
index 6ec0db438f..c9267b939d 100644
--- a/site/docs/documentation/01-priciples.en.md
+++ b/site/docs/documentation/01-priciples.en.md
@@ -15,9 +15,9 @@ title: Principles
- Embrace automation
- Design API first
- Optimize all components for day-two operations
-- Use only opensource projects with permissive licenses
+- Use only open source projects with permissive licenses
- Don't roll your own crypto algorithm
- Embrace (industry) standard as much as possible
- Make use of platform features
- Be able to run with a CDN and WAF
-- Releases utilized sematic versioning and release whenever feasible
+- Releases utilized semantic versioning and release whenever feasible
diff --git a/site/docs/documentation/03-openidoauth.en.md b/site/docs/documentation/03-openidoauth.en.md
index efa1a5c855..f37520a7ea 100644
--- a/site/docs/documentation/03-openidoauth.en.md
+++ b/site/docs/documentation/03-openidoauth.en.md
@@ -17,8 +17,8 @@ Under normal circumstances **ZITADEL** need four domain names to operate properl
#### OpenID Connect 1.0 Discovery
-The OpenID Connect Discovery Endpoint is located with the issuer domain.
-For example with [zitadel.ch](https://zitadel.ch) this would be the domain [issuer.zitadel.ch](https://issuer.zitadel.ch). This would give us [https://issuer.zitadel.ch/.well-known/openid-configuration](https://issuer.zitadel.ch/.well-known/openid-configuration).
+The OpenID Connect Discovery Endpoint is located within the issuer domain.
+For example with [zitadel.ch](zitadel.ch) this would be the domain [issuer.zitadel.ch](issuer.zitadel.ch). This would give us [https://issuer.zitadel.ch/.well-known/openid-configuration](https://issuer.zitadel.ch/.well-known/openid-configuration).
**Link to spec.** [OpenID Connect Discovery 1.0 incorporating errata set 1](https://openid.net/specs/openid-connect-discovery-1_0.html)
@@ -65,7 +65,7 @@ In addition to the standard compliant scopes we utilize the following scopes.
| Scope | Description | Example |
|:------------------------------------------------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------|
| urn:zitadel:iam:org:project:role:{rolename} | By using this scope a [client](administrate#clients) can request the claim urn:zitadel:iam:roles:rolename} to be asserted when possible. As an alternative approach you can enable all [roles](administrate#Roles) to be asserted from the [project](administrate#projects) a [client](administrate#clients) belongs to. See details [here](administrate#RBAC_Settings) | urn:zitadel:iam:org:project:role:user |
-| urn:zitadel:iam:org:domain:primary:{domainname} | When requesting this scope **ZITADEL** will enforce that the user is member of the selected organisation. If the organisation does not exist a failure is displayed | urn:zitadel:iam:org:domain:primary:acme.ch |
+| urn:zitadel:iam:org:domain:primary:{domainname} | When requesting this scope **ZITADEL** will enforce that the user is a member of the selected organisation. If the organisation does not exist a failure is displayed | urn:zitadel:iam:org:domain:primary:acme.ch |
| urn:zitadel:iam:role:{rolename} | | |
### Claims
@@ -133,7 +133,7 @@ For a list of supported or unsupported `Grant Types` please have a look at the t
#### Resource Owner Password Credentials
-> Due to growing security concern we do not support this grant type. With OAuth 2.1 it looks like this grant will be removed.
+> Due to growing security concerns we do not support this grant type. With OAuth 2.1 it looks like this grant will be removed.
**Link to spec.** [OThe OAuth 2.0 Authorization Framework Section 1.3.3](https://tools.ietf.org/html/rfc6749#section-1.3.3)
diff --git a/site/docs/start/00-quick-start.en.md b/site/docs/start/00-quick-start.en.md
index 855f25f81e..6f2a15e85f 100644
--- a/site/docs/start/00-quick-start.en.md
+++ b/site/docs/start/00-quick-start.en.md
@@ -12,7 +12,7 @@ You can either use [ZITADEL.ch](https://zitadel.ch) or deploy a dedicated **ZITA
### Use ZITADEL.ch
To register your free [organisation](administrate#Organisations), visit this link [register organisation](https://accounts.zitadel.ch/register/org).
-After accepting the TOS and filling out all the required fields you will receive a email with further instructions.
+After accepting the TOS and filling out all the required fields you will receive an email with further instructions.
@@ -25,7 +25,7 @@ After accepting the TOS and filling out all the required fields you will receive
#### Verify your domain name (optional)
-When you verify your domain you get the benefit that your [organisations](administrate#Organisations) [users](administrate#Users) can use this domain as **preferred loginname**. You find a more detailed explanation [How ZITADEL handles usernames](administrate#How_ZITADEL_handles_usernames).
+When you verify your domain you get the benefit that your [organisations](administrate#Organisations) [users](administrate#Users) can use this domain as **preferred logonname**. You find a more detailed explanation [How ZITADEL handles usernames](administrate#How_ZITADEL_handles_usernames).
The verification process is documented [here](administrate#Verify_a_domain_name)
 -Basically these are you applications who initiate the authorization flow. +Basically these are your applications who initiate the authorization flow. **Roles** -[Roles (or Project Roles)](administrate#Roles) is a mean of managing users access rights for a certain project. +[Roles (or Project Roles)](administrate#Roles) is a means of managing users access rights for a certain project. These [roles](administrate#Roles) are opaque for ZITADEL and have no weight in relation to each other. So if a [user](administrate#Users) has two roles, admin and user in a certain project, the information will be treated additive. **Grants** With ZITADEL it is possible to give third parties (other organisations) the possibility to manage certain roles on their own. -To achieve this the owner of a project can grant (some could say delegate) certain roles or all roles to a organisation. +To achieve this the owner of a project can grant (some could say delegate) certain roles or all roles to an organisation. After granting that organisation it can manage on its own which user has what roles. This feature is especially useful for service providers, because they are able to establish a great self-service culture for their business customers. @@ -34,7 +34,7 @@ This feature is especially useful for service providers, because they are able t #### Project vs. granted Project The simple difference of a project vs a granted project is that a project belongs to your organisation and the granted project belongs to a third party who did grant you some rights to manage certain roles of their project. -To make it more easily to differentiate ZITADEL Console displays these both as separate menu in the project section. +To make it more easier to differentiate, ZITADEL Console displays these both as separate menu in the project section. ### Manage a project @@ -51,7 +51,7 @@ To create your project go to [https://console.zitadel.ch/projects](https://conso](img/console_user_personal_info.png){kind=link}