Customizing the page.

The page is one Blade view wrapping a <x-dev-login::profiles /> component. Both are publishable, and the component works anywhere you drop it.

Publishing the views is the whole customization story. There is no theming config, and that is a decision: the page shows the current environment as a badge, and it is not meant to be turned into something that looks like your real login.

Embedding the buttons in your own page

One tag, and nothing from the surrounding page:

<h1>Our own login page</h1>

<x-dev-login::profiles />

The component carries its own styles in an @once block, scoped to the .dev-login-profiles class, depending on nothing. It inherits text colour from the page around it, so a dark host page stays readable.

It also asks the safety gates itself rather than trusting the page it is on. On an environment or a host where the package may not run, it renders an empty string. Your own login form stays, the dev buttons disappear.

The component namespace is registered whether or not the gates pass, so the tag never breaks a view.

What it renders

One <form method="POST"> per profile, each posting to route('dev-login.attempt', $profile->key) with @csrf, and a submit button carrying the profile's label.

Profiles are grouped into <section> elements by tenant, with an <h2> per tenant. Profiles naming no tenant come last, in a section labelled aria-label="Profiles with no tenant".

With no profiles configured, it renders a line pointing at the config key.

Labels only. No email address ever reaches the page, because an address on a button is an account identifier in every screenshot and every screen share.

Publishing the views

php artisan vendor:publish --tag=dev-login-views

This writes two files:

Laravel prefers published views over the package's, so editing either one takes effect immediately.

Replacing index.blade.php changes the page and leaves the component alone. Replacing components/profiles.blade.php changes the buttons everywhere, including on pages of your own that embed the component.

Writing your own buttons

The published component receives one variable, $groups, from ProfileRepository::groupedByTenant(). Its shape is:

[
    ['tenant' => 'acme', 'profiles' => [Profile, Profile]],
    ['tenant' => null,   'profiles' => [Profile]],
]

Each Profile is a readonly object with public key, label, email, guard, remember, tenant, redirect, resolver, and fireLoginEvent.

The minimum a replacement has to do is post to the attempt route with a CSRF token:

@foreach ($groups as $group)
    @foreach ($group['profiles'] as $profile)
        <form method="POST" action="{{ route('dev-login.attempt', $profile->key) }}">
            @csrf
            <button type="submit">{{ $profile->label }}</button>
        </form>
    @endforeach
@endforeach

Keep it a POST. A GET link would let an image tag or a prefetch log somebody in.

If you print anything from $profile, leave email out. That is the one field the shipped component deliberately never renders.

Reading profiles yourself

ProfileRepository is resolvable from the container if you want the list somewhere other than a Blade view:

use ByRcsc\LaravelDevLogin\ProfileRepository;

$profiles = app(ProfileRepository::class);

$profiles->all();              // array<string, Profile>, keyed by route parameter
$profiles->groupedByTenant();  // the display order the page uses
$profiles->find('admin');      // one Profile, or ProfileNotFound

Every method validates as it reads, so a malformed profile throws InvalidProfile here rather than later.

Check the gates before rendering anything from these, the way the component does. See Safety gates.

What to read next

• Safety gates for what the component checks before rendering.
• Profiles for the fields available on each Profile.
• Routes and redirects to move the page the buttons post to.