Composite Password Authentication Bundle Laravel Package

Getting Started

This bundle is a legacy Symfony package (last tagged 2016-10-31, zero dependents) targeting the Symfony 2.x / early 3.x Security component. Before you composer require it, check your Symfony version — if you're on Symfony 4+, the framework's AuthenticationProviderInterface it relies on has been removed, and this bundle will not boot without a compatibility shim or a rewrite.

Minimal steps to evaluate it:

1. Skim the README and Resources/config/ first. This is the only reliable "docs" — there is no maintained documentation site, and the last commit is ~8 years old.
2. Read DependencyInjection/CompositePasswordAuthenticationExtension.php and Configuration.php to learn the config keys before you touch security.yml. The bundle exposes a small set of options (typically user class, password component fields, and provider service id).
3. Install against a pinned Symfony constraint in a sandbox project:

   composer require phpmentors/composite-password-authentication-bundle
   

   Expect to add an inline "symfony/symfony": "~2.8|~3.0" constraint so Composer doesn't resolve a modern framework that lacks the required interfaces.
4. First real use case: a login form where a user must supply more than one password component (e.g. a login password plus a second "transaction" or "confirmation" password), and the authentication provider verifies the combination server-side before granting a token.

Start with a single custom UserProvider and one firewall; don't try to retrofit it onto an existing form-login firewall until you can authenticate one fixture user.

Implementation Patterns

Firewall wiring. The intended pattern is to register the bundle's authentication provider as the firewall's sole provider (or chained after a pre-auth). In security.yml you'll typically see a custom provider: key pointing at the composite provider service, replacing form_login's default DaoAuthenticationProvider.

# security.yml (Symfony 2.x/3.x syntax)
security:
    providers:
        composite:
            id: phpmentors.composite_password_authentication.provider
    firewalls:
        main:
            pattern: ^/
            composite_password: ~   # factory defined by the bundle
            form_login:
                check_path: /login_check

Custom user provider. Because composite passwords aren't stored as a single password column, you nearly always subclass the bundle's abstract user provider or implement the security UserProviderInterface yourself and delegate the component comparison to the bundle. Keep the user lookup in your own repository (Doctrine EntityRepository::findOneByUsername) and let the bundle do only the credential comparison.

Authenticator/provider strategy. The bundle is built around the pre-Symfony-4 AuthenticationProviderInterface::authenticate(TokenInterface) contract. Expect to work with:

• UsernamePasswordToken (or a custom token carrying the extra password component)
• AuthenticationException subclasses for per-component failure reasons

If you need per-component failure messages, throw distinct exceptions per missing/invalid component rather than a generic BadCredentialsException — this is the main reason to use the bundle at all.

Testing pattern. Unit-test your subclassed provider in isolation by mocking the user provider and feeding hand-built tokens. Do not try to spin up a full kernel for every case — the security component's bootstrap is slow and brittle on these old versions.

Integration tip. If you only need one extra credential field, you probably don't need this bundle at all — Symfony's form login with a custom UserChecker plus a check in your controller is simpler and future-proof. Reach for composite password only when the combination logic itself (ordering, partial-match, hashing each component) is the domain requirement.

Gotchas and Tips

• Symfony version trap. The bundle predates Symfony's PasswordHasher rename (4.3+) and the AuthenticatorInterface overhaul (5.3+). On anything modern, composer require "phpmentors/composite-password-authentication-bundle" will either install against a framework it can't run on, or fail to resolve. Fork and adapt rather than depend on the upstream.
• Abandonment = security risk. Zero stars, zero dependents, no releases since 2016. Treat any code path touching credential comparison as unmaintained and audit it before production. The password hashing strategy used here is likely MessageDigestPasswordEncoder era — do not assume it's compatible with current bcrypt/argon2 best practice.
• Config quirk: bundle configs from this era were merged via Configuration::getConfigTreeBuilder() with ->children()->scalarNode(...); unknown keys silently fail rather than erroring on older Symfony. If a config option seems ignored, dump the container (debug:container --parameter=… or config:debug) to confirm it was actually registered.
• Debugging: enable security.access_control logging and set the security channel to debug in monolog. Because authentication providers throw during the firewall listener, exceptions get wrapped — catch and log inside authenticate() to see the real cause.
• Extension point: most real customization happens by overriding the provider and user provider services in services.yml with parent: phpmentors.composite_password_authentication.provider. That's the cleanest seam; avoid editing vendor code.
• Token serialization: if you add fields to the token, implement __serialize()/serialize() correctly or sessions will silently lose the extra credential on the next request — a classic "works once then logs out" symptom in this era of Symfony.
• Migration advice: if you're greenfield, skip this bundle. If you're maintaining a legacy app, isolate it behind your own CompositePasswordChecker interface so you can swap the implementation for a modern authenticator later without touching controllers.