Module 3 · 3.3

English

Nederlands English Deutsch

Users and roles

Module 3: Address, https and users · Reading time: 8 minutes

Learning objective: After this lesson you can divide roles and rights so that everyone can only do what they need.

Key concepts: role, capability (right), administrator, editor, author, contributor, subscriber, least privilege, one account per person, display name and username, application password, deleting a user and reassigning content

Roles and rights

Everyone who logs in to your WordPress website has a role. A role is a package of rights (in WordPress terms, capabilities): can this person write posts, edit other people's posts, install plugins, create users? WordPress has five default roles:

Role	What this role can do	Typical for
Administrator	Everything: themes, plugins, users, settings, all content	One or two people who manage the website technically
Editor	Create, edit, publish and delete all Posts and Pages, including those of others; manage Comments	Whoever keeps track of the content of the whole website
Author	Write their own Posts, upload images and publish	A regular writer
Contributor	Write their own Posts, but not publish and not upload	A guest writer whose pieces are reviewed
Subscriber	Only manage their own profile	Members who need to log in to read something

With a network of websites (multisite) the super admin also exists. Plugins sometimes add their own roles, such as Shop manager and Customer with WooCommerce, or a role for SEO management.

Note the difference between author and editor: an author can only touch their own Posts, an editor can touch everything. And an editor cannot install plugins or change settings. That's exactly the point.

The principle: as few rights as needed

Every account is a possible entry point for an intruder. A leaked password of a subscriber does little harm. A leaked password of an administrator gives full control: an intruder can upload a plugin with malicious code and gain access to all files and the database of your website.

That's why you give everyone the lowest role with which they can do their job:

The marketing colleague who writes blogs: author or editor, not administrator.
The intern who supplies news items: contributor; someone else publishes.
The website builder who comes to do something once: a temporary administrator account that you remove or downgrade afterwards.
Yourself: consider two accounts, an administrator for maintenance and an editor for day to day writing. Someone who views an infected page or clicks a fake link as administrator gives away more than an editor does.

A few rules that go with this:

One account per person. Never a shared account called "office" or "editorial". You won't know who did what, you can't revoke access from just one person, and the password gets passed around by email and notes.
Tidy up. If someone leaves, remove the account or set it to subscriber. Check every quarter which administrators exist (lesson 9.4). An unknown administrator is one of the clearest signs of a hack (lesson 7.5).
No accounts for apps that don't need them. If an integration (an app, another system) needs to work with WordPress, use an application password (below).

Username and display name

Every account has a username (which you log in with, cannot be changed) and a display name (what appears with your Posts, such as "Lisa Jones"). Choose the display name in the profile under "Display name publicly as".

Is your username secret? Not really. WordPress shows a derived name in several places: in the address of an author archive (/author/lisa/) and in the website's REST entry point (/wp-json/wp/v2/users), for anyone who has published a post. That name (the slug) is often identical to the username. An intruder then already has half of what they need. The real protection lies in a strong password and two-factor authentication (lesson 7.3), but a username that isn't the same as your public name helps a little. In lesson 7.3 you check what your website shows.

Application passwords

Since WordPress 5.6, every profile has Application Passwords at the bottom. With it you create a separate password for one integration, for example an app on your phone or a system that posts content via the REST API. Advantages:

You don't give away your real password.
You can revoke one integration without changing your own password.
An application password doesn't work to log in to the regular Dashboard.

The application password has the same rights as the account. So create it on an account with a suitably low role. If you don't use integrations, you don't need them.

Removing someone

If you delete a user who has written Posts, WordPress asks what should happen to that content:

Delete all content: all Posts and Pages by that person are removed. Almost never what you want.
Attribute all content to another user: the Posts remain, with the new user as author.

Almost always choose the second option. Want to keep the old author's name with the Posts? Then downgrade the account to subscriber and give it a new, long password, instead of deleting it.

In practice: what this looks like in a panel

In the WordPress Dashboard:

Users > All Users: at the top it shows how many accounts there are per role. Click Administrator to see only the administrators.
Users > Add New User: fill in username and email, and choose the role. Let WordPress send a password link instead of emailing a password yourself.
Profile: choose a display name, and manage application passwords at the bottom.

Summary

A role is a package of rights; WordPress has administrator, editor, author, contributor and subscriber.
Give everyone the lowest role with which they can do their job, and keep the number of administrators small.
One account per person, never shared; remove accounts when someone leaves.
Usernames are not secret; the real protection is a strong password and two-factor authentication.
When deleting, attribute the content to someone else; use application passwords for integrations.

Quiz

Exercise

Exercise D3.3: A role audit of your website. Open Users > All Users and make a list: per account the role, whether the person is still active and which role they actually need. Fill in how many administrators you had and how many remain after your tidy up round. Tick off: no shared accounts, no unknown administrators, departed people removed or downgraded (with content attributed), unused application passwords revoked. Explain in one sentence why you do or don't give yourself a separate editor account.

Exercise D3.3: A role audit of your website

You do this exercise yourself; no one checks it. Tick off what you've done and mark the exercise as done.

There are no more shared accounts
There are no unknown administrators
People who have left have been removed or downgraded, with their content reassigned
Unused application passwords have been revoked

Make a list per account: current role, still active, which role is actually needed?

How many administrators were there before and after your round?

Do you use a separate Editor account for yourself? Why, or why not?

Your ticks and notes only stay in this browser; we don't send them anywhere. If you're signed in, we only save in My courses that you've done the exercise.

Cookies at WebOké

Cookie settings

Necessary

Marketing