Profiles.

A profile is a user reference, a guard, an optional tenant, and an optional redirect, under a name. The page shows one button per profile, and clicking a button acts on everything the profile says.

Profiles live in the profiles key of config/dev-login.php. The array key is both the route parameter and the name that appears in every error message:

'profiles' => [
    'admin' => [
        'label' => 'Admin',
        'email' => 'admin@example.com',
    ],
],

That profile is reachable at POST /dev-login/admin and shows a button reading "Admin".

Every key

label and email are required. The rest default to the values below, which together describe the two-line profile above.

'admin' => [
    'label'            => 'Admin',
    'email'            => 'admin@example.com',
    'guard'            => null,   // null uses the default guard
    'remember'         => false,
    'tenant'           => null,   // handed to the tenant resolver as-is
    'redirect'         => null,   // null follows the precedence chain
    'resolver'         => null,   // null uses the configured resolver
    'fire_login_event' => true,   // false logs in silently
],

A key that is not on this list is a typo. The package throws rather than ignoring it, so guardd fails with a message naming the profile and the unknown setting instead of quietly doing nothing.

Emails identify, they do not authenticate

email is what the resolver looks up. It is never checked against a password, because no password is involved anywhere in the flow.

If your users are not found by email address, the value is still whatever your own resolver wants to make of it. See User resolvers.

Profiles point at users that already exist. A profile naming an address nobody seeded throws ProfileUserNotFound, which names the profile, the address, and asks whether you ran your seeder. That exception is how you find out a config file and a seeder have drifted apart.

Because the published config is a PHP file, it can read the same environment values your seeder does. Two files that share a source cannot drift.

Guards

A profile's guard must name a session guard in your own config/auth.php. The package validates this when it reads the profile:

• A guard that is not in config/auth.php throws InvalidProfile, naming it.
• A guard whose driver is not session throws too. Token and API guards are out of scope, and the config file is a better place to find that out than a session that silently does not persist.

Profiles on different guards coexist on one page:

'profiles' => [
    'member' => [
        'label' => 'Member',
        'email' => 'member@example.com',
    ],
    'admin' => [
        'label' => 'Admin (admin guard)',
        'email' => 'admin@example.com',
        'guard' => 'admin',
    ],
],

Clicking both leaves you authenticated on both guards at once, because each guard keeps its own session state. Clicking a second profile on the same guard replaces the first, with no logout in between.

The user lookup also follows the guard. The shipped resolver asks the guard for its own user provider, so a profile on the admin guard is looked up through whatever provider admin names.

The Login event

A click ends in SessionGuard::login(), so Laravel's Login event fires and anything your application hangs on a real login also runs. Recording a last-seen timestamp, warming a cache, writing an audit row: all of it happens.

That is the default because a login that skips your side effects is not the login you were trying to reproduce.

Set fire_login_event to false for the profiles where you want the account without the consequences. It silences the guard's dispatcher for that one login, which covers Login and the Authenticated event fired alongside it. The guard gets its own dispatcher back immediately afterwards.

How the page orders profiles

The page groups buttons by tenant. Tenants appear in the order they were configured, because a config file is written in the order somebody wanted to read it, and the profiles naming no tenant come last under no heading.

Within a group, profiles keep their config order.

Building a profile in code

Profile is a readonly value object with public promoted properties. Nothing requires it to come from config:

use ByRcsc\LaravelDevLogin\Authenticator;
use ByRcsc\LaravelDevLogin\Profile;

app(Authenticator::class)->login(new Profile(
    key: 'admin',
    label: 'Admin',
    email: 'admin@example.com',
));

The constructor takes the same values the config keys do, in camel case: key, label, email, guard, remember, tenant, redirect, resolver, fireLoginEvent. hasTenant() is the only method on it.

This is what the package's own test suite does, and it is the seam a test of yours can use. See Testing.

What to read next

• The login flow for the order a click acts on these keys in.
• Configuration for the keys outside the profiles list.
• Tenancy if your profiles need to carry a tenant.