[GH-ISSUE #1231] meta: Inconsistent user/group IDs #435

New issue

Closed

opened 2026-02-27 08:17:17 +03:00 by kerem · 1 comment

kerem commented

2026-02-27 08:17:17 +03:00

Owner

Originally created by @selfhoster1312 on GitHub (Jul 22, 2025).
Original GitHub issue: https://github.com/lldap/lldap/issues/1231

When reading through the code, i was confused with UserId and GroupId:

UserId is a stringy value with a unique constraint… it can contain anything including spaces
GroupId is an incrementing counter

Both Group and User also have a display_name and a uuid.

I first encountered this when i created a user with an id containing @ like user@foo.com. What's confusing about it:

the field in the form is called User name to set the ID
a username is usually only lowercase characters without spaces and special chars, so that it can be mapped to POSIX account names
there is also a Display name input in the form for free-form text ; the only difference is that Display name has no index

The problem becomes more apparent when messing around:

create a user with ID foo @ mywtf.net/whut
click on the user to edit it
browser URL changes to http://localhost:17170/user/foo%20@%20mywtf.net/whut but nothing happens
reload
get redirected to /users

I'm not sure what the best action is but some notes:

what's called an Id (UserId/GroupId) in the code should refer to the same "kind" of types, like an integer, or a POSIX identifier
i think usernames should not be a free-form column… or at least we should carefully consider the implications of that (including in terms of routing in the SPA and integration with other systems), and document it accordingly
maybe UserId/GroupId should only have incrementing ids? or only have UUIDs? why have both? are UUIDs used for anything? they don't even have an index on them in the SQL database
lowercase, no-space identifiers are useful for translations in end-user-facing systems
maybe it's too late to change what ID means in the APIs (GraphQL/LDAP) because that would break existing configs and integrations, but it may be worth documenting more and maybe changing in the backend code

Originally created by @selfhoster1312 on GitHub (Jul 22, 2025). Original GitHub issue: https://github.com/lldap/lldap/issues/1231 When reading through the code, i was confused with `UserId` and `GroupId`: - `UserId` is a stringy value with a unique constraint… it can contain anything including spaces - `GroupId` is an incrementing counter Both Group and User also have a `display_name` and a `uuid`. I first encountered this when i created a user with an id containing `@` like `user@foo.com`. What's confusing about it: - the field in the form is called `User name` to set the ID - a username is usually only lowercase characters without spaces and special chars, so that it can be mapped to POSIX account names - there is also a `Display name` input in the form for free-form text ; the only difference is that Display name has no index The problem becomes more apparent when messing around: - create a user with ID `foo @ mywtf.net/whut` - click on the user to edit it - browser URL changes to `http://localhost:17170/user/foo%20@%20mywtf.net/whut` but nothing happens - reload - get redirected to `/users` I'm not sure what the best action is but some notes: - what's called an Id (UserId/GroupId) in the code should refer to the same "kind" of types, like an integer, or a POSIX identifier - i think usernames should not be a free-form column… or at least we should carefully consider the implications of that (including in terms of routing in the SPA and integration with other systems), and document it accordingly - maybe UserId/GroupId should only have incrementing ids? or only have UUIDs? why have both? are UUIDs used for anything? they don't even have an index on them in the SQL database - lowercase, no-space identifiers are useful for translations in end-user-facing systems - maybe it's too late to change what ID means in the APIs (GraphQL/LDAP) because that would break existing configs and integrations, but it may be worth documenting more and maybe changing in the backend code

kerem closed this issue

2026-02-27 08:17:17 +03:00

kerem commented

2026-02-27 08:17:18 +03:00

Author

Owner

@nitnelave commented on GitHub (Oct 4, 2025):

The short story is that users cannot be renamed, but groups can. The UUIDs were added later on for compatibility with systems who require that as a marker of identity of the entity (e.g. when renaming groups), because they assume that anything can be renamed.

There are some issues handling "complex" user IDs in the frontend, and there are some open issues to tighten the range of names allowed as user IDs (https://github.com/lldap/lldap/issues/239 for instance).

Though email addresses are perfectly fine, so if the frontend doesn't handle them correctly, that's a bug. Could you open a separate issue for this? I don't intend to address the underlying concern that the IDs should be of the same type, but the routing issue is indeed a bug.

@nitnelave commented on GitHub (Oct 4, 2025): The short story is that users cannot be renamed, but groups can. The UUIDs were added later on for compatibility with systems who require that as a marker of identity of the entity (e.g. when renaming groups), because they assume that anything can be renamed. There are some issues handling "complex" user IDs in the frontend, and there are some open issues to tighten the range of names allowed as user IDs (https://github.com/lldap/lldap/issues/239 for instance). Though email addresses are perfectly fine, so if the frontend doesn't handle them correctly, that's a bug. Could you open a separate issue for this? I don't intend to address the underlying concern that the IDs should be of the same type, but the routing issue is indeed a bug.