DUPLICATE the default laravel 5 Auth component

Please give more details i don't understand what you want to do here

ok, the question need some details.

as i said, i'm developing small-size ecommerce solution and i'm having 2 types of users (or profiles) : Admins and Clients. Admins have to manage the backend (products, clients, contents ...) and Clients get access to their private client area (upgrade offer, posting comments, choosing payment method ...). logically, admin and clients have 2 completely different profiles, so i separated them in 2 independent tables, one table for each type of user, definitely, i don't need to store them in one table and manage them using roles and acl.

now, i have to authenticate them using 2 separate auth systems. Admins are using the default Laravel 5 Auth system (no problem) and Clients will be using an other Auth system which will be 'simply' a duplication of the default Auth. i've found some solutions like https://github.com/ollieread/multiauth/ but not compatible with laravel 5, i've found some work around to upgrade it to laravel 5 but still not convinced. i've tried to create a custom auth driver, but i'm getting stuck, so the easy way for the moment is to just DUPLICATE the default auth system and customize some fields.

i want a clean and proper way (2 tables, no sessions conflict ) to implement auth system for clients.

i appreciate your help.

Well i have seme issue and i ended up using Sboo multiauth for L5 https://github.com/sboo/multiauth

Try to use it , here is the gist to get you going https://gist.github.com/sboo/10943f39429b001dd9d0

thx, i'll give it a try

Couldn't you make a new class that extends Auth and then make a new instance?

I have the same problem. I went through how it works behind the scene and I think there is a way to do it simple. "The out of the box" Auth injects the $auth (an instance of Guard) which has an access to your auth provider. Eloquent provider has a protected $model which is set at Guard constructor. If you add a setter to EloquentUserProvider you will have an access to setting different model [ $auth->provider->setModel('Admin'); ].

It could be great if someone more experienced tell me if i am right.

It cracks me up how often this exact question is asked on this forum. As there are multiple right ways to do something then this approach isn't technically "wrong". However, that means you are forcing yourself to use the Users and Authentication against it's designed purpose.

I had an app where I thought I had to have this approach because there is no way one table could store front end users (clients or customers or site visitors or whatever you want to call them) while using that same table to store the back end users (admins or staff or whatever you want to call them).

My first attempt was to crete a new Admin class and then extend User. But I ran into all kinds of issues with Auth and other built in functionality. Then I just copied and pasted my "User" class into "Admin" and then changed the names. But again, still ran into lots of duplication to make this approach work. Duplicating code to solve a problem typically shows the solution you are trying to come up with isn't really as great of a solution as you think.

Ultimately I ended up doing what you will one day end up doing, accepting the Laravel User and Auth system as it is written and designing my App to use it. It is absolutely possible and in fact recommended to have only ONE table to contain every single user of your site whether it be a front end user, a back end user, or someone in between.

What I have done on several apps that have front end customers and back end admins (which face it, nearly every single app will have, so the app you are building isn't the first app to deal with this, in fact this is a fairly common occurrence) and here is what I have done on all of them and it's been super easy to maintain...much easier than maintaining two different code bases of Users....try this....

• Use a single users table for everyone.
• Add a column to your users table called is_admin that is a boolean.
• Create a UserProfile Model (and associated user_profiles table) and setup the belongsTo() and hasOne relationships in your models.
• Create an AdminProfile Model (and associated admin_profiles table) and setup the belongsTo() and hasOne relationships in your models.

The result? Your User Model will have a function called userProfile() and another function called adminProfile(). When you create a new user, you create the User Profile right away and they are linked and easy to use. By checking if the user is an admin (based on the is_admin field) you can then know if the user will have an Admin profile or a user profile.

Logging In

This seems to be a main reason people try to take the two table approach, so that only Admin's can log into the admin section with all of their preferences and settings, and users are locked out. But this is very easy. During the Auth::attempt() call, you can pass any other constraints you want in. So if you simply pass the column name and value you are looking for.

if (Auth::attempt(['email' => $email, 'password' => $password, 'is_admin' => 1]))
{
    // The user is an admin and can log into the admin control panel
}

Another benefit of this approach is that your Admin's can log into the main site (unless you restrict it with is_admin => 0).

So far, everyone I have seen try to use the two table approach has ultimately left a comment saying they ended up going to the one table approach and it worked perfectly. With Laravel and Eloquent it's easy to create scopes so that if you wanted to display a list of all Admin's you can do that with a scopeAdmins() function or a scopeUsers() function to limit what you're working on to only users and not admins.

If you really want to make your app better, don't try to re-invent the flat tire that so many people have felt like they needed to do because the tire they didn't realize fits their needs actually fits perfectly.

Also, sorry for all the bad puns (and if I sound condescending sorry, that's not my intention). Best of luck!

Actually to follow up, when developers realize the two table approach is much harder to create and maintain than using the one table approach and using roles that's when they switch. Then they realize how easy it actually is to use the one table approach and are surprised at how resistent they were to it. In other words, once they realize it's easier to put the round peg in the round hole instead of two round pegs in one round hole they switch teams. (I'm sure there's a "that's what she said" joke in there somewhere).