Closed jaywink closed 3 years ago
I'm on the develop branch, as of yesterday and I can confirm that POSTS to /_matrix/client/r0/register
returns an error 401. My setup is: monolith, Postgres, not running in docker, go version 1.13.8. Registration on this server is open.
This endpoint is hit when attempting to register using the Element Android App. The fact that nobody can register with Element on Android on Dendrite servers is documented in the FAQ. Registration using Element web application works fine.
Just so people are aware: This is a barrier to adoption, as I can not tell friends to just download Element, register for an account on my homeserver and start using Matrix (which is exactly what I'd like to do).
My setup is: monolith, Postgres, not running in docker, go version 1.13.8. Registration on this server is closed. But I've set a registration_shared_secret. Alas I can not register any new users via the endpoint implemented in #257. I am sure that I am doing things wrong here - but where can one find the documentation of this feature? This is what I tried on this endpoint: `POST https://domain.tld/_matrix/client/api/v1/register
{ "auth": { "type": "org.matrix.login.shared_secret", "mac": "calculated-mac" }, "password": "password", "username": "username", "admin": false } `
I would really be happy to find a way that would make it possible to register via Element web application through a secret registration token.
Running into the same issue where I want to register users in matrix via an api wrapper using the shared secret.
Digging into the codebase my best guess atm is here https://github.com/matrix-org/dendrite/blob/802f1c96f804f7a146e4e12e25b20c980a6af870/setup/config/config.go#L284
If I understand this correctly the m.login.dummy
stage is appended in to the derived registration flow
Is this where the problem lies?
does there need to be a check here to not append the m.login.dummy
stage into the flow for these config options:
registration_disabled: true
registration_shared_secret: "supersecretstring"
There currently isn't support for this. https://github.com/matrix-org/dendrite/pull/1822 removed the legacy v1
endpoint.
For anyone else coming here, 0.3.11 (the latest released, docker version, etc) still supports the v1 endpoint. You can use https://github.com/matrix-org/synapse/blob/develop/synapse/_scripts/register_new_matrix_user.py with it with the following change - replace url through data with:
url = "%s/_matrix/client/api/v1/register" % (server_location.rstrip("/"),)
mac = hmac.new(key=shared_secret.encode("utf8"), digestmod=hashlib.sha1)
mac.update(user.encode("utf8"))
mac.update(b"\x00")
mac.update(password.encode("utf8"))
mac.update(b"\x00")
mac.update(b"admin" if admin else b"notadmin")
mac = mac.hexdigest()
data = {
"user": user,
"password": password,
"type": "org.matrix.login.shared_secret",
"mac": mac,
"admin": admin,
}
If you're running Dendrite 0.4.0 then you can use the synapse register_new_matrix_user
script without any modification.
Background information
go version
: official matrix-org docker imagesDescription
This could be thought of as not really a bug, since the C2S spec does not have shared secret registration (afaict). However, Dendrite implements one since #257. It doesn't seem to fully work currently (or I'm using it incorrectly).
Currently shared secret registration when configured can be done on two endpoints (based on PR). The first one is the real r0 client register endpoint, which according to spec doesn't have this possibility. Dendrite however does recognize the
org.matrix.login.shared_secret
login type on this endpoint.Returns the following:
Retrying the same request with the
session
added toauth
just returns yet another session, with next stage againm.login.dummy
. Trying to change stage tom.login.dummy
returns "registrations are closed" (since this homeserver has registrations closed).Rather than this be fixed, it probably should not exist on this endpoint at all but rather an admin endpoint, like in Synapse?
The other endpoint (
/_matrix/client/api/v1/register
) implemented in #257 does work with the shared registration token (and I hope wont be removed before it works on some other admin type of endpoint :)).Relates to #1299 as well.