AdminArchitect — Authentication options

Authenticate everyone!

AdminAtchitect offers a various user authentication options to help identify users before they interact with missions-critical data and application.
If you’re not familiar with AdminArchitect — it will take about 4 minutes of your time to meet him.
AdminArchitect — Login screen

This is the default Login screen, you’ll see each time you’re trying to access your admin zone.

As you might see, AdminArchitect defaults your identity/credentials pair to Email & Password fields. The reasonable question is — “What if I need different login scheme?”.

Custom credentials

To allow authentication by another identity/credential pair, open your config/administrator.php file, and change the auth.identity and/or auth.credential key values.

For instance, for authentication by username instead of email, your auth section might look like:

That will result to:

AdminArchitect — Login by username

Dedicated table/Eloquent model

Another, very popular case is when you need to store your Admin users into a separated table (ex: admins). This is also surprisingly easy:

  1. You need the admins table.
  2. Then create App\Admin Eloquent model which implements Illuminate\Contracts\Auth\Authenticatable contract and uses Illuminate\Auth\Authenticatable trait.

Then pin new created model in config/administrator.php file.


From this moment, AdminArchitect will look into admins table in order to find and authenticate the user.

P.S. SuperAdmin rule

Out of the box, right after installation, AdminArchitect allows you to create a new SuperAdmin user by running php artisan administrator:create command.

But as you know, the users table doesn’t have any specific column indicating the User’s role. AdminArchitect handles this case by providing a pre-defined SuperAdmin rule. Every time user is logged in, the authenticated user (ex.: App\User) is asked for an isSuperAdmin status.

Follow the simple flow:

  1. Unauthenticated user doesn’t have access to admin zone.
  2. If your Authenticatable model has isSuperAdmin method defined, AdminArchitect will allow/deny access for logged in user depending of returned value.
  3. Only user with id===1 can access admin zone.

Mostly, you’ll just have to implement isSuperAdmin method for your authentication logic.

AdminArchitect — isSuperAdmin

P.P.S. Conditional fetching

Sometimes you need to apply strict rules while authenticating users. It may be a custom role or active column.

For this purpose you can define a special auth.conditions option.

It accepts an array of where statements which will be applied to a final query.

AdminArchitect — Auth conditions

Keep your users under control, Thanks!