What is a user?

Quick question. What is a user?

No, I don’t mean the person. Hi Bob.

Rather in WordPress, a user isn’t just a person. It’s a collection of database records that live in your database in two tables. WP user and WP user meta. And most of what we’ll be talking about in this section of the course, user access, permissions, sessions, it all comes back to these two tables. So let’s take a quick look.

The WP users table contains the basics. username, email, a hash password, and some legacy bits like user URL, leftovers from the earlier days of WordPress.

Then there’s WP user meta. And this is where WordPress stores everything else about the user, roles, capabilities, preferences, and something particularly important, sessions. So, let’s talk about sessions for a second.

When a user logs in, they type in their password and hit submit. WordPress creates a session. That session proves that they’re logged in. It’s basically just a unique string, a hash tied to the user and is stored in the WP user meta table.

It also gets written to a cookie in their browser. So now every time they click around the site, their browser sends the cookie back. WordPress checks the session hash in the database and says, “Yep, you’re still logged in. Carry on.” You can have multiple sessions, one on your laptop, one on your phone, another in incognito.

Each one gets its own entry in the database and expiry. This is useful, but it also means that if someone steals that session cookie, say through malware or rogue extensions, then they could log in as you without knowing your username or password. We’ll cover how to mitigate some of that in a bit.

So, a WordPress user is more than a name and an email. It’s a combination of a database record in WP users, metadata in WP user meta and one or more active sessions. But why do we even have user accounts? A user might exist for all sorts of reason. It belongs to you or a member of your team.

It’s being created by a plugin, especially on e-commerce and membership sites. Uh it’s a customer logging into Woo Commerce to check their orders. It’s a contributor maybe writing blog posts but not publishing them. It’s your SEO agency who got admin access just to tweak something a couple of years ago. Or of course it’s your boss who should not have admin access but definitely does.

Now there’s another category that people tend to forget and that’s system accounts. These are user accounts that aren’t tied to an actual human. So uh no no to Bob but exists so that the automated systems bots and external services can connect to your site and WordPress has a special feature for helping to manage this called application passwords. Application passwords let you generate long random access keys that can be used on external tools like mobile apps, Zapier integrations, CRM, or pretty much anything that uses the REST API to authenticate as a particular user without the need for a real password.

You’ll find this under user profile screen in WordPress and it’s built into core. The thing is that if you’re using an application password with regular users or system accounts, they bypass things like 2FA and if misused, they can become a real security risk as any account can have an application password associated with it. When you’re looking at rotating passwords or you’ve had a breach, don’t forget to clean out the application passwords as well.

Before we worry about roles and capabilities, and we’re going to go into that in the next video, the foundation of user security is this. Know who your users are, why they have access, and whether they still need it, and if they don’t, then why are they still there? Once we have decided that someone should be a user, then we need to work out what sort of access they should have. And to help us manage this, we use roles and capabilities.