Verify Laravel Package

Getting Started

toddish/verify is a Laravel 4-era authentication bundle that predates Breeze/Fortify. It ships a full auth stack in one package: login/logout, registration with optional email confirmation, password reminders, remember-me, failed-attempt throttling, and RBAC (roles, permissions, groups). Treat it as a drop-in Auth driver replacement with a permissions layer on top.

Install and wire up (Laravel 4 style):

composer require toddish/verify

In app/config/app.php:

'providers' => [
    // ...
    'Toddish\Verify\VerifyServiceProvider',
],
'aliases' => [
    // ...
    'Verify' => 'Toddish\Verify\Facades\Verify',
],

Publish config and migrations, then migrate:

php artisan config:publish toddish/verify
php artisan migrate --package="toddish/verify"

First place to look: app/config/packages/toddish/verify/config.php. The two keys you will touch first are:

• user — the Eloquent model that extends Toddish\Verify\Models\User (not your existing User).
• login_column — the column used as the identifier (email by default; change to username if needed).

First use case — replacing the default Auth driver. In app/config/auth.php, set:

'driver' => 'verify',
'model'  => 'User', // your class extending Toddish\Verify\Models\User

Then your existing Auth::attempt($credentials) calls keep working, but now also fire throttling and return richer user objects. If you want to use the package's own facade instead:

Verify::attempt(['email' => $email, 'password' => $password], $remember);
Verify::check();      // bool
Verify::user();       // User model or null
Verify::logout();

Swap your generated User model's parent from Eloquent to Toddish\Verify\Models\User, and the role/permission methods (is(), can(), level(), roles(), permissions()) light up immediately.

Implementation Patterns

Registration flow. Two paths depending on registration_confirm:

// config: 'registration_confirm' => true
$user = Verify::register($input); // creates user in "confirmed = 0" state, emails a token
// later, from the confirmation route:
Verify::confirm($token);

With registration_confirm => false, register() immediately logs the user in — handy for internal tools, dangerous for public signup.

Login with post-login hooks. Rather than checking Auth::check() in every controller, centralize:

if (Verify::attempt($credentials)) {
    $user = Verify::user();
    if ($user->disabled) { Verify::logout(); return Redirect::back()->withError('Account disabled'); }
    return Redirect::intended('/dashboard');
}

The package already enforces max_login_attempts and throttle_interval; don't roll your own counter on top.

Permission checks — three layers, use the right one.

$user->is('admin');              // role name match
$user->can('posts.edit');       // direct or via role
$user->level(50);               // numeric level threshold

Prefer can() in views/controllers; reserve is() for branching that genuinely differs by role (e.g. different dashboards). level() is convenient but opaque — the numeric thresholds are easy to forget across a codebase.

Assigning permissions at seed time.

$admin = Role::create(['name' => 'admin', 'level' => 10]);
$admin->permissions()->sync([$editPosts->id, $deletePosts->id]);
$user->roles()->attach($admin->id);

Use sync() on the pivot for idempotent seeding; attach() in a loop will duplicate rows.

Route protection via filters (L4) / middleware (L5). The package fires the standard auth filter semantics — register a custom filter or middleware that wraps Verify::check() and optionally Verify::user()->can($permission). Keep the permission name in the route definition so the matrix is grep-able:

Route::get('/admin/posts', ['before' => 'verify.can:posts.edit', 'uses' => 'AdminController@posts']);

Password reminders. The package's Reminders integration expects a password_reminders table (included in migrations) and reads mailer / email_view from config. If you already have a reminders implementation, disable the package's routes and keep only the model/migrations.

Gotchas and Tips

• This is a Laravel 4 package. Composer constraints cap out around illuminate/* ~4.x. If you're on L5+, you almost certainly want Breeze/Fortify; only pull this in for legacy migrations. Verify the composer.json requires before committing to it.
• Your User model must extend Toddish\Verify\Models\User. A common failure is keeping extends Eloquent and then wondering why can() throws BadMethodCallException. The package relies on its own traits and relations, not a wrapper.
• login_column mismatch silently breaks login. If you set it to username but the form posts email, attempt() just returns false with no error. Log the exact credential keys you're passing during debugging.
• The Verify facade and Auth facade are not interchangeable in all cases. Auth::user() returns the model via the driver; Verify::user() goes through the same guard. Use one consistently — mixing them in tests leads to confusing null states because Auth::login() doesn't always hydrate what Verify expects.
• Throttling is per-credential, not per-IP. A bot rotating usernames bypasses max_login_attempts. Add a route-level IP throttle on top for public login endpoints.
• Email confirmation tokens are stored in the user row, not a separate tokens table. Re-sending a confirmation means regenerating the token on the user model — check the package's sendConfirmation() method rather than inventing your own column.
• Permission lookups hit the DB per call unless you eager load. In list views, User::with('roles.permissions', 'permissions')->get() saves the N+1 that can() triggers per row.
• disabled and soft-deletes are separate. The guard checks disabled but does not honour SoftDeletes by default. If you delete users logically, also flip disabled = 1 or they stay effectively active.
• Migrations must run before your app's own migrations if yours reference user_id foreign keys. Rename files with an earlier timestamp prefix if necessary, or drop FK constraints during the legacy migration and add them post-hoc.
• Extension points: override the User, Role, Permission, and Group classes via the user config key, and swap the whole guard by registering a new Auth driver if you need custom behaviour — the package is intentionally thin over Illuminate\Auth\Guard.
• Testing: Auth::be($user) works, but the throttling table persists between tests. Flush it in setUp() or you'll get sporadic "too many attempts" failures that only appear when you run the full suite.