front and back user separation?
Created 6 years ago by spotony

Hi, all!

I would like to add a website user management module, the original user module as a background manager to use. Consult the program! How to separate?

<?php
return [

    /*
    |--------------------------------------------------------------------------
    | Authentication Defaults
    |--------------------------------------------------------------------------
    |
    | This option controls the default authentication "guard" and password
    | reset options for your application. You may change these defaults
    | as required, but they're a perfect start for most applications.
    |
    */
    'defaults' => [
        'guard'     => 'admin',
        'passwords' => 'users_users',
    ],

    /*
    |--------------------------------------------------------------------------
    | Authentication Guards
    |--------------------------------------------------------------------------
    |
    | Next, you may define every authentication guard for your application.
    | Of course, a great default configuration has been defined for you
    | here which uses session storage and the Eloquent user provider.
    |
    | All authentication drivers have a user provider. This defines how the
    | users are actually retrieved out of your database or other storage
    | mechanisms used by this application to persist your user's data.
    |
    | Supported: "session", "token"
    |
    */

    'guards' => [
        'web' => [
            'driver'   => 'session',
            'provider' => 'users',
        ],
        'admin' => [
            'driver'   => 'session',
            'provider' => 'admin',
        ],

        'api' => [
            'driver'   => 'token',
            'provider' => 'users',
        ],
    ],

    /*
    |--------------------------------------------------------------------------
    | User Providers
    |--------------------------------------------------------------------------
    |
    | All authentication drivers have a user provider. This defines how the
    | users are actually retrieved out of your database or other storage
    | mechanisms used by this application to persist your user's data.
    |
    | If you have multiple user tables or models you may configure multiple
    | sources which represent each model / table. These sources may then
    | be assigned to any extra authentication guards you have defined.
    |
    | Supported: "database", "eloquent"
    |
    */

    'providers' => [
        'users' => [
            'driver' => 'eloquent',
            'model'  => MyApp\MemberModule\Member\MemberModel::class,
        ],

        'admin' => [
            'driver' => 'eloquent',
            'model'  => Anomaly\UsersModule\User\UserModel::class,
        ],

        // 'users' => [
        //     'driver' => 'database',
        //     'table' => 'users',
        // ],
    ],

    /*
    |--------------------------------------------------------------------------
    | Resetting Passwords
    |--------------------------------------------------------------------------
    |
    | Here you may set the options for resetting passwords including the view
    | that is your password reset e-mail. You may also set the name of the
    | table that maintains all of the reset tokens for your application.
    |
    | You may specify multiple password reset configurations if you have more
    | than one user table or model in the application and you want to have
    | separate password reset settings based on the specific user types.
    |
    | The expire time is the number of minutes that the reset token should be
    | considered valid. This security feature keeps tokens short-lived so
    | they have less time to be guessed. You may change this as needed.
    |
    */

    'passwords' => [
        'users' => [
            'provider' => 'users',
            'table'    => 'password_resets',
            'expire'   => 60,
        ],
    ],

];
piterden  —  6 years ago

We need by context separation of all resources of system

fryiee  —  6 years ago

I'm not sure I'm understanding you fully - you want to use the users system, but separate it into a different DB table? Is that it? Because most of the stuff (limiting admin access etc) can be accomplished by way of permissions, or adding fields to existing user model to delineate state.

ryanthompson  —  6 years ago

I don't think we fully grasp what you're after but you could use a custom field assigned to users or a role for example to separate them?

piterden  —  6 years ago

I mean another thing: what if one user would need to login separately to front and to CP? Is it possible to implement?

ryanthompson  —  6 years ago

That's super weird but it could be done. You'd need some serious customization.

fryiee  —  6 years ago

This is already implemented through laravel's guard functionality, you just need to override the logout() method so that it doesn't flush the session, this issue sums it up fairly well: https://github.com/laravel/framework/issues/16322

spotony  —  6 years ago

@ryanthompson

Do you have any suggestions and suggestions?

ryanthompson  —  6 years ago

IMO it's kinda Laravel at this point. Add a guard as @fryiee mentioned and go from there. We'd need more narrow questions it's kinda wide open at this point. You need to do some investigation and testing and see what your options are based on the tools available to you 😊

Good luck!

piterden  —  6 years ago

Modx has context based auth out from the box. You could ask @william about it.