Guide 07 · Developer docs

Members, accounts and gated content

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 Start reading
7
units
36
pages

Almost every site grows a member area eventually: an account page, saved addresses, order history, a members-only library, a course a member has paid for. The platform provides the parts: accounts, sign-in routes, providers and passkeys, a members-only URL space, and permissions on records. This guide is the map of how they fit together, and of the places where they behave differently from what their names suggest.

Who this guide is for

Theme developers building or restyling the account screens and the member area; content modellers deciding where member data and access rules live; integrations engineers creating members and sign-in links from other systems; and whoever signs a member site off before launch. It sits at level L2: it assumes you can build and deploy a template (Core dna for site builders), know Smarty or Twig (Template languages), and know how the platform caches pages (The caching model). Every template example is given in both engines.

The units, in order

  1. The identity model: person, user and author; members and backend users; groups and permissions; profile data; addresses. Read it first.
  2. Registration, sign-in and password recovery: every account route and its template, flow by flow.
  3. Authenticators, SSO and linked accounts: Google, Microsoft, Facebook and passkeys beside passwords.
  4. The my-account area and its routing convention: the built-in member screens and the catch-all that makes a template a members-only page.
  5. Members-only content: the published and permission gates, groups, entitlements, everywhere a record can be read, and files.
  6. Sessions, cookies and the cache: what a sign-in is, and how a member area lives with the page cache.
  7. Security for member sites: CSRF, rate limits and captcha, personal data, and the pre-launch checklist.

The shortest members-only page

Save this as templates/my-account/welcome.html, wrapped in your site's base template, and it is served at /my-account/welcome to anyone signed in. A signed-out visitor is sent to sign in and brought back. No page record, no route and no admin setting are involved (How the member area is routed).

Template code templates/my-account/welcome.html 
<h1>Welcome back, {$user->getPerson()->getFirstName()|escape}</h1>
<p><a href="{$_url->getPath('MyAccount', 'ordersListing')}">Your orders</a></p>
<h1>Welcome back, {{ user.getPerson().getFirstName()|e }}</h1>
<p><a href="{{ _url.getPath('MyAccount', 'ordersListing') }}">Your orders</a></p>

Seven things to know first

  1. A member and an administrator are the same records. Both are a person with a user; the user's type decides which is which (Members and backend users).
  2. A cached public page is served to members as the anonymous copy. Anything personal on a public page belongs in a fragment (Member pages and the page cache).
  3. Test as a signed-out visitor or a test member, not as yourself. Administrators skip both the published and the permission checks, so a restricted record answers 404 to everyone else, like a missing one (Two gates: published and permitted).
  4. A check in a template is not a gate. Only a restriction on the record keeps it out of listings, other templates, its JSON and the API (Listings, search and the API).
  5. Files are never gated. Anything in the file manager is served to whoever has its URL (Members-only files).
  6. Members can edit their own custom fields. Never decide access from a custom field value on the member's own person or user record (Profile data).
  7. The framework ships the sign-in template and few others. A missing account template shows "Template not found" with HTTP 200 on a Smarty site (Account routes and their templates).

Contents

7 units, in reading order.

The identity model

Who a member is in the data: the person, user and author records, the user types that separate members from backend users, groups and permissions, member profile data and the address book. Read it first, before modelling anything a member owns. 5 pages

Person, user and author A person is the human and their contact details, a user is the login, and an author is an editorial byline. Keeping the three apart from the first day avoids data that is expensive to move later. What each holds, how a member and an editor are made of them, and the current user in a template. Read more Members and backend users A user's type decides whether they are a member of the website or a backend user of the admin and the API. The five types, what each may do, the checks that keep a member out of the admin and the API, and how to confirm the separation on a site you have inherited. Read more Groups and permissions Groups are named sets of people; permissions say what a user, a group or everyone may do with a module, an entity type or one record. How the layers combine when a member asks for a record, why groups suit access by role, and why access per record belongs in the data model instead. Read more Profile data: custom fields or a related record Custom fields on the person cover most member profile data; a related record is right when the data repeats or has a life of its own. The rule for choosing, a worked case for each, the profile route that lets members edit their own details, and what that means for anything that grants access. Read more Addresses and the address book A person keeps an address book: any number of addresses, each with an address type and one marked primary. The model, the address types, the screens a member manages it with, rendering it in the member area, and how orders and checkouts use a saved address without linking to it. Read more

Registration, sign-in and password recovery

Every account flow a member uses, each as its route, its template and what that template receives: registration, email confirmation, sign-in and sign-out, forgotten and changed passwords, one-click sign-in links and remember-me. For the theme developer building or restyling the account screens. 9 pages

Account routes and their templates Every sign-in, registration and password route, with its URL, who may use it, the template it renders, what that template receives, and whether the framework ships one. The map to read before restyling any account screen, and the conventions every account form shares. Read more Registering a member Registration is off until switched on, and its settings decide the new account's type, status and groups. The settings, the form and its fields, adding a field, what happens on submit, and the case most sites handle badly: an email address that already has an account. Read more Email confirmation 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. Read more Signing in and out Password sign-in posts to /login, passes through the platform's authenticate step and lands the member where they were going. The form, its error states and what they must not reveal, where the member lands and how to keep the page they wanted, and what signing out does and does not end. Read more Forgotten and reset passwords A member who has forgotten their password asks for a link, the emailed link signs them in, and they choose a new password. Both halves, the link's lifetime and number of uses, the reset email and how to override it, and what a reset changes on the account. Read more Changing a password A signed-in member changes their password at /change-password by giving the current one. Why the current password is required, the form and its errors, the only password rule the platform has, and what happens to the member's other sessions. Read more One-click sign-in links A sign-in token is a link that signs one member in, a limited number of times, until it expires: the mechanism behind the password reset email, and available for campaign and re-engagement emails. How tokens are made, what the link does, when to use one, and the limits that keep it safe. Read more Remember me Remember-me lets a browser start a new session after the twelve-hour sign-in has run out, but only through a sign-in provider that can be refreshed. What is stored, how long it lives, the prompt members see, how it is revoked, and why a password-only site should leave it off. Read more Restyling the account screens The account screens are restyled by writing templates at the paths the routes render, as one set: the pages, the shared input partials, the messages and the emails. The full list of files, a field partial that handles its own errors, and what differs on a Twig site. Read more

Authenticators, SSO and linked accounts

Signing members in through Google, Microsoft, Facebook and passkeys, alongside or instead of a password: the model, the providers and their setup, the handshake and its errors, account matching, the linked-accounts screen, and the applications and sessions screens. For developers adding single sign-on to a member site. 7 pages

How the sign-in methods fit together A member can sign in with a password, a passkey, or an outside provider such as Google, Microsoft or Facebook, and one account can hold several. The model behind that, the methods that are checked locally, every provider the platform ships, which are safe to enable, and the policy questions to settle with the client. Read more Enabling a provider Switching on Google, Microsoft or Facebook sign-in: the client to create at the provider, the redirect URIs to register for every hostname and environment, the order to fill in the settings, and the sign-in buttons the template draws from what is enabled. Read more The sign-in handshake Signing in through a provider is four requests: login-with, the provider, the callback and authenticate, held together by a state value kept in the visitor's session. Each step, what it protects against, the errors a member can meet and the template that shows them, and how to tell the causes apart. Read more Matching a provider sign-in to a member A provider sign-in becomes a member account by the email address the provider reports. How an existing account is found and a new one made, the rule that stops a provider sign-in taking over an account that already has a way in, the attack it guards against, and what that means for connecting providers. Read more The linked-accounts screen The platform ships a member screen for listing, adding and removing sign-in methods, at /my-account/linked-accounts, but not its template. What the template receives, the routes its buttons call, the password form for a member who has none, and what each removal is refused for. Read more Passkeys Members can sign in with a passkey instead of a password: a credential kept by their device or password manager. The settings, the script that runs the browser side, enrolling at registration or from the account, signing in, the management screen, and the browser and domain constraints to plan for. Read more Authorised applications and signed-in sessions Two member screens the platform ships routes for: the applications a member has allowed to act for them, with a way to revoke each, and the member's signed-in sessions, with a way to end them. What each shows, the routes behind their buttons, and when a site needs them. Read more

The my-account area and its routing convention

How the members-only area under /my-account is routed: the screens the platform ships, the catch-all that turns a template into a page, and what to use when a page needs more. For theme developers building or restyling a member area. 4 pages

How the member area is routed Every URL under /my-account goes through one dispatcher: named routes for the built-in screens, then a catch-all that turns a template in templates/my-account/ into a members-only page. The mapping rule, what wins when names collide, and what the template receives. Read more The built-in member screens The screens the platform serves under /my-account: each one's route name, the template it renders and the variables it receives, which ones the framework ships a template for, and the account menu they share. Read more Adding a custom member page A members-only page needs a template and a deploy, nothing else: no page record, no route and no admin setting. The procedure, the file it takes, how to put it in the account menu, and what it does and does not protect. Read more When the catch-all is not enough The catch-all serves a GET with the signed-in user and nothing else. What to use instead when a member page has to take a form, carry an id in its path, follow other access rules or feed a script. Read more

Members-only content

Deciding what a visitor may see: the published and permission gates, restricting records to a group, entitlements for access per record, every other way a record can be read, and files. For anyone building or signing off a members-only section. 5 pages

Two gates: published and permitted A visitor sees a record only if it is published and they may read it. The two checks are independent, a refusal looks like a missing page, and administrators skip both. Where each check runs, what a refused visitor sees, and why a check in a template is not a gate. Read more Restricting a record to a group Pages, books, blog posts, FAQ, forms, products and custom entity records can each be made readable by one group only, and the platform then enforces it wherever the record is read. The settings, how a section inherits them, how to prove they apply, and when a group is the wrong tool. Read more Entitlements: access per record When access depends on what a member bought, booked or was approved for, model it as a record relating the member to the thing, created by the server and never by the member. A course enrolment as the worked example: the model, the check in a template, and why it scales where groups do not. Read more Listings, search and the API A record is read in more places than its own page: listings, other templates, search, the sitemap, its URL requested as JSON, and the API. What each of them shows of a gated record, and the check to run on a members-only section before launch. Read more Members-only files Every file in the file manager is served to anyone who has its URL, whatever page links to it. What that means for a members-only page, the settings that look like protection and are not, and the options for a file that must stay private. Read more

Sessions, cookies and the cache

How a member's sign-in works on the wire and how it meets the page cache: the cookies, their lifetimes and attributes, and the cached shell with member fragments. For theme and JavaScript developers, before a member site is built. 2 pages

Member pages and the page cache The page cache serves a stored copy to anyone who asks, signed in or not, and never stores what a signed-in visitor sees. What that does to a member site, how to measure it, and the cached shell with member fragments that keeps public pages fast. Read more Sign-in sessions and cookies A member's sign-in is one cookie holding an access token that lasts twelve hours; a second cookie carries the working session. Their attributes, what SameSite does to visitors arriving from other sites, cookie or bearer token for scripts, and what a member sees when either runs out mid-form. Read more

Security for member sites

The checks a member site needs before launch: CSRF on every signed-in form, rate limits and captcha on the forms that attract abuse, personal data kept out of logs, emails and the browser, and a one-screen checklist. For whoever signs a member site off. 4 pages

CSRF on member forms Every state-changing request from a signed-in member carries the session's CSRF token, or the platform refuses it with a 403. Where the token comes from on a member page, how forms and scripts send it, what the refusal looks like, and the one legitimate exception. Read more Rate limiting and captcha Sign-in, registration and password reset are the forms that attract automated abuse. Which routes to put limits in front of, thresholds to start from, slowing down rather than blocking, and where reCAPTCHA belongs, where it is theatre, and what it owes visitors who cannot complete it. Read more Personal data in logs, emails and the browser Well-meaning code causes most member-data incidents: a token in a URL, a whole record in a log line or a script tag, a password in an email. What must never appear, the redaction rules for logs, emails and jobs, and the rule for what a template sends to the browser. Read more The pre-launch checklist One screen to work through the week before a member site launches: accounts and sign-in, providers, gated content, caching, and security. Each item links to the page that explains it. Read more