[GH-ISSUE #287] Self registration with invite code?

kerem commented

2026-02-27 08:15:16 +03:00

Owner

Originally created by @poVoq on GitHub (Aug 20, 2022).
Original GitHub issue: https://github.com/lldap/lldap/issues/287

Would it be possible to have the option in the webinterface to allow users to register themselves with an invite code?

Invite codes could be permanent or time/number-limited?

Maybe users could even be allowed to generate their own invite codes?

Originally created by @poVoq on GitHub (Aug 20, 2022). Original GitHub issue: https://github.com/lldap/lldap/issues/287 Would it be possible to have the option in the webinterface to allow users to register themselves with an invite code? Invite codes could be permanent or time/number-limited? Maybe users could even be allowed to generate their own invite codes?

kerem

2026-02-27 08:15:16 +03:00

closed this issue
added the
enhancement

wontfix

frontend

backend
labels

kerem commented

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

Author

Owner

@poVoq commented on GitHub (Jan 25, 2023):

While this would be still nice to have in LLDAP, there is this relatively simple php app that can provide this functionality:

https://github.com/matheusfillipe/ldap-signup

the special-auth branch is slightly modified to work with invite-codes.

I will probably test it more in the coming days and provide a working configuration for the LLDAP documentation.

Somewhat related is the awesome Canaille app: https://gitlab.com/yaal/canaille which allows managing LDAP users and groups with invites and also has an additional Oauth2 endpoint (similar to Keycloak, but much less complex). It also does not support self-registration yet, but can be a great companion to LLDAP never the less I think (I need to actually test it with LLDAP).

@poVoq commented on GitHub (Jan 25, 2023): While this would be still nice to have in LLDAP, there is this relatively simple php app that can provide this functionality: https://github.com/matheusfillipe/ldap-signup the `special-auth` branch is slightly modified to work with invite-codes. I will probably test it more in the coming days and provide a working configuration for the LLDAP documentation. Somewhat related is the awesome Canaille app: https://gitlab.com/yaal/canaille which allows managing LDAP users and groups with invites and also has an additional Oauth2 endpoint (similar to Keycloak, but much less complex). It also does not support self-registration yet, but can be a great companion to LLDAP never the less I think (I need to actually test it with LLDAP).

kerem commented

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

Author

Owner

@pixelrazor commented on GitHub (Mar 16, 2023):

Looking at maybe taking this up after the yew upgrade.

I'm imagining that we can use tokens nearly identically to password reset (if not using the same model/table) where that token is deleted when used and we generate a short lived cookie for that one endpoint (a new endpoint created for this).

This leaves the UI changes. It should only be visible to admin since that's the only group with write privilege. This could potentially be a new menu item in the navbar along 'users' and 'groups'? From there, it could be either or both of:

Just a button to generate a sharable link. big critical test indicating that you shouldn't open it or it will invalidate it for the user you send it to
A field where you type and email and have a button to send an email to that address containing the new link

2 feels a bit redundant to me - while we COULD prefill the email in the creation form, i think it should be kept open for users to use a different email than the one it was sent to.

I feel like there COULD be an argument for wanting the ability to make a link that also adds the new user to certain groups, but i don't think that's really the best idea, and the admin can easily add them after creation.

Then of course we'll need a new endpoint for the creation page. This could be pretty much the same as the current user creation page - there could ideally be a way we share that part of the frontend with some refactoring of that component

@pixelrazor commented on GitHub (Mar 16, 2023): Looking at maybe taking this up after the yew upgrade. I'm imagining that we can use tokens nearly identically to password reset (if not using the same model/table) where that token is deleted when used and we generate a short lived cookie for that one endpoint (a new endpoint created for this). This leaves the UI changes. It should only be visible to admin since that's the only group with write privilege. This could potentially be a new menu item in the navbar along 'users' and 'groups'? From there, it could be either or both of: 1. Just a button to generate a sharable link. big critical test indicating that you shouldn't open it or it will invalidate it for the user you send it to 2. A field where you type and email and have a button to send an email to that address containing the new link 2 feels a bit redundant to me - while we COULD prefill the email in the creation form, i think it should be kept open for users to use a different email than the one it was sent to. I feel like there COULD be an argument for wanting the ability to make a link that also adds the new user to certain groups, but i don't think that's really the best idea, and the admin can easily add them after creation. Then of course we'll need a new endpoint for the creation page. This could be pretty much the same as the current user creation page - there could ideally be a way we share that part of the frontend with some refactoring of that component

kerem commented

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

Author

Owner

@nitnelave commented on GitHub (Mar 16, 2023):

Sounds good! I agree with the overall approach. A couple of points:

The tokens could be invalidated only after the user actually sends to form to create the user. That way if the admin clicks on the link it doesn't invalidate it. I'd put the email (hashed maybe?) inside the token as well to further avoid brute-forcing (though I don't think that's going to be a problem if the token is 100 random characters).
The tokens could have a configurable expiry time (10 min, 2h, 2 days, 2 weeks, 2 months).
You probably already thought about it, but just making sure: We need a page for listing the active invitations, to which email they belong, when they expire, and a button to delete them. Similar to the user list.
I would enforce the email in the form: maybe that'll be used to only allow emails from a specific domain (think university students or small businesses). You can always write to the admin to get an invitation with a different email. Also if someone steals the link they can't completely hijack the user.
If SMTP is configured, send an email to the admin on successful user registration, and one to the user (saying that if it's not them, contact <admin_email>).
We might need to start by doing a bit more input validation, at least for the username. See https://github.com/nitnelave/lldap/issues/239 . A good starting place is only ASCII alphanum plus dash dot and underscore.
We could also think about email confirmation? Sending a link to the email that the user has to click to confirm that they created the account? Maybe later.

@nitnelave commented on GitHub (Mar 16, 2023): Sounds good! I agree with the overall approach. A couple of points: - The tokens could be invalidated only after the user actually sends to form to create the user. That way if the admin clicks on the link it doesn't invalidate it. I'd put the email (hashed maybe?) inside the token as well to further avoid brute-forcing (though I don't think that's going to be a problem if the token is 100 random characters). - The tokens could have a configurable expiry time (10 min, 2h, 2 days, 2 weeks, 2 months). - You probably already thought about it, but just making sure: We need a page for listing the active invitations, to which email they belong, when they expire, and a button to delete them. Similar to the user list. - I would enforce the email in the form: maybe that'll be used to only allow emails from a specific domain (think university students or small businesses). You can always write to the admin to get an invitation with a different email. Also if someone steals the link they can't completely hijack the user. - If SMTP is configured, send an email to the admin on successful user registration, _and one to the user_ (saying that if it's not them, contact <admin_email>). - We might need to start by doing a bit more input validation, at least for the username. See https://github.com/nitnelave/lldap/issues/239 . A good starting place is only ASCII alphanum plus dash dot and underscore. - We could also think about email confirmation? Sending a link to the email that the user has to click to confirm that they created the account? Maybe later.

kerem commented

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

Author

Owner

@nitnelave commented on GitHub (Mar 16, 2023):

Oh, and regarding adding the user to certain groups, that could be added later on by making that a property of the invitation: in the invitation list screen, the admin would have a way to add groups to the invitation, that will then be added to the user on account creation.

@nitnelave commented on GitHub (Mar 16, 2023): Oh, and regarding adding the user to certain groups, that could be added later on by making that a property of the invitation: in the invitation list screen, the admin would have a way to add groups to the invitation, that will then be added to the user on account creation.

kerem commented

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

Author

Owner

@pixelrazor commented on GitHub (Mar 16, 2023):

We could also think about email confirmation?

Would this end up being specific to this path, or should that also become part of the process when an admin creates a user?

re: adding to groups - i still think it'd be bbetter to have the admin control groups manually AFTER account creation instead of having it attached to the creation link. That being said i can't seem to form a solid argument so i'll sway to whatever way you prefer.

SSome of these requirements are enough to warrant a different model for these tokens since we've deviated a bit from the password reset tokens. I'll have to do enough investigating to ensure it can be done without (hopefully) breaking previouus versions.. IIRC isn't there some breaking db migration planned at SOME point in time TBD?

@pixelrazor commented on GitHub (Mar 16, 2023): > We could also think about email confirmation? Would this end up being specific to this path, or should that also become part of the process when an admin creates a user? re: adding to groups - i still think it'd be bbetter to have the admin control groups manually AFTER account creation instead of having it attached to the creation link. That being said i can't seem to form a solid argument so i'll sway to whatever way you prefer. SSome of these requirements are enough to warrant a different model for these tokens since we've deviated a bit from the password reset tokens. I'll have to do enough investigating to ensure it can be done without (hopefully) breaking previouus versions.. IIRC isn't there some breaking db migration planned at SOME point in time TBD?

kerem commented

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

Author

Owner

@nitnelave commented on GitHub (Mar 16, 2023):

Let's leave email confirmation out of the picture for now. It's not needed for now, and we can always come back to the question.

Same for adding to groups, as long as we have the email on user creation, the admin can add it manually after the creation.

The current tokens for the password reset are 100 random (ascii) characters, I wouldn't really call that a "model" :D
W.r.t. the DB, we have some DB migrations built into LLDAP that are run on startup to make sure the DB is up to date (see the sql_migrations.rs file). Adding a new table is not a breaking change.

@nitnelave commented on GitHub (Mar 16, 2023): Let's leave email confirmation out of the picture for now. It's not needed for now, and we can always come back to the question. Same for adding to groups, as long as we have the email on user creation, the admin can add it manually after the creation. The current tokens for the password reset are 100 random (ascii) characters, I wouldn't _really_ call that a "model" :D W.r.t. the DB, we have some DB migrations built into LLDAP that are run on startup to make sure the DB is up to date (see the sql_migrations.rs file). Adding a new table is not a breaking change.

kerem commented

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

Author

Owner

@nitnelave commented on GitHub (Mar 16, 2023):

We'll have to be careful and use transactions when checking for the token's validity, removing it and creating the user at the same time.

@nitnelave commented on GitHub (Mar 16, 2023): We'll have to be careful and use transactions when checking for the token's validity, removing it and creating the user at the same time.

kerem commented

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

Author

Owner

@nitnelave commented on GitHub (Mar 20, 2023):

I was thinking back on this feature, and compared to creating the account directly for the user, the only thing that changes is that the user is able to pick their username. That doesn't seem worth the extra complexity.

@nitnelave commented on GitHub (Mar 20, 2023): I was thinking back on this feature, and compared to creating the account directly for the user, the only thing that changes is that the user is able to pick their username. That doesn't seem worth the extra complexity.

kerem commented

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

Author

Owner

@poVoq commented on GitHub (Mar 20, 2023):

Its a completely different use-case. If you want to run a semi-public service you can't manually create accounts all the time. But anyway... there are ways to achieve this without having it built into LLDAP directly, so not a big deal.

@poVoq commented on GitHub (Mar 20, 2023): Its a completely different use-case. If you want to run a semi-public service you can't manually create accounts all the time. But anyway... there are ways to achieve this without having it built into LLDAP directly, so not a big deal.

kerem commented

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

Author

Owner

@pixelrazor commented on GitHub (Mar 20, 2023):

You'll be manually creating links and sending them out anyways, and have to deal with the security implications depending on how you distribute them.

@pixelrazor commented on GitHub (Mar 20, 2023): You'll be manually creating links and sending them out anyways, and have to deal with the security implications depending on how you distribute them.

kerem commented

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

Author

Owner

@poVoq commented on GitHub (Mar 20, 2023):

In my original feature request I was rather thinking about shared (time/number limited) invite codes, so that would not require manual intervention except for making these shared invite codes from time to time.

@poVoq commented on GitHub (Mar 20, 2023): In my original feature request I was rather thinking about shared (time/number limited) invite codes, so that would not require manual intervention except for making these shared invite codes from time to time.

kerem referenced this issue

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

[PR #153] [CLOSED] ldap: ignore UUID attributes #575

kerem referenced this issue

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

[PR #295] [MERGED] example_configs: add Nextcloud #663

Rows
Columns

[GH-ISSUE #287] Self registration with invite code? #107