Как изменить стандартное промежуточное программное обеспечение для аутентификации Laravel - PullRequest
0 голосов
/ 07 сентября 2018

Итак, как говорится в моем заголовке, я хочу изменить стандартное Broadcast аутентификационное промежуточное ПО Laravel на собственное аутентификационное промежуточное ПО, которое я создал и использует аутентификацию на основе токенов. Я сделал это потому, что мое приложение является приложением на основе API, и, когда пользователь проходит аутентификацию, я создаю токен сеанса и отправляю ему, а также сохраняю в БД со столбцом expires_at. Я использую Pusher.

У меня есть следующее промежуточное ПО:

class AuthCustom
{
    public function handle($request, Closure $next)
    {
        // if we have the session token stored in header
        if ($request->header('x-session')) {
            $session = Session::where('id', $request->header('x-session'))->where('expires_on', '>=', date('Y-m-d G:i:s'))->with('user')->first();
            if ($session !== null) {
                $user = (new User())->where('id', $session->user_id)->first();
                if ($user !== null) {
                    $request->merge(['user' => $user]);

                    return $next($request);
                }
            }
        }
}

Мой BroadcastServiceProvider код выглядит следующим образом:

class BroadcastServiceProvider extends ServiceProvider
{
    public function boot()
    {
        Broadcast::routes();

        require base_path('routes/channels.php');
    }
}

Если я поставлю Broadcast::routes(['middleware' => 'authcustom']); в BroadcastServiceProvider, boradcasting/auth даст код состояния 403, потому что $request->user() имеет значение null, что затем приводит к Access forbidden.

Я попытался выполнить поиск по всему проклятому вебу и ничего не нашел об изменении стандартного промежуточного программного обеспечения для вещания.

Я даже пытался удалить Broadcast::routes() и настроить новый маршрут /broadcast, который возвращал объект Pusher socket_auth, и каждый раз, когда я получал 419 Unkown код состояния.

Есть идеи или, может быть, вы можете указать мне направление, в котором я мог бы справиться? Спасибо!

Позже редактировать: Мое соединение JS Echo выглядит так:

Vue.use(VueEcho, {
    broadcaster: 'pusher',
    key: 'xxxxxxxxxxxxxx',
    cluster: 'eu',
    authEndpoint: 'http://localhost/api.easycargo.ro/public/broadcasting/auth',
    auth: {
        headers: {
            'x-session': this.auth.token
        }
    }
});

Ответы [ 2 ]

0 голосов
/ 11 сентября 2018

Я рад, что у вас что-то работает. Для более поздних читателей ниже приведен более лаверский способ решения проблемы, о которой идет речь: создайте настраиваемую защиту авторизации , используемую для аутентификации запросов для специальных маршрутов.

Laravel AuthManager включает вспомогательный метод & mdash; viaRequest() & mdash; упрощает создание Guard, который аутентифицирует пользователя с данными из контекста запроса без необходимости полной реализации Illuminate\Contracts\Auth\Guard. Мы можем связать нашу собственную защиту с помощью метода boot() в AuthServiceProvider.php :

public function boot()
{
    Auth::viaRequest('custom-auth', function ($request) {
        // Any custom user-lookup logic here. For example:
        if ($request->header('x-session')) {
            $user = // ...try to fetch a user...
            return $user;
        }
    });
}

Как мы видим, мы просто передаем закрытие методу viaRequest(), который возвращает объект User, если аутентификация прошла успешно, или null, если аутентификация не удалась.

Далее мы расскажем Laravel о нашей новой аутентификации, добавив запись в массив 'guards' в config / auth.php :

'guards' => [ 
    ...
    'broadcasting' => [
        'driver' => 'custom-auth', 
    ],
],

Наконец, нам нужно обновить промежуточное ПО для любых маршрутов, которые должны аутентифицировать пользователя, с помощью нашего пользовательского Guard. Мы можем использовать встроенное промежуточное программное обеспечение авторизации Laravel и указать, какую защиту применять в качестве параметра промежуточного программного обеспечения . Например, мы инициализируем широковещательные маршруты в вопросе BroadcastServiceProvider.php :

Broadcast::routes([ 'middleware' => [ 'auth:broadcasting', ... ] ]);

... где broadcasting соответствует имени, которое мы присвоили нашему пользовательскому Guard в config / auth.php .

Этот подход позволяет нам использовать все сервисы Laravel Auth, обеспечивает более центральное место для определения нашей логики аутентификации и упрощает автоматизированное тестирование, потому что мы можем легче моделировать аутентификацию по мере необходимости.

0 голосов
/ 10 сентября 2018

Мне действительно удалось найти решение, поэтому все, что мне нужно было сделать, - это связать $user, который я получил в моем собственном промежуточном программном обеспечении auth, с запросом, выполнив следующее:

$request->merge(['user' => $user]);

//add this
$request->setUserResolver(function () use ($user) {
   return $user;
});

и теперь $request->user(), который проверяет laravel, возвращает объект пользователя и проходит проверку.

...