Change variable enabling user registration

[TheLillo]

Now use matrix_homeserver_enable_registration instead of matrix_dendrite_registration_disabled and matrix_synapse_enable_registration #1615

[spantaleev]

Problems with this approach:

• the same variable (matrix_homeserver_enable_registration) is defined in multiple roles' defaults/main.yml. This may be confusing to us and may cause Ansible to issue a warning
• we should probably mark all of the old variables (matrix_synapse_enable_registration, matrix_dendrite_registration_disabled) as deprecated / superseded by another via roles/matrix-{dendrite,synapse}/tasks/validate_config.yml, so that users would start using the new variables.

---

I think a better way to do this is to keep the implementation specific variables that we have now:

• matrix_synapse_enable_registration
• matrix_dendrite_registration_disabled

Users are using them already and are discovering them by looking at roles/matrix-{dendrite,synapse}/defaults/main.yml, just like they're discovering variables for any other role.

We can keep things as they are, but also provide an extra variable (e.g. matrix_homeserver_registration_enabled - a name consistent with how we name such "enabling" booleans in the playbook), coming from the matrix-base role, which defaults to false there but is redefined like this in group_vars/matrix_severs:

matrix_homeserver_registration_enabled: |-
  {{
    {
      'synapse': matrix_synapse_enable_registration,
      'dendrite': not matrix_dendrite_registration_disabled,
    }[matrix_homeserver_implementation]
  }}

Other roles (matrix-client-element) can either use this new variable (matrix_homeserver_registration_enabled) directly or it can be passed to them via group_vars/matrix_servers.

I suppose this could work well and is exactly how we handle other things:

• matrix_homeserver_container_url
• matrix_homeserver_container_federation_url
• matrix_nginx_proxy_proxy_matrix_client_api_client_max_body_size_mb
• matrix_nginx_proxy_proxy_matrix_federation_api_enabled

However.. it does not bring us closer to an "homeserver implementation independent configuration". To have that, we'd need to do something else.

---

Here's another idea to achieve "homeserver implementation independent configuration".

We introduce this new matrix_homeserver_registration_enabled variable via matrix-base and default it to false there:

# Controls whether the homeserver exposes public registration.
# On a private server, you would normally not want this.
# To allow more controlled public registration, you may wish to look into supporting tools like matrix-registration.
matrix_homeserver_registration_enabled: false

group_vars/matrix_servers passes this along to the various homeserver implementations:

.....

matrix_synapse_enable_registration: "{{ matrix_homeserver_registration_enabled }}"

.....

matrix_dendrite_registration_disabled: "{{ not matrix_homeserver_registration_enabled }}"

.....

Then, we update the documentation for matrix_synapse_enable_registration and matrix_dendrite_registration_disabled in their respective roles' defaults/main.yml:

# Controls whether the homeserver exposes public registration.
# WARNING: if you'd like to change this setting, you should do it via the `matrix_homeserver_registration_enabled` variable.
matrix_synapse_enable_registration: false

But then we also need to tell people to switch away from directly using these old configuration options and switch to the new one (matrix_homeserver_registration_enabled). If they keep using matrix_synapse_enable_registration, then matrix_homeserver_registration_enabled becomes out of sync with it, and all other roles (which we've switched to using matrix_homeserver_registration_enabled) also become out of sync.

One way to solve this is to rename matrix_synapse_enable_registration to something else (e.g. matrix_synapse_config_enable_registration) and then deprecate matrix_synapse_enable_registration via roles/matrix-synapse/tasks/validate_config.yml (pointing users to matrix_homeserver_registration_enabled).

Hmmmm

[github-actions]

This PR is stale because it has been open a year with no activity. Remove stale label or this will be closed in 30 days.