[Bug] — createUser method and email confirmations

[kiya-abdulahi]

Bug report

Describe the bug

Using the auth.api.createUser when email confirmations are disabled does not automatically confirm emails.

For instance, if you disable email confirmations and create a users via auth.api.createUser, the auth.users table will show the email_confirmed_at column as null and the supabase ui will show Waiting for verification..:

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

1. Disable email confirmations
2. Create a user via auth.api.createUser
3. View the auth.users table
4. Take a look at the email_confirmed_at column which will be null
5. Take a look at the supabase ui that shows users and you'll see the Last Sign In column show Waiting for verification..

Expected behavior

The expected behavior when creating a user while having email confirmations disabled is that the email_confirmed_at column on the auth.users table will be set to the time the user signed up and the supabase ui that shows users will have Last Sign In set to the time the user signed up.

This is how the behavior is when creating a user via auth.signUp

System information

• OS: macOS
• Version of supabase-js: [1.28.2]
• Version of Node.js: [14.18.0]

Additional context

I also noticed that if you have email confirmations enabled and a user is created via auth.api.createUser, no email confirmation is sent.

[kiya-abdulahi]

So i did a bit of investigating and here's what I was able to come up with. When using the auth.api.createUser, it calls the gotrue api, specifically the admin/users POST endpoint.

This in turn calls the [adminUserCreate(https://github.com/supabase/gotrue/blob/master/api/admin.go#L176) method which does a number of things. What's important in regards to this issue is that it:

• grabs the params here
• grabs the config here

Now after the new user is written to the table, there are a number of checks. One of which is:

if params.EmailConfirm {
	if terr := user.Confirm(tx); terr != nil {
		return terr
	}
}

I beleive this is where the issue exists. params.EmailConfirm will always be null. When we grab the params mentioned above, what's happening is that we decode the request body. But the request body only allows UserAttributes defined as such:

export interface UserAttributes {
  /**
   * The user's email.
   */
  email?: string
  /**
   * The user's password.
   */
  password?: string
  /**
   * An email change token.
   */
  email_change_token?: string

  /**
   * A custom data object. Can be any JSON.
   */
  data?: object
}

One solution is to add a check against the config we grab if AutoConfirm is enabled. This is reflective of the behavior of the auth.signUp API which ultimately calls the signup POST endpoint on the gotrue server.

After a user is created with the signup endpoint, there are checks against the config on to whether or not the user should be confirmed. This can be seen here:

if params.Provider == "email" && !user.IsConfirmed() {
	if config.Mailer.Autoconfirm {
		if terr = models.NewAuditLogEntry(tx, instanceID, user, models.UserSignedUpAction, nil); terr != nil {
			return terr
		}
		if terr = triggerEventHooks(ctx, tx, SignupEvent, user, instanceID, config); terr != nil {
			return terr
		}
		if terr = user.Confirm(tx); terr != nil {
			return internalServerError("Database error updating user").WithInternalError(terr)
		}
        ....
}

If this appears to be the right path, I'm happy to stab at creating a PR!

[ngoctranfire]

Want to also say that this is an issue for me too and I think a PR to fix this would be a great idea!

[rphlmr]

Hello, it seems to be fixed ;) : supabase/supabase#4268