kompo/auth
Kompo Auth gives Laravel apps ready-made authentication: login, registration, password reset, and email verification via prebuilt Kompo components, routes, and middleware. Drop it in to skip auth boilerplate while keeping guards, sessions, and views customizable to fit the rest of your Kompo stack.
1. Verify compatibility before installing. The package is pre-1.0 (v0.7.x), so treat the install as a pilot, not a platform commitment.
composer require kompo/auth
php artisan about # confirm PHP/Laravel versions
composer show kompo/auth # read the actual requirements block
Check vendor/kompo/auth/composer.json for php, illuminate/*, and kompo/* constraints against your app. If you are on a Laravel major the package hasn't declared, stop here — do not force-install with --ignore-platform-reqs on the auth path.
2. Discover what it actually registers. Auto-discovery hides the surface area; make it visible:
php artisan route:list --path=auth
php artisan vendor:publish --provider="Kompo\Auth\AuthServiceProvider"
ls vendor/kompo/auth/src vendor/kompo/auth/routes vendor/kompo/auth/config
Read routes/*.php and the service provider first. Route names, middleware aliases, and guard names are the real contract you will be coding against — everything else is negotiable.
3. Publish and diff, don't blindly accept. Publish config, views, and migrations one group at a time (--tag=config, --tag=views, --tag=migrations). If you already have a users table, do not run the published migration; read it and cherry-pick only the columns you're missing.
4. First use case: gate an existing Kompo CRUD screen. The lowest-risk pilot is protecting an admin area you already have, not rewriting your public auth. Wrap your Kompo resource routes in the package's guest/auth middleware and confirm login, logout, and "remember me" work end-to-end:
Route::middleware(['web', 'auth'])->group(function () {
Route::get('/admin', AdminDashboard::class);
});
That single group proves session handling, guard config, and redirects without touching registration or password reset.
Where to look first: vendor/kompo/auth/src (form/controller classes), vendor/kompo/auth/routes, config/kompo-auth.php if published, and the README's config sample. With zero stars and no changelog, the source is the documentation.
Extend the built-in forms rather than replacing them. Kompo's model is class-based UI, so the natural customization point is subclassing the package's login/registration form and overriding hooks — not forking Blade:
namespace App\Kompo\Auth;
use Kompo\Auth\LoginForm as BaseLoginForm;
class LoginForm extends BaseLoginForm
{
// override the submit handler / redirect / validation
public function handle()
{
parent::handle();
// e.g. log the login, set a flash, redirect by role
}
}
Confirm the exact class names and method names in vendor/ before writing this — at v0.7.x they are not covered by a stability promise. Bind your subclass in a service provider (or via the config's class map, if the package exposes one) so the package's routes resolve your class.
Keep your own route layer in front of it. The most reversible integration is to define your own /login, /register, /password/reset routes pointing at your subclasses, and disable the package's route registration if it offers a config flag. Then the package is a library of forms, not the owner of your URL space.
// config/kompo-auth.php (verify key name in vendor config)
'routes' => false,
Guard and session configuration. Use a dedicated guard if this is an admin-only panel, so a future customer-facing auth system can coexist:
// config/auth.php
'guards' => [
'kompo' => ['driver' => 'session', 'provider' => 'users'],
],
Then pin the middleware (auth:kompo) on the admin group and set the redirect targets explicitly. Never rely on the package's default redirect if your panel lives under a prefix.
Authorization belongs in policies, not the package. Kompo Auth secures authentication. Role/permission logic stays in Laravel gates and policies attached to your Kompo resources. This keeps the package at the edge of your app, where it can be swapped.
Gate::define('manage-billing', fn (User $u) => $u->hasRole('admin'));
Password reset and mail. Point the reset flow at your mailer config and test it against a real transport (Mailpit locally) before any demo. Password reset is the flow most likely to silently break on a package upgrade because it spans routes → notification → view.
Testing pattern. Assert the flows, not the package internals, so upgrades don't rewrite your suite:
public function test_admin_requires_login()
{
$this->get('/admin')->assertRedirect('/login');
$this->actingAs(User::factory()->create())
->get('/admin')
->assertOk();
}
Add one feature test each for login success/failure, registration, and reset-request. That trio is your regression net when you bump the package.
Wrap it, minimally. If you touch more than three package classes, add a thin App\Auth layer (a login()/logout() helper or a single bound interface) so a future replacement is a config swap rather than a grep-and-replace across the codebase.
"kompo/auth": "0.7.111") in composer.json, commit the lock file, and treat every composer update that touches it as a code change requiring a diff review. The high patch count signals a moving API.vendor/kompo/auth between versions (composer diff or a git-diff of the vendor dir) before merging. If you cannot explain the upgrade risk, don't take it.bootstrap/cache/packages.php, run php artisan route:clear, and confirm the provider is actually discovered (php artisan about or config/app.php for older skeletons).users migration. On an existing app, never migrate it — extract only the missing columns into a new migration with a timestamp that sorts after your original.login, logout, password.request. Grep your app for route('login') before installing; Laravel resolves the last registered name silently, so a duplicate can hijack your existing redirects.@csrf or the meta tag Kompo expects) and that the session cookie domain matches the app URL. This is the single most common "it doesn't work" cause with Kompo + auth./login and /admin almost always means the guard is misconfigured or the guest middleware is applied to /login under the wrong guard. Check config/auth.php first, then the middleware aliases in route:list.SESSION_LIFETIME and a cleared cookie jar; it's the feature most often left half-configured and discovered broken in production.route:list --path=auth → php artisan tinker with Auth::guard(...)->check() → read the package's form handle() method → Log::info inside your subclass. Do not patch vendor/.Illuminate\Auth\Events\*). Avoid: editing vendor code, overriding the service provider, and putting business rules inside the package's forms — those are the hooks that vanish at 1.0.laravel/breeze or a hand-rolled controller — your App\Kompo\Auth\* subclasses are the only thing you'd rewrite.How can I help you explore Laravel packages today?