Security User Laravel Package

Getting Started

Treat this as a source-reading exercise, not a docs-reading one. With 0 stars, 0 dependents, and a 0 score, there is no community surface area: no issues to learn from, no blog posts, no upgrade guides. Budget 20 minutes to read the repo before you composer require anything.

1. Read composer.json first. Confirm "type": "symfony-bundle" and check the require block for symfony/framework-bundle and symfony/security-bundle version constraints. The package name and "Bundle for easy integrations security user" phrasing suggest an older Symfony codebase; the constraints tell you immediately whether it can run on your Symfony version at all. If it pins ^3.4 or ^4.0 and you're on 6/7, stop here.
2. Install into a scratch branch. composer require ozznest/security-user (there's no --dev reason to install it). Commit the lockfile change so you can revert cleanly.
3. Register the bundle. Add it to config/bundles.php (or app/AppKernel.php on legacy apps). Without this, nothing works and the failure mode is a silent "service not found," not an error about the bundle.
4. Locate the three things that matter: the DependencyInjection/ extension (service ids and parameters), Resources/config/services.* (what's actually wired), and any Entity/, Model/, or Trait/ directory (your base user class).
5. First use case: make your own User entity extend the bundle's base class (or use its trait, if it ships one), map it to your users table, and point security.yaml at it:

providers:
    app_users:
        entity:
            class: App\Entity\User
            property: username

Verify with bin/console debug:container | grep -i security_user, then a real login request. A green debug:container with a red login usually means an encoder mismatch, not a wiring problem.

Implementation Patterns

Subclass, don't fork. The intended integration is almost certainly class User extends Ozznest\...\SecurityUser {} with your app owning the Doctrine mapping. Keep your fields in App\Entity\User and let the base supply getUsername(), getRoles(), getPassword(), eraseCredentials(). If the bundle ships a trait instead, prefer it — traits compose with entities you already have and survive base-class changes better.

Password encoding. These micro-bundles commonly ship a default encoder (bcrypt being the usual era-appropriate choice) either in the extension defaults or a compiler pass. Do not let it win by accident: declare your password_hashers / encoders block explicitly in security.yaml and confirm bin/console debug:config security shows yours, not the bundle's.

Roles. Expect a roles array/JSON column with a ROLE_USER fallback in getRoles(). If your app uses DB-backed roles or a hierarchy, override getRoles() in your subclass rather than fighting the base. If getRoles() returns the serialized column directly, watch for the classic Symfony pitfall where roles are returned as a nested array and never flattened.

Schema workflow. Run bin/console doctrine:migrations:diff and read the generated SQL before running it. If the bundle registers its own Doctrine mapping (Resources/config/doctrine/*.orm.xml), you'll get a second table or duplicate columns — trim those out of the migration rather than hand-writing mappings.

Override via container aliasing, not config. A bundle this small has no extension points worth the name. The realistic customization path is:

services:
    Ozznest\SecurityUser\Security\UserProvider:
        alias: App\Security\AppUserProvider

That keeps the bundle's wiring intact while letting you own the behavior. It's also the least painful thing to rip out later.

Test the boot, not the features. A single kernel test that boots the container and asserts the provider resolves catches ~90% of the ways this package breaks on upgrade — renamed service ids, dropped tags, changed signatures.

Gotchas and Tips

The UserInterface signature break is the big one. Symfony 5.3+ requires getUserIdentifier(); older bundles only define getUsername(). If the package predates that split, you'll get a fatal abstract method not implemented error the moment authentication runs. The fix is to add getUserIdentifier() in your subclass — but do it before you write any other code, because it affects every authenticator you use after.

Session serialization will bite you. Symfony's user object requirements around Serializable / __serialize / eraseCredentials() changed multiple times. Test that a login survives a second request — refresh the page after authenticating. A user that authenticates then immediately deauthenticates is this bug, not a session config bug.

"Invalid credentials" with no exception is an encoder mismatch, not a form bug. Debug order: password_hashers config → the hash prefix stored in the DB row → the encoder the bundle registered. Almost always the first.

Service-not-found means the bundle isn't in config/bundles.php. There's no error message pointing at this. Check it before you start grepping the container.

No PasswordUpgraderInterface support, probably. If the provider doesn't implement it, migrate_from / automatic rehashing silently does nothing. Your users with legacy hashes stay on legacy hashes forever. Verify with bin/console debug:container --tag=security.user_provider and inspect the class.

The honest recommendation: this is 100–200 lines of UserInterface boilerplate. Copy it into App\Entity\User and drop the dependency. With zero dependents there is no ecosystem keeping it compatible with future Symfony releases, and you will be the one writing the getUserIdentifier() patch anyway. The only reason to keep it is if it encapsulates something non-obvious — and after reading the source, you'll know whether it does.