# CakeDC Users: the CakePHP user system that ships the parts you would rewrite

> The CakeDC Users plugin bundles a full authentication stack into a CakePHP application, from email validation and password reset through social login, Webauthn, an account lockout policy and a captcha. It keeps authorisation in a separate package, and it maintains a parallel branch for every CakePHP generation still in use.

**CakeDC/users** — Users Plugin for CakePHP

- Repository: https://github.com/CakeDC/users
- Website: https://www.cakedc.com
- Stars: 522 · Forks: 289
- Language: PHP
- License: NOASSERTION
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/cakedc-users

## A user system that arrives with the parts usually left out

The Users plugin for CakePHP is described as a comprehensive, extensible solution for user management, authentication and authorization, and the design goal is stated plainly: to get you up and running with a full-featured user system in minutes while remaining flexible enough for complex, custom applications.

The feature list is what makes that claim concrete, and the grouping tells you what is bundled.

The user lifecycle covers registration, email validation, profile management and password reset. Authentication covers login and logout, a Remember Me option backed by a cookie, and a Magic Link for one-click login. Social login lists Facebook, Twitter, Instagram, Google, LinkedIn through OpenID Connect, Amazon and GitHub.

The security group is the densest, and each item is a separate mechanism rather than a setting. There is a one-time password for two-factor authentication, and Webauthn for two-factor authentication with a Yubico key or TouchID. There is an account lockout policy after failed attempts, a password strength meter, and reCaptcha v2 and v3 support.

That combination is the reason the plugin exists as a package rather than as a tutorial. A registration form with email validation, a password reset flow that actually sends a token, a lockout policy and a strength meter is a lot of code to write and a lot of code to get right, and the parts that are easy to get wrong are exactly the parts that matter for an authentication system.

On the authorisation side the plugin integrates role-based access control and superuser support, and it does so through a separate package, CakeDC/auth, rather than inlining the permission model. The extensibility list names what you can subclass: controllers, models, mailers and templates. And admin management is out-of-the-box CRUD for user management.

The plugin is written for CakePHP 5.0 and newer with PHP 8.1 and newer, the default branch is named 16.next-cake5, and the latest release is 16.0.4 from May 2026. The last push was on 2026-08-31. The licence is MIT, with the copyright held by Cake Development Corporation from 2010 to the present.

## Four commands, and the plugin load that has to come before the migration

The quick start is four steps, and the order matters because the migration cannot run before the plugin is loaded.

The install is a Composer require:

```bash
composer require cakedc/users
```

Then the plugin has to be loaded in the bootstrap method of the application class, in src/Application.php:

```php
public function bootstrap(): void
{
    parent::bootstrap();
    $this->addPlugin('CakeDC/Users');
}
```

That is the whole integration step, and the parent call matters as much as the plugin call. The plugin's own bootstrap needs to run first, and the addPlugin line is what registers it with the application so that its routes, middleware and configuration are in place.

Then the migrations:

```bash
bin/cake migrations migrate -p CakeDC/Users
```

The plugin name is passed with the plugin option, so the command targets only the plugin's own migrations rather than running everything the application has. That is the standard CakePHP convention for a plugin that ships its own schema, and it means an application with other plugins or its own migrations is not affected by running this one.

Finally, a superuser is created:

```bash
bin/cake users add_superuser
```

That step is what turns the plugin from a set of user tables into something you can log into and administer. The superuser concept is mentioned separately in the feature list, where the authorisation support is described as RBAC and superuser support via CakeDC/auth, so the two are linked: the superuser is the account that bypasses the role model, and the roles model everything else.

So the sequence is install, load, migrate, create an administrator. Four commands and one small edit to the application class, and after that the plugin's routes, templates, mailers and controllers are in place.

## Seven CakePHP lines, seven branches, and a deliberate naming scheme

The versions table is the first thing in the readme and it is more informative than a support matrix usually is, because it shows how the plugin is versioned against the framework.

CakePHP 5.3 and later maps to the 16.x branch at tag 16.0.0, marked Stable and Current. CakePHP 5.0 maps to 15.x at 15.1.3 and to 14.x at 14.3.4, both Stable. CakePHP 4.5 maps to 13.x at 13.0.1. CakePHP 4.3 maps to 11.x at 11.1.0. CakePHP 4.0 maps to 9.x at 9.0.5. And CakePHP 3.7 maps to 8.x at 8.5.1.

The naming is worth reading closely because it is not simply the framework version with a prefix. The branch names carry a next suffix and the framework generation: 16.next-cake5, 15.next-cake5, 14.next-cake5, 13.next-cake4, 11.next-cake4, 9.next and 8.next. So the leading number is the plugin's own major version and the suffix records which CakePHP generation the branch targets.

The gaps in the numbering are the other thing to notice. There is no 12.x, no 10.x and no 15-to-16 continuous run, and the table jumps from 13 to 11 and from 11 to 9. Those gaps are where the framework itself had breaking changes that forced a new plugin major, and they are the reason a plugin like this has to maintain parallel branches rather than one line of development.

The consequence for an adopter is that the branch you want is determined by your CakePHP version and not by anything else, and that the current branch is the one named in the default branch of the repository, 16.next-cake5. The tags in the table are the versions to pin, and the notes column distinguishes the current stable branch from the older ones that remain stable but are no longer the active line.

That is a maintenance commitment, and it is the kind of detail a plugin with a large install base has to make explicit, because an application stuck on an older framework needs to know that a supported branch exists and will keep receiving fixes.

## The repository layout, and the three static analysers in it

The top level of the repository shows a plugin built to the conventions of a framework plugin, and the tooling is more thorough than most.

There is a src/ directory for the plugin code, templates/ for the view templates, a config/ directory, resources/ for the plugin's assets, and a webroot/ directory for anything served directly. There is a Docs/ directory, which is where the documentation lives, and the readme points at Docs/Home.md for the full installation details, configuration options and tutorials, which means the readme is a summary and the Docs directory is the reference.

The static analysis setup is the most interesting part of the listing, because there are three separate tools each with its own configuration and its own baseline file. There is a phpstan.neon with a phpstan-baseline.neon beside it, and psalm.xml with a psalm-baseline.xml beside it, and a phpcs.xml for coding standards.

Three analysers with three baselines is unusual, and the reason is worth thinking about. A baseline is a list of known findings that are accepted for now rather than fixed, and it exists so that a new finding fails the build while the existing backlog does not. Having three means the plugin is checked with the three tools a PHP project is most likely to be checked with, and that each is allowed to accumulate a bounded backlog.

The practical effect for a contributor is that the baseline files are part of the contract. Fixing something does not remove it from the baseline automatically; the entry has to be deleted, which is a deliberate extra step that stops a fix from being silently un-baselined.

The rest of the listing is standard. There is a composer.json, a phpunit.xml.dist for the test configuration, a .semver file, a CHANGELOG.md, a CONTRIBUTING.md, a .gitattributes, a .gitignore and a .github/ directory for the workflows. The build and coverage badges point at a CI workflow named ci and at Codecov, so the test suite runs on every push and the coverage is reported.

The Packagist badges show the download count and the latest stable version, which is how a plugin like this communicates that it is a live dependency rather than an abandoned repository.

## What the plugin does not decide for you

There are two boundaries in the documentation that are worth being explicit about, because both are places where a plugin that promises everything ends up owning too much.

The first is authorisation. The RBAC and superuser support is provided by CakeDC/auth, a separate package, and the plugin integrates with it rather than implementing it. So if you want a different permission model, or no permission model, the Users plugin still does its job and you leave the role side alone. The cost of that separation is one more package to configure, and the benefit is that the authorisation model is not baked into the user records.

The second is the front end. The feature list names controllers, models, mailers and templates as the things you can extend, and it does not mention a JavaScript layer, a component library or a theme. So the plugin delivers the server side of user management with the pieces a CakePHP application expects, and the pages it renders are yours to restyle. For an application with its own design system, that is the right shape; for an application that wanted a ready-made admin interface, it is a limitation.

A third limitation is the framework generation itself. The plugin supports CakePHP 5.0 and newer, and the branch table shows that the older branches exist for the older frameworks but that the current line is 16.x. An application on CakePHP 4.x is on a stable branch that will not receive the features added to 16.x, so upgrading the application and upgrading the plugin are separate decisions with separate timings.

There is also a licensing point to check. The repository records a custom licence that GitHub could not classify, and the readme states that the project is licensed under MIT with redistributions of the source code required to retain the copyright notice. The LICENSE.txt file in the repository root is the authoritative text, and for a plugin that ships a superuser creation command and an account lockout policy, it is worth reading before you deploy it.

And the last limitation is the one every plugin has. It is a starting point, not a finished system. The description says it is designed to get you up and running in minutes, and the extensibility list is the other half of that promise, because what you build on top is yours to own.

## Conclusion

CakeDC Users suits a CakePHP application that needs a working authentication system this week rather than a bespoke one, since the parts most likely to be got wrong, email validation, tokenised password resets, lockout and Webauthn, are already written and tested. It does not suit you if you want a ready-made admin interface, because the plugin delivers the server side and its own templates, and it does not suit you if you need the authorisation model and the user model to be the same thing, since RBAC lives in a separate package. Before you deploy it, check the branch that matches your CakePHP version, because the current line is 16.x for CakePHP 5.3 and the older branches will not receive the new features, and read LICENSE.txt since the repository records a licence GitHub could not classify.

## FAQ

### How do I install the CakeDC Users plugin?

Run composer require cakedc/users, add the plugin in the bootstrap method of src/Application.php with the addPlugin call, then run bin/cake migrations migrate with the plugin option, and finally run bin/cake users add_superuser to create the first administrator account.

### What does the CakeDC Users plugin provide out of the box?

User lifecycle features including registration, email validation, profile management and password reset, authentication with login, a Remember Me cookie and Magic Link, social login for Facebook, Twitter, Instagram, Google, LinkedIn through OpenID Connect, Amazon and GitHub, two-factor authentication with one-time passwords and Webauthn, an account lockout policy, a password strength meter, reCaptcha v2 and v3, and out-of-the-box CRUD for user management.

### Which CakePHP version does the current CakeDC Users branch support?

The 16.x branch at tag 16.0.0 targets CakePHP 5.3 and later and is marked as the current stable branch, and the default branch of the repository is named 16.next-cake5. Older framework generations are served by parallel branches such as 15.x and 14.x for CakePHP 5.0, 13.x for CakePHP 4.5 and 11.x for CakePHP 4.3.

### Does the CakeDC Users plugin include role-based access control?

It integrates RBAC and superuser support through the separate CakeDC/auth package rather than implementing the permission model itself, so you can use a different authorisation approach without changing the user management side. The superuser account created by the add_superuser command bypasses the role model.

### What are the requirements for the CakeDC Users plugin?

CakePHP 5.0 or newer and PHP 8.1 or newer. The plugin is MIT licensed with the copyright held by Cake Development Corporation, and the full installation details, configuration options and tutorials are in the Docs directory of the repository.

## Sources

- [CakeDC/users on GitHub](https://github.com/CakeDC/users)
- [Issues](https://github.com/CakeDC/users/issues)
- [Project website](https://www.cakedc.com)
- [README](https://github.com/CakeDC/users/blob/16.next-cake5/README.md)
- [Releases](https://github.com/CakeDC/users/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cakedc-users