How to allow admin user to simulate or authenticate as any other user on my site?

Hi,

You can do a set of routes that only admin can access to display a given user settings and edit them. You do not have to log in as that user.

Hope it helps!

OK thanks, how do I do that exactly?

How are you checking that they are admin now? You apparently have some way in place.

Just make a new controller (and routes) than only admin have access to. index() method lists all users. Clicking on a user takes to the show(user_id) method to display the user form for that user, just like you do for the user to edit.

My users have a type assigned to them in the DB, admin user is set as 'admin' type, they login like any other user, but then see an extra admin menu. So just trying to figure out how to allow them to edit other user's account data as if they were that user.

Create a controller that can only be used by the admin

eg, adapt this to suit

<?php

namespace App\Http\Controllers\Admin;

use Illuminate\Http\Request;
use App\Http\Controllers\Controller;

class ImpersonateController extends Controller
{
    public function store(Request $request)
    {

        session()->put('impersonate',$request->user);

        flash()->success('You are impersonating');  
      
       return redirect()->back();
    }

    public function destroy()
    {
      session()->forget('impersonate');

      return redirect(route('dashboard'));
    }
}

POST the id of the user you want to impersonate to this route

create the following middleware

<?php

namespace App\Http\Middleware;

use Closure;
use Illuminate\Support\Facades\Auth;

class Impersonate
{
    /**
     * Handle an incoming request.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Closure  $next
     * @return mixed
     */
    public function handle($request, Closure $next)
    {
        if(session()->has('impersonate')){
            Auth::onceUsingID(session('impersonate'));
        }

        return $next($request);
    }
}

then add the Impersonate middleware to the web middleware group in Http/Kernel.php

    protected $middlewareGroups = [
        'web' => [
            \App\Http\Middleware\EncryptCookies::class,
            \Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,
            \Illuminate\Session\Middleware\StartSession::class,
            // \Illuminate\Session\Middleware\AuthenticateSession::class,
            \Illuminate\View\Middleware\ShareErrorsFromSession::class,
            \App\Http\Middleware\VerifyCsrfToken::class,
            \Illuminate\Routing\Middleware\SubstituteBindings::class,
            \App\Http\Middleware\Impersonate::class,
        ],

That should be it.

To come out of impersonation, hit the destroy method on the Impersonate controller.

So you don't actually have an admin specific area? I would have implemented a roles/permissions system and used authorization, which is basically what this kind of thing is made for: https://laravel.com/docs/5.7/authorization

I'd really make some sort of control panel for admin users only. But to simply what you're wanting, create a new controller and corresponding routess. In the controller, check that they are admin and issue a 404 if they aren't, so if a regular user tries to access it they'd just see a 404 page. The rest is your basic laravel stuff. index() method lists all users, show($user_id) method shows form to edit a single user, update() save the updated user, etc. I'm not sure what's confusing you here? You just need to make sure the user trying to access these routes is an admin.

You could even just add an "edit" button in the user profile on the existing profile pages that only shows for admin users so they click on it, and it goes to the show($user_id) method of your admin controller.

@cronix It can be a problem if you have locked everything down so that only the authenticated user can edit their own resources. In this case you either go through all those resources and change the checks so that it can be user or admin, or you implement user impersonation.

@snapey It doesn't sound like this app has any sort of checking like you're talking about though. If it was, it would just be as simple as updating the policy and allowing admin to save/edit in addition to the user who "owns" the resource, or user in this case, and not having to impersonate someone. This sounds like the wrong use case for impersonation anyway, as it's generally used to see things from your users point of view as they would see it, not to get around a permission issue?

@cronix we can only work with what is presented

E.g. I've written the code for a regular user to update their settings (and various other actions). Ideally I want an admin to be able to "be" that user as far as my code is concerned, i.e. allow the admin to do anything a user can, to that user's account.

Yes, I've read it. I'm just saying the way he wants to solve via impersonation it isn't the proper way to go. It will work, obviously, but is the wrong tool for the job imho. There are better ways, and I'm sure you'd agree. If an admin has to impersonate a user just to change their resources, something isn't right with that. Admin should be able to do admin type actions as an admin.

I've had a similar issue. I used roles https://laravel.com/docs/5.4/eloquent-relationships#many-to-many and https://laravel.com/docs/5.4/authentication#adding-custom-guards.

@Cronix - I agree with you completely that an admin/superuser should be able to edit other users resources but there are valid use cases for user impersonation by an admin... I.e. troubleshooting/replicating issues as the User

If anyone is looking for a package for user impersonation then https://github.com/404labfr/laravel-impersonate is an excellent choice but remember to be very careful to prevent unauthorised access to the routes!

@D9705996 Yes

but there are valid use cases for user impersonation by an admin

I did say

This sounds like the wrong use case for impersonation anyway, as it's generally used to see things from your users point of view as they would see it, not to get around a permission issue?

Laravel Spark has an impersonation feature, and it works exactly as you described - to give admin a way to view/test/troubleshoot everything from the users perspective.

@ajck - did any of the comments help you fix your problem? If so can you please mark as solution