Public User Registration

[rijkvanzanten]

Being able to register as a new user. Couple questions to discuss:

• How to show this in the app (resolved)
• How to interface with this through the API (regular POST /users ? Dedicated /users/register?)
• How this ties in with email validation for users
• How does this tie in with user invites
• Can public registration be permissions to "invite" yourself?

[benhaynes]

We're planning on adding this as a dedicated section in the Project Settings... and I think this would be our field layout... right after the "Public Pages" section:

User Registration (Divider, with person_add icon)
[Enable User Registration]    [Initial Role]
[Enforce Email Confirmation]  [Email Template]
[Reset Password URL]          [Redirection URL]

We can ignore the last 4 fields for MVP (Directus only), and/or add them for supporting white-labeled user management on the client project side.

[glowkeeper]

I can't see this in the admin app' in the latest v9 release - is this happening?

[rijkvanzanten]

This is an open feature request, so it's not a part of Directus (yet).

That being said, you can already configure your permissions for the public role to allows creating new users, there's just no UI for it in the Admin App

[glowkeeper]

Ah yes, I see - so I assign the Public role create permissions on the directus users collection. Once a user registers via my frontend (which posts the new user to /users), my admins then jump into the admin app' and assign the newly registered user a role with whatever scope they need. Nice! In fact, exactly what I need :)

I'm slightly concerned that my users table might get spammed by a malicious actor - granted, such users won't be able to do anything bad, but do you have any advice on what I might do to help prevent that?

[amiraiouaz]

This is not optimal because if you do not have admins to manage users' role, you cannot grant permissions to the public role for the field role. This will lead to a security issue as anyone could grant themself the admin role.

A solution could be (haven't tried it yet):

• Permissions for the public role to create new users (without access to the role field)
• Create an API Hook in order to assign the role you want when a new user is created (you can also use something like SendGrid to send an email as information)
• To prevent malicious actor, you can use reCAPTCHA in your front-end

That being said, having a Public User Registration in the Admin App:

• Register endpoint (with possibility to add one specific role for the registration)
• Email Confirmation before being able to log in
• Possibility to edit the email templates both for the Email Confirmation and Reset Password

Would be a very important feature for many use cases.

[jeremycoder]

Definitely agree!

[mehmetuken]

Adding close public registration options. Enabled or disabled.

[abdonrd]

I really like this feature request.
Allowing users to register on our websites/apps is a very common use case.

I imagine using this register endpoint directly on our websites/apps.

[rijkvanzanten]

And I want to avoid hardcoding this role ID. Since it would change depending on the database.

Ahh interesting; how would you configure the role used for public registration then? If it was a system thing, you'd have the same problem right?

Or are you suggesting Directus would ship with a "registered users" role out of the box that would be used for this purpose?

[abdonrd]

Or are you suggesting Directus would ship with a "registered users" role out of the box that would be used for this purpose?

Exactly!

[abdonrd]

And maybe we can use it as Dynamic Variables like $CURRENT_USER or so?

[rijkvanzanten]

In your use case, would there ever be the need to register users to different roles based on some other flags / properties? I could imagine you might want to sign people up to a different role if they come from a trusted organizational email or something along those lines 🤔

[abdonrd]

Yes, I suppose that could be a case.
But so far I have never seen myself in that use case.

[NilsBaumgartner1994]

I would like to see this feature too

[vietave]

Hi. Just want to confirm if this feature, or something like it, has been implemented? I've been going over the docs but don't see it anywhere. Thanks.

[rijkvanzanten]

Good point! In that case, you could look for the HTTP status. 204 indicates successful creation with empty body (no read access).

[manuelwehrli]

Interesting points here that lead me to some questions:

When there is an error, are there different codes or messages for different scenarios? For example it could fail because the email is already in use, the email has no valid syntax, the email is on the blacklist of before banned users, the password does not meet the security guidelines, etc. How can I tell the visitor more or less why it failed rather than just showing a general error message?

How can I enforce that an actual entry in the users table is only made after the email address was confirmed? A bad actor could use the email of somebody else and try to register, then the legitimate owner would receive an email out of nothing and will maybe just delete it. Later that user suddenly wants to register and there would still be the entry in the table, though in unconfirmed state. Without a special routine, this would result in an user/email already exists error and I would have to clean up such unconfirmed registrations regularly. Is this something the invite endpoint solves in a better way?

Where can I give the invite endpoint public access? Is the routine behind actually something that I could reimplement with a flow and so customize it even more, for example checking against a blacklist of common spam email domains and filtering requests with randomly generated spam addresses in the first place, and also defining a custom invitation/confirmation email template, etc?

Or (to avoid the bad actor scenario) do I have to make a custom endpoint, that just sends an email with a link including a token (no idea how to generate and temporarily persist that in directus) which then directly creates the user and so occupies the email address?

There is still the risk that a bad actor would abuse a public invite endpoint to spam random people over my server with confirmation emails they did not trigger themselves, potentially putting my service into a bad light. If directus offers public registration in the future, some integration of captcha verification would be wise.

I think I mentioned some points that would ask for a dedicated public registration endpoint rather than just exposing the create users endpoint, especially the bad actor scenarios. I appreciate your help how to (partially) solve this issues.

[emrahnazif]

When there is an error, are there different codes or messages for different scenarios? For example it could fail because the email is already in use

I don't know how many different errors can give the actual directus but as I remember, if the email address is already taken, it says email must be unique.

How can I enforce that an actual entry in the users table is only made after the email address was confirmed?

As I know directus doesn't manage this internally but I am sure can create your own logic here.
You can basically add a boolean type field (activated) to users table or even "status" to have more options. you can modify your user roles according to this. If the user is "activated" then they are allowed to do the stuff. If someone claims to be the owner of a email address, they can simply reset their password. If you want to delete any not "activated" emails after a period of time (lets say 24 hours), maybe you can automate this through the flows as well.

To avoid some bad actors, you can also use rate limiting maybe?

[macntech]

Why not just create an API user that can only handle this part of user creation (so revoke all permissions except User table creation and view role on the ID field only) and hard code the auth token of the API user in the source code of the app?

I tested this one and the response from API is like expected status 200 and return of User ID of the new created user.

[sooqwaifr]

How do we handle email verification? In case the user enters a wrong email?

[NilsBaumgartner1994]

I propose a flag: EMAIL_VERIFICATION Which when true will send a link which a user has to press or has a code to enter If false, the verification will be skipped. Beste Grüße, Nils Baumgartner

…

Am 13.08.2022 um 03:43 schrieb sooqwaifr ***@***.***>:  How do we handle email verification? In case the user enters a wrong email? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

[macntech]

I propose to add a flag VERIFIED in the user database and revert a verify link back to the users email. In that link add a token like /auth/verify?token. If user clicked on the link the VERIFY=true and user could login. Needs a link back with a check routine during login route if user has been verified.

[anlexN]

I think POST /users is for user registration.

auth0

GitHub

open API

[vanling]

@rijkvanzanten not quite the same as a user registration but with the user invitation you could do the same as with reset passwords. So you it would be possible to add a custom address as an argument.
This way people could start the 'public registration' by entering their email and will need to click the link that is sent via email. Invite flow is already there, might still be issues with the role ID

Form with email field > await directus.users.invites.send('user@example.com', 'application_role_id','example.com/user/verify'); > email with example.com/user/verify?token= > form with password field ..

Currently trying to find out which fields needs te be public for user invites to work

[vanling]

Again i was deep in the JS-SDK and found out later that custom url was already supported <3
https://docs.directus.io/reference/system/users.html#invite-a-new-user

edit: If the application role id could be 'hidden' here this would satisfy most applications with registration needs i guess. So maybe have a default role for 'public invites'

For now it's an easy workaround with serverside(app) api call or extension :)

[kadlinobit]

Maybe this will help someone looking for a proper user registration workaround (with email confirmation). I have utilized /users/ POST endpoint (as discussed in this thread) to create a new user with invited status.

1. First I filter the request data and delete role and status from the request (so default values will be used in every case).
2. After the user is created, I use action to generate jwt token and send it to the user email for verification.

const jwt = require('jsonwebtoken')
const { Url } = require('directus/utils/url')

module.exports = async function registerHook(
    { filter, action },
    { services, exceptions, env }
) {
    const { AuthenticationService, MailService } = services
    const { InvalidCredentialsException } = exceptions

    filter(
        'users.create',
        async (input, { collection }, { database, schema, accountability }) => {

            // Do not change the payload if request comes from app / admin
            if (!accountability || (accountability.admin && accountability.app))
                return

            delete input.status
            delete input.role
            return input
        }
    )

    action('users.create', async ({ payload }, { schema, accountability }) => {
        
        // Do not send activation email if user is created from app or by admin
        if (!accountability || (accountability.admin && accountability.app))
            return

       const mailService = new MailService({
            accountability,
            schema
        })

        const { email } = payload

        const tokenPayload = { email, scope: 'invite' }
        const token = jwt.sign(tokenPayload, env.SECRET, {
            expiresIn: '7d',
            issuer: 'directus'
        })
        const inviteURL = new Url(env.FRONTEND_URL).addPath('user-confirm')
        inviteURL.setQuery('token', token)

        await mailService.send({
            to: email,
            subject: 'Confirm your user account',
            template: {
                name: 'user-invitation',
                data: {
                    url: inviteURL.toString(),
                    email
                }
            }
        })
    })
}

For verification, I have created a simple new POST endpoint /users/activate/, that receives the token, checks it and activates the user account.

const jwt = require('jsonwebtoken')

module.exports = (router, { services, exceptions, database, env }) => {
    const { UsersService } = services
    const {
        InvalidPayloadException,
        ForbiddenException,
        ServiceUnavailableException
    } = exceptions

    router.post('/activate', async (req, res, next) => {
        try {
            const { token } = req.body

            const { email, scope } = jwt.verify(token, env.SECRET, {
                issuer: 'directus'
            })

            if (scope !== 'invite')
                return next(
                    new ForbiddenException(
                        `You are not allowed to perform this operation.`
                    )
                )

            // Find user in DB by email
            const user = await database
                .select('id', 'status')
                .from('directus_users')
                .where({ email })
                .first()

            // Check user status - must be "invited"
            if (user?.status !== 'invited') {
                return next(
                    new InvalidPayloadException(
                        `Email address ${email} hasn't been invited.`
                    )
                )
            }

            const usersService = new UsersService({ schema: req.schema })
            await usersService.updateOne(user.id, { status: 'active' })
            res.send('OK')
        } catch (error) {
            return next(new ServiceUnavailableException(error.message))
        }
    })
}

I've taken most of the logic from UsersService - functions inviteUser() and acceptInvite(), which means the workflow is similar to the default user invitations, except you can create an account with all the details you need in one step and then just let the user click the activation link.

[falmanna]

@Mellifico
check here
https://docs.directus.io/extensions/endpoints.html

[Mellifico]

@falmanna
Many thanks!

[Mellifico]

One question : do I have to put your two pieces of code into the index.js of my extension ? The doc is quite short and I'm a bit lost....

[damamire]

the const { Url } = require('directus/utils/url') is not working for me - does anybody know where to import this in newer releases?

[damamire]

did you manage to get a user registration working and if, how?

[NilsBaumgartner1994]

Would be nice to make a own extension/ npm package of this

[Dominic-Marcelino]

Will an e-mail validation be part of this?

I personally think this is one of the most important missing parts.
The validation could be implemented comparable to the requestPasswordReset function:

directus/api/src/services/users.ts

Lines 360 to 405 in 57b0234

	async requestPasswordReset(email: string, url: string | null, subject?: string | null): Promise<void> {
	if (url && isUrlAllowed(url, env.PASSWORD_RESET_URL_ALLOW_LIST) === false) {
	throw new InvalidPayloadException(`Url "${url}" can't be used to reset passwords.`);
	}
	const STALL_TIME = 500;
	const timeStart = performance.now();
	const user = await this.knex
	.select('status', 'password')
	.from('directus_users')
	.whereRaw('LOWER(??) = ?', ['email', email.toLowerCase()])
	.first();
	if (user?.status !== 'active') {
	await stall(STALL_TIME, timeStart);
	throw new ForbiddenException();
	}
	const mailService = new MailService({
	schema: this.schema,
	knex: this.knex,
	accountability: this.accountability,
	});
	const payload = { email, scope: 'password-reset', hash: getSimpleHash('' + user.password) };
	const token = jwt.sign(payload, env.SECRET as string, { expiresIn: '1d', issuer: 'directus' });
	const acceptURL = url
	? new Url(url).setQuery('token', token).toString()
	: new Url(env.PUBLIC_URL).addPath('admin', 'reset-password').setQuery('token', token);
	const subjectLine = subject ? subject : 'Password Reset Request';
	await mailService.send({
	to: email,
	subject: subjectLine,
	template: {
	name: 'password-reset',
	data: {
	url: acceptURL,
	email,
	},
	},
	});
	await stall(STALL_TIME, timeStart);
	}

Will probably start an integration with the beginning of the year.
Should we create it as a custom extension or are you interested in a pr to core?

[falmanna]

would be great to have a built-in signup endpoint that follows public singup best practices

[alcompstudio]

O, Im created similar theme, maybe somebody help me find a resolve? #16977

[tillsanders]

I'm curious – this has been in the short term section of directus' roadmap for a while now. Is it something we will see in the coming months? I'm really excited for this!

[Dominic-Marcelino]

Personally I see some points a bit different. Following my thoughts

• How to interface with this through the API (regular POST /users ? Dedicated /users/register?)
  I'd use the existing POST /user endpoint as this is semantically exactly what's done. The user-creation shouldn't care if an email validation is needed or not.
  Instead a new endpoint to re-send a verification mail would make sense.

• How this ties in with email validation for users
  There should be settings if:

  • validation-mails are sent automatically
  • non-validated users are able to login or not

  This would also make the verification a non-breaking change if the default stays as not-required.
  Optionally the settings could even be set on role-base.

• How does this tie in with user invites
  The same settings as above should be used by default.

In case a verification should be disabled for some users, an admin could always set the verification field to true / a verification timestamp.

[rijkvanzanten]

@Dominic-Marcelino To add on to that, I think the latter "non-validated users are able to login or not" can already be achieved by creating the user with status: active 🙂 The only real new thing here then would be to optionally send a verification email on user creation

[Dominic-Marcelino]

@rijkvanzanten even though it can be archived via status imho these are still two different things. A user status can be active or disabled to whatever reason whereas the validation is a specific reason that stays the activation is still in progress.

This would also allow to add a new middleware that checks the settings and the value can automatically be set after e-mail validation too. Changing the status instead can’t be a default behaviour after validation, as the status can be used for anything. Therewith people would still have to create a custom solution with flows or code 🤔

Another thing regarding to validation:
I think it should be tracked via timestamp (and not a boolean) as well as it should be reset on email change 🤔

[rijkvanzanten]

I think it should be tracked via timestamp (and not a boolean) as well as it should be reset on email change 🤔

Ah, so you're suggesting to have a "email validated on" field which is a timestamp?

[Dominic-Marcelino]

Ah, so you're suggesting to have a "email validated on" field which is a timestamp?

Correct! Sorry, should have mentioned this before…
With such a field it would easily be possible to block actions for non-validated users as well as validating one manually / skip the validation.
The timestamp helps to track stuff a bit better than a simple Boolean.

[NilsBaumgartner1994]

So this solutions seems for me better. It also is very similar to GitLab implementation?

[avimar]

Is there any way to display a form for the public / not logged in user?

I tried creating an intermediary table - "signup" with public write access.
Then a flow to copy that email, add the appropriate role, and status "invited" to the direct_users table, and then POST /auth/password/request with payload of {email}, but... it only shows you to login first, even when I go straight to the signup create page.

Is there some way to display that form without logging in?

[manuelwehrli]

As far as I tested, the password request endpoint is only for users with active status, not invited nor any other. For invited users, you have to use POST /users/invite/accept to set the first password and activate the account which works only with the jwt that directus creates on the /users/invite/ endponit. If you set the status to active in your custom flow, the password can be (re)set through /auth/password/request. Remind that the way you described, there is no check if a user uses his own email address or the one of somebody else, as the default invitation endpoint does. The frontend effects you described might result from these circumstances, directus studio is just programmed that way, not much you can do about it without modifying its source code.

[rijkvanzanten]

Heya! Thanks for opening this feature request!

This feature request has received over 15 votes from the community. This means we'll move this feature request to the Under Review state!

The Core team will schedule a meeting to review this request as soon as possible. The discussion will then be approved or denied. You may or may not be invited to join this meeting with the core team.

For more information, see our Feature Request Process.

[cdwmhcc]

Great! I love the directus team!

[antontranelis]

The Core team will schedule a meeting to review this request as soon as possible.

How was that meeting going?

[w0kyj]

How to determine role with public registration?

• email domain, default role no permissions, ...
• create invite link endpoint (role associated with the endpoint)
  • public page option

[cdwmhcc]

There should be an option to configure the user group to which the newly registered user belongs.

[Pachat]

or to have an M2O field with filtered roles to let him choose

[cereschen]

settings => access control => Public => system collection => directus_user => create => use custom => field permissions(forbid role field) => field presets( set {role : "your system normal role"} )

then enjoy sign up

[Pachat]

@cereschen OK. But then what is the URL to register? users/+ is forbidden and /admin/users/+ brings back to the login form.

[cereschen]

还行。但是，要注册的 URL 是什么？ 是被禁止的，并带回登录表单。users/+``/admin/users/+

/users
method POST

Now visitors have permission to this

[joselcvarela]

@rijkvanzanten looks like this was released on version 10.11.0.
More specifically on this PR: #22125

Can it be marked as resolved? 🤔