Easy Auth Bundle Laravel Package

Getting Started

First, the framework mismatch. mikemeier/easy-auth-bundle is a Symfony bundle (the Bundle suffix and the mikemeier namespace are the giveaways), not a Laravel package. There is no service provider, no config/easy-auth.php, and nothing for composer require in a Laravel app to auto-discover. If you are working in Laravel, the realistic "first step" is to not install it and instead treat it as a design reference for building an Auth guard or a small authentication package of your own.

If you are actually in a legacy Symfony 2.x/3.x codebase and are evaluating this bundle, the minimal path is:

1. Confirm it will even install. The last release is from January 2014, which predates Symfony 3 and modern PHP 7/8. Open composer.json in the repo first and read the require block — specifically the symfony/symfony (or symfony/framework-bundle, symfony/security-bundle) constraint and the php constraint. If those cap you at Symfony 2.x and PHP 5.x, you have your answer before writing a line of code.
2. Read the README end to end. With 0 stars, 0 dependents, and a decade-old release, the README is the only specification. There is no community Q&A, no Stack Overflow corpus, no third-party blog posts. Treat every documented behaviour as unverified until you test it.
3. Find the bundle's DI extension. Open DependencyInjection/<Name>Extension.php and DependencyInjection/Configuration.php. The extension's alias is the root key for your config.yml; Configuration.php is the authoritative list of every option the bundle accepts. Do this before guessing at YAML — with no docs, the Configuration tree is your config reference.
4. Register the bundle in app/AppKernel.php (new MikeMeier\EasyAuthBundle\EasyAuthBundle()) — adjust the namespace to whatever the actual composer.json PSR-4 mapping says.
5. First use case: wire it into the security.yml firewall for a single, non-critical login route, and verify the happy path (valid credentials → authenticated token) and one failure path (bad password → rejected) in a throwaway environment.

If step 1 fails, stop. Do not vendor-patch a 2014 auth bundle to run on a current stack; authentication is the worst possible place to carry unmaintained, unaudited code.

Implementation Patterns

Given the package's age and obscurity, the honest "patterns" section is mostly about containment — how to use it without letting it become load-bearing.

Isolate it behind a single firewall entry (Symfony). Configure the bundle to own exactly one firewall and one route prefix, e.g. an admin login at /admin/login. Keep every other firewall on Symfony's native form_login or your own listener. This means a future rip-out is a security.yml edit rather than a rewrite.

Wrap the decision in your own service. Whatever the bundle exposes — an authentication provider, a listener, a user provider, or a controller — inject it into a thin AuthAdapter service of your own and call that from controllers. Your application code should never type-hint a class from this namespace directly. That adapter is where you add logging, rate limiting, and the "is this user still allowed" checks the bundle almost certainly does not do.

Pin the version hard. Since there has been one release and no activity since 2014, use an exact constraint ("mikemeier/easy-auth-bundle": "1.0.0" — check the real tag) rather than ^. Also commit composer.lock. A silent transitive update under an unmaintained bundle is a classic way to break login on a Tuesday.

Treat credentials and storage as yours, not theirs. If the bundle ships a user provider that reads from a specific table shape, keep that mapping in your own entity/repository and let the bundle consume it. Never let an abandoned package define your schema.

For Laravel developers — the port pattern. The concept this kind of bundle usually encodes (a pluggable credential checker + a session token) maps cleanly onto a custom guard:

// app/Auth/EasyGuard.php — a Laravel-native reimplementation, not the bundle
class EasyGuard implements Guard
{
    public function __construct(
        protected UserProvider $provider,
        protected Request $request,
    ) {}

    public function check() { return ! is_null($this->user()); }

    public function user()
    {
        $id = $this->request->session()->get('easy_auth_id');
        return $id ? $this->provider->retrieveById($id) : null;
    }

    // attempt(), validate(), login(), logout() ...
}

Register it with Auth::extend('easy', fn ($app, $name, $config) => ...) in a service provider. This gives you the bundle's ergonomics with Laravel's session, CSRF, hashing, and events — and it will still work next year.

Integration testing is not optional. Write one feature test per path (success, bad password, unknown user, disabled user, session fixation on login) against the bundle's own code path. You are the only person who will ever have tested this thing.

Gotchas and Tips

• The framework mismatch is the headline gotcha. Anything you read about "installing" this in Laravel will be wrong. There is no EasyAuthServiceProvider, no facade, no auth.php driver.
• Zero dependents means zero institutional memory. No GitHub issues with answers, no forks carrying patches, no tutorials. Every problem you hit is yours alone. Budget accordingly.
• 2014-era Symfony assumptions. Expect getRequest()-on-container patterns, mcrypt usage, non-::class string service references, and possibly symfony/symfony as a single requirement. Each of these breaks on modern Symfony in a different, unhelpful way.
• Check for mcrypt and password hashing. PHP 7.2 removed mcrypt; PHP 5.5+ added password_hash. If the bundle hashes or encrypts credentials with mcrypt, md5, or sha1, do not use it — that is a security defect, not a porting inconvenience.
• Config quirks hide in Configuration.php. If a YAML key appears ignored, it is probably misspelled against the configuration tree, or the bundle silently defaults it. The Configuration class is the only truth; there is no schema doc to cross-check.
• Dependency injection debugging (Symfony). If the bundle's services fail to wire, use php app/console container:debug <service> (or bin/console debug:container on newer versions) to see what actually got registered and with which arguments.
• Logging is your substitute for docs. Wrap every call into the bundle in a service that logs inputs and outcomes. When something breaks at 2am, those logs are the only diagnostic surface you'll have.
• Extension points to inspect before forking. Look for event dispatcher usage (kernel.security.* listeners), an authentication provider interface, and a user provider interface. The provider interface is usually the right seam for adding MFA, lockout, or an external identity store — cleaner than subclassing anything.
• Verdict for day-to-day use: none. A 0-star, 0-dependent, single-2014-release authentication bundle should not be a day-to-day dependency in any codebase you care about. Read it for ideas, reimplement the 200 lines you actually need on top of framework-native auth, and move on.