Need advise role system or multi auth?

I hope it is understandable what I wrote? I need to know what is the best practice for such an app to not run in any issues after a while of developing.

I researched a little bit on how to tackle this and I think I should make an multi auth for customers and normal users (Or two apps using the same database?). So this means a different migration for users and customers. Beside that I am going to create a role system with 3 different types of users, normal user, admin and customer. The admins should be stored in the users table so there are two types of users in the same table. So I think this is a good way to go, if someone has an better approach please tell me how.

best

i have in the past written a different auth guard for the admin and to be honest, that's so annoying i'll never do that anymore.

I'll advice you to use this: https://github.com/spatie/laravel-permission

In my case I like to have all the users in the same table so then I can use the authentication that laravel uses out of the box without needing to change it. In my projects I like to use this package ( https://github.com/tightenco/parental ), basically it lets you have all the users in the same table and extend the user model to have different user types (teacher, student, coordinator...) in each model so it looks very clean.

I think there's not a best way to do it, you just need to try some options and use the one you are more comfortable with. In a previous post someone had a similar problem and they suggested him to take a look at this post: https://tighten.co/blog/extending-models-in-eloquent

Hope it helps.

@MANELGAVALDA - never thought about extending the user model, that's pretty smart.

The only issue i've with this method is, you can't 100% customize your permissions. With the laravel-permission package I can create an unlimited numbers of rôle with different permission.

The best solution depend on what you want.

@vincentkos will have a look at that thanks for your answer.

@manelgavalda Your approach sounds nice but there is one problem. My customer has completely different fields to store how should I solve this?

@VINCENTKOS - Hey, yeah It depends on what you want, in the case of extending the model the good thing is that you can have completly different logic for each type of users, for example I liked this approach in an school application, because the teacher and the student had very different logic (and it wasn't just about permissions), I liked that when I called $student->subjects showed me the subjects that the student was enrolled to, and when I called $teacher->subjects showed me the subjects that the teacher was teaching, and the same for a lot of methods that for example the teacher didn't need to have, but the student had.

@smoketm Yep, that's the ugly part of this approach that all the user data is on the same table, what you can do in order to "solve" this is to create a profile section for the student, then there's other possible "problems", (you will need to query the relation if you want to have all the data):

username
password
email
type // (student, teacher, coordinator)
profile_id // only for students

So instead of looking for a lot of empty fields on the table, you will just end up having 1 empty field(profile_id), in my case I prefered to have empty fields on my user table, it was the solution I was happier with, you just need to have the general fields first:

username
password
email
type // (student, teacher, coordinator)
student_field_1 //optional
student_field_2 //optional
student_field_3 //optional
....

Some good things about this approach is that is very easy to work with users in general (User::all()) or work with a specific user type (Teacher::all(), Student::all()...), and keep the user logic to each own:

But to keep it simple just try the simplest approach and see if you are comfortable with.

@manelgavalda thanks for your answer I will play with that approach for sure.

If you code an app where different user types are needed is it a common way to have multi auth? For example for admins for customers and for normal users let's say?

@SMOKETM - I think the best for this case it's just to use guards, because the different type of users (admin, customers and users) don't need to share the methods or code. I think the easier way will be just to create an "admin" an a "customer" guard, something like this: https://blog.muva.tech/laravel-5-4-our-admin-model-and-admin-guard/

This is the approach I'm currently using for a shop, that has customers and admins, and does the job.

@manelgavalda thanks for your answer yes that would be an option, but another thought a I had was to build two different apps one for customers and one for users. The customer app does completely different stuff than the users app. And then share the needed data from the users app with the customers app? Would that be a good idea because its a little bit confusing with all that different guards and routes and so on?

best

@SMOKETM - Yeah, I think that's also a good idea, you can try it.

All the options that the people said before are also good options, you just need to use your preferred one, and if you don't like it just change it.