Laravel Dummyuser Laravel Package

Getting Started

Install the package into a Laravel 5.x application:

composer require longman/laravel-dummyuser

On Laravel 5.5+ the service provider is auto-discovered. On 5.4 and below, register Longman\DummyUser\DummyUserServiceProvider in config/app.php and publish the package config:

php artisan vendor:publish --provider="Longman\DummyUser\DummyUserServiceProvider"

Look first at the published config (typically config/dummyuser.php) and the package’s DummyUser model/trait. Those two files tell you everything the package offers: the default attributes (id, name, email, password) and how the authenticatable contract is satisfied.

The first and most valuable use case is logging in without a users table. From tinker or a throwaway route:

auth()->login(new Longman\DummyUser\DummyUser);

If that succeeds, auth()->user() returns a dummy instance and middleware like auth passes. Use this whenever you need a signed-in context before your real User model, migrations, or registration flow are ready — auth scaffolding, Blade layout checks, middleware/policy prototyping, demo environments.

Implementation Patterns

Guard-based wiring. Point a dedicated guard at the dummy provider instead of replacing your real guard. Keeps production auth untouched:

// config/auth.php
'guards' => [
    'dummy' => [
        'driver'   => 'session',
        'provider' => 'dummy',
    ],
],
'providers' => [
    'dummy' => [
        'driver' => 'dummy',
        'model'  => Longman\DummyUser\DummyUser::class,
    ],
],

Then use auth('dummy') explicitly in dev-only routes and tests. If the package does not ship a custom provider driver, use the eloquent driver pointed at the dummy model — it will still satisfy Authenticatable for non-persisted use cases.

Dev-only demo login route. A common pattern is a route that authenticates the dummy user while the app is incomplete:

Route::get('/dev/login', function () {
    abort_unless(app()->environment('local', 'staging'), 404);
    auth()->login(new DummyUser);
    return redirect('/dashboard');
});

Wrap it in an environment check every time. The package itself has no opinion about who can call this.

Testing scaffolding. Use it in feature tests that require an authenticated actor but where the users table is irrelevant to the assertion:

$this->actingAs(new DummyUser, 'web')
     ->get('/reports')
     ->assertOk();

This avoids database factories and seed data for tests that only exercise middleware, gates, or route access.

Config-driven attributes. Set name/email/id in the published config so that dummy users are recognizable in logs and UI (e.g. email = [email protected]), and so tests can assert on stable values rather than hard-coded strings.

Extension via subclass. When you need different roles or permission sets for different dev scenarios, subclass the dummy model and set $attributes or override hasRole/can behavior:

class AdminDummyUser extends DummyUser
{
    protected $attributes = ['id' => 999, 'name' => 'Dev Admin'];
}

This keeps the package untouched while letting you drive authorization branches locally.

Use as a reference implementation. With a single dependency and a 2017 release, the package’s real day-to-day value is often as a template: copy the Authenticatable implementation into your own app/Support/DummyUser.php and drop the dependency. That eliminates supply-chain and Laravel-version concerns.

Gotchas and Tips

• Laravel 5.x only. The 2017 release predates later authentication changes (e.g. password/rehash handling and typed contracts). On Laravel 8+ expect Authenticatable/MustVerifyEmail signature mismatches; on Laravel 6+ treat it as unsupported. Test on your target framework before relying on it.
• Never ship to production. A dummy authenticatable that can be logged in without credentials is a footgun. Gate any usage behind app()->environment('local', 'staging') and, ideally, an explicit config flag. Add the dev route only when the flag is on.
• Session persistence is real. Using auth()->login() writes to the session store. With a shared dummy user id, multiple developers or test cases can collide. In tests prefer actingAs() and RefreshDatabase-style isolation of the session.
• Remember-me requires getRememberToken. If your dummy model does not implement a non-null remember token, auth()->login($user, true) can behave unexpectedly. Override getRememberToken/setRememberToken or avoid remember cookies for dummy sessions.
• Password hashing. If the dummy model returns a plaintext password from getAuthPassword(), credential-based attempts will fail. Either set a bcrypt-hashed value in config or skip the credential path entirely and log in directly.
• Config cache. After changing dummy attributes run php artisan config:clear; stale cached config is the usual cause of “why is my dummy email still the old one.”
• Guard confusion. auth()->user() reflects the default guard. If you wired a separate dummy guard, tests and controllers must call auth('dummy') or you will get null and misdiagnose it as a package bug.
• Unique IDs for assertions. A fixed id is fine for display but can break anything that keys per-user state (notifications, caches, rate limiters). Override the id per test or subclass with distinct values.
• Extension points are just the model. Beyond config and subclassing, do not expect hooks or events. If you need role/permission integration (Spatie, Gate definitions), implement it in your subclass rather than patching vendor code.
• Debugging checklist: composer dump-autoload after subclassing, verify provider registration on Laravel <5.5, check the guard name, then confirm the session driver is not array if you expect the login to survive a redirect.