Roles are good for multiple login and you use Middleware to determine auth user roles and redirect to homespace or use multiple guards which i do not prefer
Login Using different roles or different tables?
I have used users table with multiple roles for authentication. Now that I am finding that everywhere in Laravel examples on internet when I search for authentication they have used different tables. What are the pros and cons? I had given it a good thought before using same table. But have not searched google much for the multiple logins.
i think you need this for example you have users table and you set types of users and give them roles like(admin, manager, worker, etc..) and create a middleware for the roles you want
this a middleware for admin
<?php
namespace App\Http\Middleware;
use Closure;
use Illuminate\Support\Facades\Auth;
class AdminMiddleware
{
/**
* Handle an incoming request.
*
* @param \Illuminate\Http\Request $request
* @param \Closure $next
* @return mixed
*/
public function handle($request, Closure $next)
{
if(Auth::user()->usertype == 'admin') {
return $next($request);
} else {
return back();
}
}
}
to create a middleware
php artisan make:middleware AdminMiddleware
then in users table
<?php
use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;
class CreateUsersTable extends Migration
{
/**
* Run the migrations.
*
* @return void
*/
public function up()
{
Schema::create('users', function (Blueprint $table) {
$table->bigIncrements('id');
$table->string('name');
$table->string('usertype')->nullable();
$table->string('email')->unique();
$table->timestamp('email_verified_at')->nullable();
$table->string('password');
$table->rememberToken();
$table->timestamps();
});
}
/**
* Reverse the migrations.
*
* @return void
*/
public function down()
{
Schema::dropIfExists('users');
}
}
and then go to your phpmyadmin in users table
then set any usertype you want for example(admin) then your roles will be setted well as u want let me know if you have a problem
@player4 Please, don’t store different user types across different tables. What you have done already (users table with multiple roles) is perfectly acceptable.
A user is a user. You don’t need to split different “types” across different tables. It just adds unnecessary complexity. If you have say, a “regular” user and an admin, and they’re in different tables, what happens when you want to elevate a user to an admin? What happens if you want to add a new user type, say a moderator? You then have to create migrations, guards, controllers and views just to support a new role.
So keep your application users in a single table, assign them roles, and then use authorization to determine what a user can do in your application based on their role(s).
@player4 according to @martinbean he did explain it well no need of creating different tables
notice also in ur login controller just use this to determine who is logged in
//public $redirectTo = '/home';
protected function redirectTo () {
if(Auth::user()->usertype == 'admin')
{
return 'dashboard';
}
elseif(Auth::user()->usertype == 'manager')
{
return 'manager-dashboard';
}
else
{
return 'home';
}
}
you can also create another middleware for example: manager, as i did on admin and also look out about user policies will help u well
Thank you jamalroger. I think guards can also be used not just only with different tables. I think guard is just meant for separate handling.
Thank you martinbean.
What if I still use guards to manage different logins while keeping one table users.
It looks like the fundamentals behind different table approach is to compartmentalize and "completely" separate the logic in separate units.
I have personally started dividing code in small classes to keep strongly cohesive, loosely coupled, and divide and conquer approach.
So that may end up in more number of files. But it helps in avoiding any class responsibility to become too long or complex.
So possibly we are doing a trade off between keeping less files, tables or keeping more files, but less complexity in any single class. Please enlighten me on this.
Thanks again. Please excuse me if it doesn't make sense.
Thank you Niyo for elaborating. It really helped.
@player4 Use the default guard to determine if a user is logged in or not. Then use authorisation to determine if they’re trying to access a route their role allows them to or not.
Please or to participate in this conversation.