Insideauth Laravel Package

Getting Started

InsideAuth provides named authenticators for Laravel apps that need more than one authentication guard/profile. Start by installing the package and publishing any config:

composer require insideauth/insideauth
php artisan vendor:publish --tag=insideauth-config

Look first at the published config to see the registered authenticator names and their backing classes. The default authenticator is named auth, so a first smoke test can call:

use InsideAuth\Facades\InsideAuth;

$auth = InsideAuth::getAuthenticator(); // defaults to "auth"
$user = $auth->authenticate($request);

If you need a non-default authenticator, pass its name explicitly:

$adminAuth = InsideAuth::getAuthenticator('admin');

Your first real use case is usually adding a second login surface - an admin portal, API client auth, or tenant-specific login - without duplicating guard logic. Register that authenticator in config, point it at its user provider/class, and resolve it by name in middleware or controllers.

Implementation Patterns

Resolve authenticators at the edge, not deep in the stack. Prefer resolving InsideAuth::getAuthenticator($name) in middleware, form requests, or controller actions and passing the authenticated user/result downward. This keeps your domain code independent of which authenticator was used.

Use named authenticators for multi-surface auth. Define one authenticator per login surface (auth, admin, api, tenant) rather than branching inside a single authenticator. This keeps guard configuration, session behaviour, and redirects isolated.

Wire Livewire persistent middleware from the package's class list. The release adds a parameter exposing all authentication classes used internally. Use it when configuring Livewire so persistent middleware matches the same authenticators:

use InsideAuth\InsideAuth;
use Livewire\Livewire;

Livewire::addPersistentMiddleware(
    InsideAuth::authenticationClasses()
);

Check the exact method/parameter name in the installed version; the intent is to pass every auth class so Livewire requests re-run the same authentication pipeline as normal HTTP requests.

Prefer the default-name shorthand in single-authenticator apps. If you only have the standard auth authenticator, calling getAuthenticator() without a name reduces noise and makes it easy to introduce named authenticators later.

Integrate with Laravel auth where possible. Use the authenticator inside custom guards or middleware rather than replacing Laravel's Auth facade wholesale. This preserves auth()->user(), policy checks, and Blade directives.

Test each named authenticator independently. Feature tests should hit each login surface and assert the correct user provider and redirect behaviour. Use the class list to confirm Livewire components behave the same under each authenticator.

Gotchas and Tips

• Default name is implicit. getAuthenticator() now silently resolves auth. If you later rename the default authenticator, existing no-argument calls will break. Be explicit in code that genuinely depends on the default.
• Name typos fail at resolution time. Because authenticators are resolved by string name, a misspelled name may only fail when that code path runs. Add a config validation or test that resolves every configured name at boot.
• Livewire persistent middleware must match your authenticators. If you add a new authenticator but forget to include it in the class list passed to addPersistentMiddleware, Livewire requests for that surface may appear unauthenticated or bypass expected middleware.
• Check the exact API for the class list. The release note describes a new parameter exposing all authentication classes; confirm whether it is a method, config key, or constructor parameter in the installed version before relying on it.
• Avoid resolving authenticators in service providers. Resolution may depend on request/session state. Resolve lazily in middleware or request-scoped code.
• Debugging: log the authenticator name and resolved class at the point of use. Most issues are a mismatch between the configured name, the guard used by the route, and the middleware applied to Livewire.
• Extension point: custom authenticators should implement the package's authenticator contract and be registered in config. Prefer extending the provided base class over reimplementing session/remember-me behaviour.
• Upgrade note: the no-argument getAuthenticator() behaviour is additive, not breaking, but audit calls that previously passed an explicit 'auth' if you want consistency across the codebase.