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
Unit 01 · The identity model

Members and backend users

The identity model Page 2 of 36 Updated

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.

Who this is for. Whoever sets up registration, imports accounts or takes over an existing site. Afterwards you can tell a member from a backend user at a glance, and prove that no member can reach the admin.

The five user types

Every user has a type, shown in the admin under Users › Users and stored as the code in brackets:

TypeSigns in toRecord permissions on the siteUnpublished records on the site
Frontend user (frontend)The website onlyApplyNever
Backend user (backend)The admin, limited to the permissions it is given, and the websiteApplyShown by default
Administrator (admin)The admin, with full rights, and the websiteSkippedShown by default
Super admin (superadmin)
Developer (developer)

A member is a frontend user. Every other type is a backend user, including the plain backend type, which is for staff with limited rights. Backend users see unpublished records on the site while the setting Show unpublished is on, which it is by default (Two gates).

A user also has a status: Active, Inactive or Disabled. Only an active user can sign in with a password; what an inactive member sees is covered with registration (The states a member can be in).

The rule: a member never reaches the admin

A frontend user must never be given access to the admin or to the content API, and the platform enforces both:

  • The admin, at /cdna-admin, checks every request. A frontend user is redirected to the admin's sign-in page with "You are not authorized to access this page". A backend user signed in on the website is also sent to that page: the admin accepts only a session started on its own sign-in page.
  • The API, at /cdna-api, refuses a frontend user on every route that does not say otherwise. The refusal looks like a missing route: a 404, {"result": "error", "message": "Page or record not found"}, or a 403 where the security setting Access Denied (Authenticated) is set to show it. The routes that admit members are the few built for visitors and members, such as GET /cdna-api/users/account for the member's own profile (A site member and a backend user).

What matters most is the type itself: a member given a backend type is no longer a member. Two places set it. The registration settings choose the type of everyone who registers, and offer Backend beside Frontend; keep it set to Frontend, so a visitor who registers never receives an admin login. And an import or integration that creates users sets the type it is told to.

Check the registration type

On every site with registration on, the registration setting Type must be Frontend. It is the default; check it anyway, because one change gives every new registrant the admin.

Checking an inherited site

  1. The registration type. In the Users settings, under Registration, Type is Frontend.
  2. The backend users. List every user whose type is not frontend, with a backend user's credential, and confirm each one is staff or an integration that should have the admin. Anyone you do not recognise is a member with the wrong type, or an old account to disable.
  3. From the outside. Signed out, /cdna-admin answers a redirect to the admin sign-in page and /cdna-api/pages/pages answers 401. Signed in as a test member, /cdna-admin sends you to the admin sign-in page.
Every user who is not a member 
GET /cdna-api/users/users?properties={id,type,status}&!type=frontend HTTP/1.1
Host: hub.coredna.com
Authorization: Bearer YOUR_ACCESS_TOKEN
Accept: application/json
Response 200 OK 
{
  "result": "success",
  "totalCount": 23,
  "data": [
    {"id": 8, "type": "admin", "status": "active"},
    …
  ]
}
Real response from this documentation site, shortened

The same request with type=frontend lists the members. The List users reference has the other filters.

Telling them apart in a template

_currentUser->isFrontendUser() is true for members and also for signed-out visitors; isBackendUser() is true for every other type; isAdmin() only for administrators, super admins and developers (The current user in a template). A template rarely needs them: what a visitor may see is decided by record permissions, which apply whatever the template does. Use them for presentation, such as an "Edit in admin" link shown only to backend users on an uncached page.

Go deeper
GuidePerson, user and author GuideAuthentication and authorisation FAQA frontend user can reach an admin URL ReferenceAccounts: API reference

Was this page helpful?

Your answer goes to the docs team.