Allow users to self-register (or with invitation link)

[zamentur]

User registration

We need a system to allow people to register on a yunohost instance. It's needed for our small community server roadmap.

Features needed

3 registration modes

Invitation-link-only : The registration form is not publicly displayed in SSO. The admin can generate an invitation link and send it to the future user Admin-validation : The registration form is publicly displayed in SSO, but the user should be validated by admin manually Public : The registration form is publicly displayed in SSO, and user can access directly to the new created account (after email validation ?).

Email validation

If the instance has a valid email stack. The admin could activate the email validation feature. To create an account you need to click on a validation link. Email validation link expiration: 7 days ?

CAPTCHA validation

We need to avoid robot and spam.

Implementation guide

Create settings

Add a settings "user.registration.mode" with choices "invitation-link-only", "admin-validation", "public" . See this line to add the settings: https://github.com/YunoHost/yunohost/blob/dev/src/yunohost/settings.py#L56

Add a settings "user.registration.email_validation" Boolean (linked to Password reset feature)

Create API/CLI endpoints

Create API/CLI endpoints as a subcategories of user called subscription https://github.com/YunoHost/yunohost/blob/dev/data/actionsmap/yunohost.yml#L207 The associated code could be added in https://github.com/YunoHost/yunohost/blob/dev/src/yunohost/user.py#L498 . See group subcategories to find example how to write the code.

The data could be registered inside a YAML file in /etc/yunohost/subscriptions.yml

invitations:
  - code: 58TFr7566BB95Fg
    groups:
       - moderators
    quota: 10G
    nb_account: 10
    timestamp: 153152215441
  - code: C5HHbsfsdfg98
    groups:
       - moderators
    quota: 1G
    email: camille@gmail.com
    nb_account: 1
    timestamp: 153152215441
subscriptions:
  - login: john
    firstname: john
    lastname: doe
    email: john@example.com
    hash_pwd: $6$....
    email_rescue: john@gmail.com
    email_validation: validated
    groups:
       - moderators
    timestamp: 153152215441
  - login: jane
    firstname: jane
    lastname: doe
    email: jane@example.com
    hash_pwd: $6$....
    email_rescue: jane@gmail.com
    email_validation: PPo543ccxgdf9
    groups:
       - friends
    timestamp: 153152215441

Administrator actions

List all current subscriptions yunohost user subscription list | GET /yunohost/api/user/subscriptions

Return a list of all current waiting subscriptions/invitations with statuts like 'email validated: yes/no'

Accept / refuse a subscription yunohost user subscription accept LOGIN | POST /yunohost/api/user/subscriptions/:login/accept yunohost user subscription delete ID | DELETE /yunohost/api/user/subscriptions/:id

Create an ephemereal invitation code/link yunohost user subscription invite [--groups GROUP1 ...] [-q {SIZE|0}] [--send-to EMAIL] | POST /yunohost/api/user/subscriptions/invite

Future user actions

The user won't use this API endpoints directly. He/she will use SSO pages that will use those API endpoints.

Note those API could be separated from the ADMIN API. But if we do that it makes some works to create the API stuff. There is also the password reset feature with same issues.

Register GET /yunohost/api/user/subscriptions/captcha POST /yunohost/api/user/subscriptions public API endpoints with 'authenticate: false' like for yunohost tools postinstall or yunohost backup restore

POST DATA: USERNAME [--code INVITATION_CODE] [--groups GROUP1 ...] -f FIRSTNAME -l LASTNAME [-m MAIL] [-p PASSWORD] [-q {SIZE|0}?????]

Email validation yunohost user subscription resend LOGIN | POST /yunohost/api/user/subscriptions/:login/resend yunohost user subscription validate | POST /yunohost/api/user/subscriptions/:login/accept POST /yunohost/api/user/subscriptions/:id/validate/:validation_code

• cron to clean old validation/invitation links

SSOwat change

Change app_ssowatconf

Change app_ssowatconf to add user.registration.mode and user.registration.email_validation value in /etc/ssowat/conf.json https://github.com/YunoHost/yunohost/blob/dev/src/yunohost/app.py#L1345

Add register link

Adapt SSO login view to display registration URL or not based on registration mode value https://github.com/YunoHost/SSOwat/blob/dev/portal/login.html https://github.com/YunoHost/SSOwat/blob/6a7a9d668e5a23ad5d1c0a1630c7b2c2b82ef19c/helpers.lua#L530

Add a registration form page

Add a registration form page in SSO that use Ajax query to call API /yunohost/sso/registration/ -> POST /yunohost/api/user/subscriptions

/yunohost/sso/registration/?groups=XXXX Registration page for a specific group ?

/yunohost/sso/registration/?invitation_code=XXXXXX -> POST /yunohost/api/user/subscriptions?invitation_code=XXXXXX

/yunohost/sso/registration/?validation_code=XXXXXX -> POST /yunohost/api/user/subscriptions/validate?validation_code=XXXXXX

[SiM]

Great, I've been waiting for this feature for a long time :wink: The 3 registration mode and validation process seem perfect to me.

Wouldn't it be appropriate to also deal with #296 at the same time ? (because then the management of the registration form would be simpler and there would be no need to modify all this later once the #296 will be done... yeah I'm confident that it will be done one day soon :smile: :tm: )

My technical skills are limited on this topic but I'm available for testing

[eauchat]

Great plan indeed, seems like quite a bit of work ahead to do all this.

A few remarks/suggestions/questions:

1) On the registration form, it would be very valuable to be able to:

• have the possibility to easily display a custom text (for example a line on top where you can inform the subscribers of the criteria that will be used to accept/refuse their request)
• add a "comment" input to allow the subscriber to explain the reason of the subscription / send a little message to the server admin along with the subscription (like: "Hey Alice, I'm Falda, we talked the other day so I'm subscribing now...")

2) As @SiM mentioned, indeed it would be nice to address #296 at the same time, also to simplify the subscription form.

3) I was looking into this subscription thing today, trying to implement at least a basic password reset system for my server. It occurred to me that if it was possible to allow a specific API request to yunohost with a token, it could be quite easy to implement at least a simple password reset system. And in the long term, the token system would be useful for invitation links. This could be a good first brick in this big new construction. What do you think? The way I see it, the administrator could create a token to authorize anyone who has this token to execute a request/command to the API. For example anyone with this token could execute yunohost user update someUser -p $chosenPassword and only that very specific command/request to the API. I don't know if that's easy to implement or even possible, but @alexAubin remark in 1366 gave me some hope that maybe it could be.

[Agwebberley]

I will try to work on this issue.

[0cwa]

Maybe the php class here will help with scripting this? https://yunohost.org/de/admin_api#using-a-php-class

[artybdrlt]

Hello guys. ANy update on this feature?

[Che15ea]

I am interested in the feature as well!

[tituspijean]

Please keep the issue tracker clean and use the comment reactions if you only need to say "+1". 😉

[anubister]

3 registration modes

A 4th mode would be great : user-to-user invitations, allowing to populate automatically in one or more groups (of the inviting user).

-> this lower significantly the admin work, based on trust chain (which could be revoke), and allow users to work immediately with new people.

For instance this mechanism is successfully implemented on XMPP servers : https://blog.prosody.im/great-invitations/

[tituspijean]

Question, since I am writing the actionsmap for this. Currently yunohost user create command needs the following arguments: https://github.com/YunoHost/yunohost/blob/510e82fa22b8f0b52528dc4bd32b747d4543a5b3/share/actionsmap.yml#L62-L122

I will remove the deprecated arguments, but what about --domain and --loginShell?

The former might be something the admins want users to choose from the domain list. Or not? Then we should add that as a parameter of the invitation creation. The former I am more prone to discard and let default.

[Mike6547]

Hello, do you have a release date for this feature?

[alexAubin]

No, there is no release date for anything in YunoHost, everything happens because volunteer actually do the work and we release shit when it's deemed show-ready.

[Mike6547]

@alexAubin Thank you for your reply. I'm not asking for a precise date, just an estimate, as this feature could be a great help in my work.

[alexAubin]

Yes, we are aware that our free volunteer work can help people "with their work"

[Mike6547]

Yes, we are aware that our free volunteer work can help people "with their work"

The work I do is also voluntary for the website of an association, we are both volunteers but in different fields ^^

[alexAubin]

Cool then

[tituspijean]

Summary of the workflow as per discussed with @alexAubin during YunoCamp 2023: https://pad.pijean.ovh/code/#/2/code/view/UrtwBBC-onn17CYVbAVOZSWBLZsiElyeQx1ixBw+VP0/embed/present/

[Love-Ukraine]

Thank you for updating us on the progress of this feature. Do you have an estimated date for its integration?

[tituspijean]

No, cf. the multiple comments marked as useless off-topic here.

[Mike6547]

@tituspijean This is great news, I can't wait to use this feature!

[collector-ynh]

I'm very happy to know that you've finally decided to work on this major feature 👍

[alexAubin]

Initial exploration was done in https://github.com/YunoHost/yunohost/pull/1682 and https://github.com/YunoHost/yunohost/pull/1322 , to be reused when restarting work on this