LDAP users can have broken MXIDs #1129

Open
opened 2025-10-17 22:00:51 +00:00 by Clubs · 2 comments

When using an LDAP provider, which supplies Continuwuity with a name that contains unusable characters, they are added to the database and the user can somewhat use their client, until the point that it conflicts with other users and servers trying to interact with that user.

Example setup:

  • A server running Authentik, which connects to Continuwuity to provide LDAP services
  • The Authentik server allows a user to have the display name !$%^&*# @ (including the space between the # and the @)
  • A Continuwuity server running with these LDAP configurations:
[global.ldap]
enable = true
ldap_only = true
uri = "ldap://<address and port>"
base_dn = "dc=ldap,dc=goauthentik,dc=io"
bind_dn = "cn=<ldap user>,ou=users,dc=ldap,dc=goauthentik,dc=io"
bind_password_file = "<password path>"
uid_attribute = "name"
name_attribute = "displayName"
  • An unmodified version of the Cinny client

With that setup, that user can log in with their password, and once logged in will be shown that they have the following handle: @!$%^&*# @:bearware.dev (including the space).

So far I've found that users containing invalid characters can still do most of the basic tasks if a client can parse it. Cinny's autocomplete will allow the user to send invites and receive invites (though they show up as unknown instead of their username). It will also try to autocomplete for things like @s, but attempting to mention a user with those characters in their username tends to result in it appearing like a clickable link, with results depending on where the characters are in the game. While most chat functions work, if you dont have a client's autocomplete or search functions, it makes it almost impossible to properly invite a user, including with the use of chat commands. The user can also federate (at least, with other continuwuity servers) without extra issue. Neither log from the Continuwuity server shows any output from any of these actions

When using an LDAP provider, which supplies Continuwuity with a name that contains unusable characters, they are added to the database and the user can somewhat use their client, until the point that it conflicts with other users and servers trying to interact with that user. Example setup: - A server running Authentik, which connects to Continuwuity to provide LDAP services - The Authentik server allows a user to have the display name `!$%^&*# @` (including the space between the # and the @) - A Continuwuity server running with these LDAP configurations: ``` [global.ldap] enable = true ldap_only = true uri = "ldap://<address and port>" base_dn = "dc=ldap,dc=goauthentik,dc=io" bind_dn = "cn=<ldap user>,ou=users,dc=ldap,dc=goauthentik,dc=io" bind_password_file = "<password path>" uid_attribute = "name" name_attribute = "displayName" ``` - An unmodified version of the Cinny client With that setup, that user can log in with their password, and once logged in will be shown that they have the following handle: `@!$%^&*# @:bearware.dev` (including the space). So far I've found that users containing invalid characters can still do most of the basic tasks if a client can parse it. Cinny's autocomplete will allow the user to send invites and receive invites (though they show up as unknown instead of their username). It will also try to autocomplete for things like @s, but attempting to mention a user with those characters in their username tends to result in it appearing like a clickable link, with results depending on where the characters are in the game. While most chat functions work, if you dont have a client's autocomplete or search functions, it makes it almost impossible to properly invite a user, including with the use of chat commands. The user can also federate (at least, with other continuwuity servers) without extra issue. Neither log from the Continuwuity server shows any output from any of these actions
Owner

Those are technically legal user IDs, although I'm not sure the check that is normally run should be allowed to bypass for LDAP registrations

Those are [technically legal user IDs](https://spec.matrix.org/v1.16/appendices/#historical-user-ids), although I'm not sure the check that is normally run should be allowed to bypass for LDAP registrations
Author

Ah gotcha, I didn't see that the section for historic IDs, good to know. From my perspective using LDAP here, it definitely feels unexpected that the check doesnt run like it would otherwise if you use LDAP, though my usage of LDAP is pretty limited

Ah gotcha, I didn't see that the section for historic IDs, good to know. From my perspective using LDAP here, it definitely feels unexpected that the check doesnt run like it would otherwise if you use LDAP, though my usage of LDAP is pretty limited
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
continuwuation/continuwuity#1129
No description provided.