Authentication For Admin App Login


I am not updating these docs because my focus is on my new PHP Serverless Project.

My LaSalle Software's purpose was always a mixture of learning, marketing, and a basis for my own projects. It has, and is, fulfilling these purposes magnificently!

As always, contact me with your questions.


This page refers to authenticating the administration app's login only.

API authentication is described in the "system" section of these docs.

  • my authentication does not use cookies
  • multiple front-end apps can use a single admin app, so the back-end admin's login authentication accommodates multiple front-ends
  • there is no "users" database table
  • the official users database table is "personbydomain"
  • I use a custom authentication guard
  • my custom auth guard is based on Laravel's sessionguard.php
  • my custom auth guard is called (surprise!) LaSalleGuard.php
  • User = Personbydomain

    Not everyone I have in my database will have login privileges. So I need a database table for non-login-able people ("persons" table), and a separate database table for people who can login ("personbydomains" table). Everyone who can login, who is in the "personbydomains" table, exists in the "persons" table.

    Similarly, email address should reside in a dedicated database table ("emails" table). An email in the "personbydomains" table exists in the "emails" table.

    The name of my users database table reflects that users belong to a front-end domain: "personbydomains". Each personbydomain belongs to an "installed_domain".

    This is the "personbydomains" database table's field structure:

    The LaSalleGuard Custom Guard

    The heart of Laravel's authentication is the guard.

    Laravel comes with guard classes called TokenGuard, RequestGuard, and "SessionGuard":

    Laravel sets the "SessionGuard" as the default guard:

    In order to include front-end domains in my LaSalle Software's "users", I created my own users table called "personbydomains". For authentication, I also did not want to use cookies, I did not want to use Laravel's session token, and I wanted to implement a "logins" database table. I have a separate docs page for my custom "Logins" database table. To implement all of this within Laravel's authentication structure, I create my own custom guard called "LaSalleGuard":

    My custom guard is already set up in my admin app's config:

    Laravel UI Package Contains Core Auth Classes

    Authentication classes resident within the Laravel Framework version 6 (branch 6.x) repository version 6 (branch 6.x) repository are not there in the 7.x branch!

    These files are still needed for Laravel 7.x's authentication!

    These files have been moved to the Laravel UI package.

    Ah, but with a twist: these classes physically reside in a different package. However, their namespace is still the same! This is why I have this package pre-installed, but still including it in composer.json.

    Take a look!

    Admin app needs Laravel's UI package. In the composer require section:
    "laravel/ui": "^2.0",

    Banning Users

    You can ban a user from logging in by checking the "Banned" checkbox their "personbydomain" record:

    If the user is already logged in, they will be logged out at their next request cycle.

    If the user is not yet logged in, they will not be able to log into the admin app.

    You cannot ban yourself. Only owners can ban owners.

    Please note that I have not implemented the ban in the LaSalleGuard's "once" and "onceUsingId" methods. These methods are generally used for testing, or are executed programmatically (not used in the usual course of someone logging in and out of the admin app).

    Emergency Banning All Users From Logging Into The Admin Back-end

    I want a facility where I can:
  • kick out all logged-in users from the admin app's back-end
  • prevent users from logging into the admin app's back-end
  • do this quickly by changing an environment variable from 'false' to 'true'

  • Here is the environment variable:

  • logins database records and session files are not deleted, in case they are needed to trace login activity
  • when users log in, the are presented with the blank login form. No messages. No indication whatsoever that they are banned