Building a member area on Core dna: who a member is in the data, the sign-in flows and their templates, single sign-on and passkeys, the my-account routing convention, members-only content, sessions and the page cache, and the security checks to run before launch.
L2
Unit 02 · Registration, sign-in and password recovery
Email confirmation
Registration, sign-in and password recoveryPage 8 of 36Updated
The states a member account can be in, what each allows, and how to confirm an address without leaving a new member at a dead end.
Who this is for. Whoever is asked to "make members confirm their email address". Afterwards you can give the client a confirmation step that never locks a member out.
The states a member can be in
A user's status is Active, Inactive or Disabled. For a member:
Active
Inactive
Disabled
Signed in straight after registering
Yes
Yes
Signs in with a password
Yes
No: "The user account is inactive - please ensure you have verified your email address."
Receives a password reset email
Yes
No, and the form says the same as for any address
Signs in with a link from an email
Yes
No: "Could not login using token: The token could not be found"
A member registered as Inactive can sign in once, at registration, but not again until an administrator changes their status; the forgotten-password form answers every address alike, so it sends nothing to an inactive account either.
Confirming an address without a dead end
Separate the two questions the client is asking: may this person sign in, and have they proved the address is theirs. Let the first be yes at once, and record the second as a group:
Register members as Active. They can sign in, reset a forgotten password and reach their account from the start.
Send the confirmation from a job on the user's create event, with a link to an endpoint of your own: a synchronous job endpoint that checks the link's signature and adds the person to the group (Securing it). The link proves the address; the group records it.
Tell an unconfirmed member what to do. On their account page, where the template can test the group, show "Check your inbox to confirm your address" and a way to send the email again, instead of a page they cannot open.
An unconfirmed member can then still sign in, change their details and recover their password; only the confirmed-only content waits.
When the client wants to approve members by hand
Setting registration's Status to Inactive is an approval workflow: an administrator reviews each new account and sets it Active. If the client wants that, the site must say so at the moment of registering ("Your account will be ready once we have approved it; we will email you"), someone must own the review queue, and the approval email must come from a job on the user's update. Without all three, Inactive is the dead end described above. An approval queue is often better kept as a group too, as above, so that unapproved members can still sign in and see their own account.