Browse Source
Update docs/configuring-playbook-jitsi.md: move the description about meetings with authentication enabled out of the section for the default authentication method
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>pull/3934/head
Suguru Hirahara
1 year ago
No known key found for this signature in database
GPG Key ID: E4F9743DAB4B7B75
1 changed files with 3 additions and 2 deletions
Unified View
Diff Options
+ 3
- 2
docs/configuring-playbook-jitsi.md
View File
| @@ -46,14 +46,14 @@ By default the Jitsi instance does not require for anyone to log in, and is open | |||||
| Currently, there are three supported authentication methods: `internal` (default), `matrix` and `ldap`. | Currently, there are three supported authentication methods: `internal` (default), `matrix` and `ldap`. | ||||
| With authentication enabled, all meetings have to be started by a registered user. After the meeting is started by that user, then guests are free to join. If the registered user is not yet present, the guests are put on hold in individual waiting rooms. | |||||
| **Note**: authentication is not tested by the playbook's self-checks. We therefore recommend that you would make sure by yourself that authentication is configured properly. To test it, start a meeting at `jitsi.example.com` on your browser. | **Note**: authentication is not tested by the playbook's self-checks. We therefore recommend that you would make sure by yourself that authentication is configured properly. To test it, start a meeting at `jitsi.example.com` on your browser. | ||||
| #### Authenticate using Jitsi accounts: Auth-Type `internal` (recommended) | #### Authenticate using Jitsi accounts: Auth-Type `internal` (recommended) | ||||
| The default authentication mechanism is `internal` auth, which requires a Jitsi account to have been configured. This is a recommended method, as it also works in federated rooms. | The default authentication mechanism is `internal` auth, which requires a Jitsi account to have been configured. This is a recommended method, as it also works in federated rooms. | ||||
| With authentication enabled, all meetings have to be started by a registered user. After the meeting is started by that user, then guests are free to join. If the registered user is not yet present, the guests are put on hold in individual waiting rooms. | |||||
| To enable authentication with a Jitsi account, add the following configuration to your `vars.yml` file. Make sure to replace `USERNAME_…` and `PASSWORD_…` with your own values. | To enable authentication with a Jitsi account, add the following configuration to your `vars.yml` file. Make sure to replace `USERNAME_…` and `PASSWORD_…` with your own values. | ||||
| ```yaml | ```yaml | ||||
| @@ -74,6 +74,7 @@ jitsi_prosody_auth_internal_accounts: | |||||
| This authentication method requires [Matrix User Verification Service](https://github.com/matrix-org/matrix-user-verification-service), which can be installed using this [playbook](configuring-playbook-user-verification-service.md). By default, the playbook creates and configures a user-verification-service so that it runs locally. | This authentication method requires [Matrix User Verification Service](https://github.com/matrix-org/matrix-user-verification-service), which can be installed using this [playbook](configuring-playbook-user-verification-service.md). By default, the playbook creates and configures a user-verification-service so that it runs locally. | ||||
| To enable authentication with Matrix OpenID, add the following configuration to your `vars.yml` file: | To enable authentication with Matrix OpenID, add the following configuration to your `vars.yml` file: | ||||
| ```yaml | ```yaml | ||||