Laravel 5.7 - Как использовать Auth :: check (), даже если не используется промежуточное ПО для аутентификации - PullRequest
0 голосов
/ 15 декабря 2018

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

Я застрял наиспользуя Auth :: check ().

Функция контроллера выглядит примерно так:

class SomeController extends Controller
{
    public function check(Request $request) {
        if(Auth::check()) {
            return response()->json([
                        'message' => 'Logged in'
                    ], 200);
        }
        else {
            return response()->json([
                        'message' => 'Not logged in'
                    ], 200);
        }
    }
}

У меня два сценария:

Сценарий 1

Route::get('scenario1', 'SomeController@check');

В этом сценарии в контроллере, когда я проверяю Auth :: check () внутри условия if, я всегда получаю ложное условие, независимо от того, является ли пользовательаутентифицировано или нет.

Сценарий 2

Route::get('scenario2', 'SomeController@check')->middleware('auth:api');

В этом сценарии в контроллере, когда я проверяю Auth :: check (), я получаю значение true, когда пользователь вошел в системуи ошибка (маршрут [логин] не определен), когда пользователь не вошел в систему.

Ответы [ 2 ]

0 голосов
/ 17 декабря 2018

Чтобы ответить на ваш прямой вопрос

Как использовать Auth :: check (), даже если не используется промежуточное программное обеспечение для аутентификации

Вы просто используете Auth::check().Промежуточное программное обеспечение Auth не означает, что у вас всегда есть доступ к классу Auth, это означает, что пользователь должен пройти проверку подлинности для посещения / использования определенного маршрута.

Если у вас было промежуточное программное обеспечение авторизации на маршруте, то сделал Auth::check в методе контроллера, который обрабатывал этот маршрут, это всегда было так, потому что промежуточное ПО не позволяло ни одному не прошедшему проверку подлинности пользователю достигать этой точки.

РЕДАКТИРОВАТЬ - Вам, возможно, потребуется использовать группу веб-промежуточного программного обеспечения.

0 голосов
/ 15 декабря 2018

Что касается сценария 2, прочитайте Защита маршрутов (и следующий подраздел «Перенаправление неаутентифицированных пользователей»).

При подключении промежуточного программного обеспечения auth к маршруту, если пользователь нене прошедший проверку подлинности, он перенаправляется на маршрут с именем login, который вы не реализовали в своем приложении.


Но я не понял, почему кажется, что auth работает в вашем сценарии 2но не в вашем сценарии 1…

...