Each user access to admin panel by default!

[bahman2216]

It there any way to prevent access other users to admin panel?
I made roles for user and admin, But there is no gui mode to assign role to user.

[OwenMelbz]

Hi, I'm not 100% what you mean sorry.

Are you saying that normal front end users can access the admin, and how can you prevent this?

[bahman2216]

With permission manager you can create user. But user can access admin panel!
There is no role to check user has access to admin route or not.

[OwenMelbz]

Sure, you need to create middleware on your application to filter out users without the correct permissions.

If you search the backpack github both in crud and here you'll find lots of examples of this question already. 90% of them use middleware or guards

[bahman2216]

I know, But I mean all CRUD routes has both "web" and "admin" middlware.
I can change original source code to remove "web" middlware. But I do not want to do this. Im looking for better way.

[OwenMelbz]

You dont need to do that.

Just create your own middleware that checks your user is an admin.

The backpack admin middleware is less than perfect, it just checks if they're logged in I think.

You can follow the instructions by spatie - as this is what the permission manager

https://packagist.org/packages/spatie/laravel-permission#user-content-using-a-middleware

[bahman2216]

I read the doc and made my custom middlware.
But all routes in service providers Backpack has web middlware by default and I could not overide them.
For instance,

/admin/page

has both admin and web middlware and my route middlware did not affect on this route.

[OwenMelbz]

you do not need to overwrite the web and admin middleware.

You can just add your own middleware on top.

You can assign middleware to whole route groups.

You can also define the routes yourself if you do not want the service providers inside the vendor folder

[tabacitu]

Hi @bahman2216 ,

You can shut off all the routes Backpack\Base is creating by changing this value in your base config file:

    // Set this to false if you would like to use your own AuthController and PasswordController
    // (you then need to setup your auth routes manually in your routes.php file)
    'setup_auth_routes' => true,

    // Set this to false if you would like to skip adding the dashboard routes
    // (you then need to overwrite the login route on your AuthController)
    'setup_dashboard_routes' => true,

You can then create the routes you need, something like:

Route::group(['prefix' => config('backpack.base.route_prefix')], function () {
    // Admin authentication routes
    Route::auth();
});

---

@OwenMelbz , seems like many people have this confusion. I think we can fix this by:

• including the "role" and "permission" middleware in Backpack\PermissionManager;
  +/- including a "superadmin" role and "admin panel access" permission;

What do you think? I think the "superadmin" suggestion is a bit too much - people might not have that role, or might need more detailed permissions, for each admin panel page. So I think the best way to go would be to just include the middleware and instruct people when installing PermissionManager to create the roles and permissions they need (using a Seed) and place the routes they want under the right middleware. You think that would be too little help?

Cheers!

[OwenMelbz]

My personal opinion is the fact that session sharing between any generic users is wrong.

e.g If you're logged in to the admin, you're also logged into the frontend, which is highly unpractical I've found, as admins might not be frontend users, for example we have one application where users must belong to a school. But admins will not, meaning you cannot use the frontend and admin at the same time.

I think we need to implement an backpackAdmin authentication guard on backpack itself, which allows the separation.

We could publish this middleware which will run default checks against the guard, then users can expand this middleware to handle their custom functionality, which might be role or permission based.

[tabacitu]

Damn. You may be right, some projects will have zero functionality on the front-end for the admin. Others, however, will allow him to still use the app as a user (think SaaS, forum, etc). So it's a little trickier than I expected... WIll think about it and get back to you.

[OwenMelbz]

I think it could potentially be pretty simple, although would not be fully backwards compatible, and a fair amount of files to change

within the config we would need a setup like

return [

    'separate_admin_session' => true,
    'admin_guard' => [
            'name' => 'backpackAdmin',
            'driver' => 'session',
            'provider' => 'users',
        ],
];

then we create the middleware something like, which can be published for expansion

public function handle($request, Closure $next, $guard = null)
{
    if (config('backpack.separate_admin_session')) {
        if (!\Auth::guard(config('backpack.admin_guard.name'))->check()) {
            return redirect(config('backpack.admin_path').'/login');
        }
    }
    
    return $next($request);
}

We'd also need to inject the middleware into $routeMiddleware within the Kernal.php however not really sure how to go about doing this, i guess in the service provider somhow

We'd then also need to make sure all the auth classes define the class e.g. in the LoginController we'd need

public function guard()
{
    return \Auth::guard(config('backpack.admin_guard.name'));
}

We would then also need to update all the templates / classes that do things like

Auth::check() or Auth::user() to Auth::guard(config('backpack.auth_guard.name'))->user()

I had considered a backpack user helper like backpack_admin() which automatically returns the authenticated admin user and then even maybe a backpack_user()

We'd also need to figure out how to get users to apply the middleware to the routes, maybe we can do that in the CrudRouter if the feature is enabled?

It does seem a fair amount of work and extra code, but I think its a definitely worth feature!

[OwenMelbz]

Ended up adding a PR for this Laravel-Backpack/Base#87

[lloy0076]

Please see the PR Laravel-Backpack/Base#87.