Laravel中的命名空间控制器和路由

Question

Assume, I have a model "Post" and I create two resource controllers for it - User/PostController and Admin/PostController.

So when I wish to consume the resource, my routes would look something like this:

/user/post/:id
/admin/post/:id

Is this correct according to the convention or am I doing it wrong?

Answer 1

It is recommended to use a separate model for its controller and vice versa. This will allow you to maintain consistency and readability in the application, keeping the application easy to development.

In the application where there are admin and user accounts, I suggest using Middleware + ( roles + permissions ) and do not stand out in routing /user/ and /admin/ a apply general /user/

Answer 2

In the my example I described, you can use one method in the PostController , for example: show , add permission (eg user-post-list , admin ), add roles (eg admin , user ), in the routing describe who has permission (eg user-post-list , admin ) to given function (show) and assign: permissions to role, roles to user - one or many role to user. You can also add roles to the routing and assigning the appropriate permissions in controller. You can load permissions from the file using fixtures , for example permissions.csv , roles.csv , role_permission.csv or use seeds and fixtures or only seeds - before make create roles and permissions - create the appropriate migrations)

Second solution (and only using Seed) it not flexible, because enlarging the list of permissions and roles involves modifying the code as opposed to the first solution - loading them from the file.

Of course, there are other solutions. I think that the proposing by me has a simple logic, it is effective and flexible to changes.

Check this: https://itsolutionstuff.com/post/laravel-56-user-roles-and-permissions-acl-using-spatie-tutorialexample.html

or

https://www.google.pl/search?q=laravel+roles+and+permissions+tutorial&oq=laravel+roles+&aqs=chrome.4.69i57j69i60j69i65j0l3.11595j0j7&sourceid=chrome&ie=UTF-8

Answer 3

Here is how I go about this problem in Laravel, when having users with different access-types.

Lets say we have a model like you, called Post. Now what we will do is, add a scope to that model, which we'll define a bit further down here:

use App\Scopes\AdminScope;
class Post extends Model {

// Apply a global scope to this controller
    protected static function boot(){
        parent::boot();
        static::addGlobalScope(new AdminScope);
    }

In the router you define it as a regular resource route:

Route::resource('posts', 'PostsController');

In the Controller, you can fetch all Posts on the index method like normal. This will after we create our admin scope, return all the posts in the system for admin users, and those belonging to a specific user for regular users:

class PostsController extends Controller {

public function index(){
    $posts = Post::all();
}

No comes the part where you differentiate wether returning all the posts in the system, or just the ones belonging to the current user, based on the user type that is logged in:

Create a new folder in your app-folder named Scopes. In this folder, create a new file called AdminScope.php which will look something like this:

namespace App\Scopes;

use Illuminate\Database\Eloquent\Scope;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Builder;
use Auth;
class AdminScope implements Scope
{
    /**
     * Apply the scope to a given Eloquent query builder.
     *
     * @param  \Illuminate\Database\Eloquent\Builder  $builder
     * @param  \Illuminate\Database\Eloquent\Model  $model
     * @return void
     */
    public function apply(Builder $builder, Model $model)
    {
        // IF THE CURRENT USER TYPE IS NOT ADMIN, ALTER THE QUERIES:
        if( Auth::user()->type != "admin" ){
            $builder->where('user_id', '=', Auth::user()->id)
        }
    }
}

Ofcourse, this last file you will need to alter to meet the requirements on how you differentiate between a normal user and an administrator.

The good thing about this approach, is that you now can apply this Scope to any model where you see it fit, and it will alter all the queries for non-admin users to only show the Models that they own where the scope is applied.

Note:

This is a global scope, that will apply to all the Eloquent Models where it has been added, and to all queries made for that model. If you want, you can also write conditional local scopes, which you can read more about here:

Local Scopes