Php Auth Core Laravel Package

Getting Started

1. Install and pin. composer require xver/php-auth-core then immediately commit the exact version. Check composer.json in the package for PHP and framework constraints before assuming it fits your runtime.
2. Look at the source first. There is no meaningful published documentation. Start in vendor/xver/php-auth-core/: read README.md if present, composer.json, src/, and any tests/. The public API is whatever the source exposes.
3. Check for Symfony integration. Run bin/console config:dump-reference xver_auth_core (or the likely bundle name) and bin/console debug:container xver. If it is a plain library, you will wire its services yourself; if it ships a bundle, let Flex/recipe registration do the work.
4. First use case: authenticate one user in isolation. Before touching a controller, write a KernelTestCase (or a small script) that instantiates the core auth service, passes a known credential, and asserts success and failure. This proves the package works in your environment and reveals its expected inputs/outputs.
5. Then integrate one flow. Pick either a login form or a token endpoint, call the package from a thin service, and add an HTTP-level test. Do not build registration, password reset, and MFA at the same time.

Implementation Patterns

• Inject, don’t instantiate. Type-hint the package’s auth service in your own service/controller and let autowiring resolve it. Use #[Autowire] for scalar config such as token TTL or a pepper if the package expects constructor arguments.
• Keep controllers thin. For a JSON login endpoint, use a readonly DTO with #[MapRequestPayload], validate it, call the auth service, then regenerate the session or issue a token. Return 204/token payload from the controller, not from the package.
• Wrap the package in an adapter. Define your own AuthenticatorInterface or LoginService that delegates to xver/php-auth-core. This keeps your application code stable if the package is abandoned or replaced, which is likely given its maturity signals.
• Server-rendered vs API. For Twig apps, call the package from a custom Symfony authenticator or a login controller and let SecurityBundle manage the session. For APIs, treat it as a credential verifier/token issuer and keep the HTTP layer stateless.
• User provider integration. If the package defines a user-provider or credential-lookup interface, implement it against Doctrine (or your existing repository). Do not duplicate password hashing—use the package’s hasher if it provides one, and verify the algorithm and parameters it uses.
• Session hygiene on success. Regenerate the session ID, rotate tokens, and clear old auth state. This is application responsibility even if the package performs the credential check.
• Testing pattern. Use WebTestCase for the HTTP login path and KernelTestCase for service-level checks. Assert failure paths (wrong password, unknown user, expired token) as well as success. If Symfony TestPack is missing, install it with composer require symfony/test-pack.
• Events over edits. If the package dispatches events, use #[AsEventListener] for audit logging and lockout counters. Avoid modifying vendor code; decorate services or listen to events instead.
• Configuration via env. Bind secrets through %env(...)% and .env.local; do not hard-code peppers or signing keys in services.yaml.

Gotchas and Tips

• AGPL-3.0 is the biggest operational constraint. The network clause can require source disclosure for modified versions exposed over a network. Get legal review before production; this is not a “just use it” license for many SaaS products.
• Maturity risk is high. Zero stars, zero dependents, and no real docs mean you are the QA team. Pin the exact version, read the source, and keep a fork/adapter path. Verify the release date and Packagist metadata—the listed date is in the future, which is a red flag worth checking.
• The provided AGENTS.md is generic Symfony guidance, not package documentation. Use it for workflow (Flex, attributes, debug:* commands) but not as an API reference. The real API lives under vendor/.
• Autowiring failures are common with unknown packages. If you see “cannot autowire” errors, run bin/console debug:autowiring <ClassName> and debug:container <service>. Add aliases or tags explicitly only after checking whether the package expects them.
• Don’t hand-edit config/bundles.php if a Flex recipe exists. If no recipe exists, register the bundle manually only after confirming it is a bundle and not a plain library.
• Security pitfalls to audit yourself: constant-time password comparison, no credential logging, session fixation prevention, cookie Secure/HttpOnly/SameSite flags, login rate limiting (symfony/rate-limiter), and token expiration/rotation. Do not assume the package handles all of these.
• Compatibility checks: run composer why-not xver/php-auth-core <version> if you hit conflicts, and test on the same PHP version as production. Use devbox run -- php -v / devbox run -- php bin/phpunit if the host lacks PHP.
• Debug with the framework before changing code. Read var/log/dev.log, use /_profiler, and run bin/console lint:container after wiring. A container lint failure is faster to diagnose than a runtime auth failure.
• Prefer Symfony Security if it already covers the need. Only adopt this package if it adds something specific (a protocol, token format, or credential scheme). Otherwise you are adding an AGPL dependency and an unmaintained surface area for no gain.
• Extension points to look for: interfaces, events, and decoratable services. If none exist, keep the adapter wrapper so you can swap the implementation without rewriting your login flow.