Remember token laravel для чего

Обновлено: 07.07.2024

Аутентификация - это процесс регистрации и логина пользователей. Не путайте с авторизацией - проверкой прав уже залогиненного пользователя.

В Laravel сделать аутентификацию очень просто. Фактически, почти всё сконфигурировано для вас уже изначально. Конфигурационный файл аутентификации расположен в config/auth.php , он содержит несколько хорошо описанных опций для тонкой настройки поведения служб аутентификации.

По сути средства аутентификации Laravel состоят из "гвардов" и "провайдеров". Гварды определяют то, как именно аутентифицируются пользователи, для каждого запроса. Например, Laravel поставляется с гвардом session , который поддерживает состояние аутентифицированности с помощью хранилища сессий и кук.

Провайдеры определяют то, как именно пользователи извлекаются из вашей базы данных. Laravel поставляется с поддержкой извлечения пользователей с помощью Eloquent и конструктора запросов БД. Но при необходимости вы можете определить дополнительные провайдеры для своего приложения.

Не переживайте, если сейчас это звучит слишком запутанно! Для большинства приложений никогда не потребуется изменять стандартные настройки аутентификации.

Требования для базы данных

По умолчанию в Laravel есть модель Eloquent App\User в директории app . Эта модель может использоваться с базовым драйвером аутентификации Eloquent. Если ваше приложение не использует Eloquent, вы можете использовать драйвер аутентификации database , который использует конструктор запросов Laravel.

При создании схемы базы данных для модели App\User создайте столбец для паролей с длиной не менее 60 символов. Хорошим выбором будет длина 255 символов.

Кроме того, перед началом работы удостоверьтесь, что ваша таблица users (или эквивалентная) содержит строковый столбец remember_token на 100 символов. Этот столбец будет использоваться для хранения ключей сессий «запомнить меня», обрабатываемых вашим приложением.

События

Laravel генерирует различные события в процессе аутентификации. Вы можете прикрепить слушателей к этим событиям в вашем EventServiceProvider :

Ручная аутентификация пользователей

Конечно, совсем не обязательно использовать контроллеры аутентификации, включенные в Laravel. Если вы захотите убрать эти контроллеры, вам нужно будет напрямую управлять аутентификацией пользователей, используя классы аутентификации Laravel. Не волнуйтесь, они не кусаются!

Мы будем работать со службами аутентификации Laravel через фасад Auth , поэтому нам надо не забыть импортировать фасад Auth в начале класса. Далее давайте посмотрим на метод attempt :

Метод attempt принимает массив пар ключ/значение в качестве первого аргумента. Значения массива будут использованы для поиска пользователя в таблице базы данных. Так, в приведённом выше примере пользователь будет получен по значению столбца email . Если пользователь будет найден, хешированный пароль, сохранённый в базе данных, будет сравниваться с хешированным значением password , переданным в метод через массив. Если два хешированных пароля совпадут, то для пользователя будет запущена новая аутентифицированная сессия.

Метод attempt вернет true , если аутентификация прошла успешно. В противном случае будет возвращён false .

Метод intended "редиректора" перенаправит пользователя к тому URL, к которому он обращался до того, как был перехвачен фильтром аутентификации. В этот метод можно передать запасной URI, на случай недоступности требуемого пути.

Указание дополнительных условий

При необходимости вы можете добавить дополнительные условия к запросу аутентификации, помимо адреса e-mail и пароля. Например, можно проверить отметку "активности" пользователя:

В этих примерах email не является обязательным вариантом, он приведён только для примера. Вы можете использовать какой угодно столбец, соответствующий "username" в вашей базе данных.

Обращение к конкретным экземплярам гварда

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

Передаваемое в метод guard имя гварда должно соответствовать одному из защитников, настроенных в конфиге auth.php :

Завершение сессии

Для завершения сессии пользователя можно использовать метод logout фасада Auth . Он очистит информацию об аутентификации в сессии пользователя:

Запоминание пользователей

Если вы хотите обеспечить функциональность "запомнить меня" в вашем приложении, вы можете передать логическое значение как второй параметр методу attempt , который сохранит пользователя аутентифицированным на неопределённое время, или пока он вручную не выйдет из системы. Конечно, ваша таблица users должна содержать строковый столбец remember_token , который будет использоваться для хранения токенов "запомнить меня".

Если вы используете встроенный в Laravel LoginController , логика "запоминания" пользователей уже реализована трейтами, используемыми контроллером.

Если вы "запоминаете" пользователей, то можете использовать метод viaRemember , чтобы определить, аутентифицировался ли пользователь, используя cookie "запомнить меня":

Другие методы аутентификации

Аутентификация экземпляра пользователя

Если вам необходимо "залогинить" в приложение существующий экземпляр пользователя, вызовите метод login с экземпляром пользователя. Данный объект должен быть реализацией контракта Illuminate\Contracts\Auth\Authenticatable . Конечно, встроенная в Laravel модель App\User реализует этот интерфейс:

Конечно, вы можете указать, какой экземпляр гварда надо использовать:

Аутентификация пользователя по ID

Для входа пользователя в приложение по его ID, используйте метод loginUsingId . Этот метод просто принимает первичный ключ пользователя, которого необходимо аутентифицировать:

Однократная аутентификация пользователя

Когда посредник прикреплён к роуту, вы автоматически получите запрос данных для входа при обращении к роуту через браузер. По умолчанию посредник auth.basic будет использовать столбец email из записи пользователя в качестве "username".

Замечание по FastCGI

Драйвера аутентификации

Laravel из коробки предлагает для аутентификации драйвера database и eloquent . Чтобы узнать больше о том, как добавлять свои драйвера, изучите документацию по расширению системы аутентификации.

Добавление собственных провайдеров пользователей

Если вы не используете традиционную реляционную базу данных для хранения ваших пользователей, вам необходимо добавить в Laravel свой собственный провайдер аутентификации пользователей. Мы используем метод provider фасада Auth для определения своего провайдера:

После регистрации провайдера методом provider , вы можете переключиться на новый провайдер в файле настроек auth.php . Сначала определите провайдера provider , который использует ваш новый драйвер:

Затем вы можете использовать этот провайдер в вашей настройке guards :

Контракт User Provider

Реализации Illuminate\Contracts\Auth\UserProvider отвечают только за извлечение реализаций Illuminate\Contracts\Auth\Authenticatable из постоянных систем хранения, таких как MySQL, Riak, и т.п. Эти два интерфейса позволяют механизмам аутентификации Laravel продолжать функционировать независимо от того, как хранятся данные пользователей и какой тип класса использован для их представления.

Давайте взглянем на контракт Illuminate\Contracts\Auth\UserProvider :

Функция retrieveById обычно принимает ключ, отображающий пользователя, такой как автоинкрементный ID из базы данных MySQL. Реализация Authenticatable , соответствующая этому ID, должна быть получена и возвращена этим методом.

Функция retrieveByToken принимает пользователя по его уникальному $identifier и ключу $token "запомнить меня", хранящемуся в поле remember_token . Как и предыдущий метод, он должен возвращать реализацию Authenticatable .

Метод updateRememberToken обновляет поле remember_token пользователя $user значением нового $token .

Метод retrieveByCredentials принимает массив авторизационных данных, переданных в метод Auth::attempt при попытке входа в приложение. Затем метод должен "запросить" у основного постоянного хранилища того пользователя, который соответствует этим авторизационным данным. Обычно этот метод выполняет запрос с условием "where" для $credentials['username'] . Затем метод должен вернуть реализацию Authenticatable . Этот метод не должен пытаться проверить пароль или аутентифицировать пользователя.

Метод validateCredentials должен сравнить данного $user с $credentials для аутентификации пользователя. Например, этот метод может сравнить строку $user->getAuthPassword() с Hash::check для сравнения значения $credentials['password'] . Этот метод должен возвращать true или false , указывая верен ли пароль.

Контракт Authenticatable

Теперь, когда мы изучили каждый метод в UserProvider , давайте посмотрим на контракт Authenticatable . Помните, провайдер должен вернуть реализацию этого интерфейса из методов retrieveById , retrieveByToken , и retrieveByCredentials :

Этот интерфейс довольно прост. Метод getAuthIdentifierName должен возвращать имя поля "первичного ключа» пользователя", а метод getAuthIdentifier - "первичный ключ" пользователя. При использовании MySQL это будет автоинкрементный первичный ключ. Метод getAuthPassword должен возвращать хешированный пароль пользователя. Этот интерфейс позволяет системе аутентификации работать с классом User, независимо от используемой ORM и уровня абстракции хранилища. По умолчанию Laravel содержит в директории app класс User , который реализует этот интерфейс. Вы можете подсмотреть в нём пример реализации.

Session guard или token guard для SPA?

1. юзер заходит через обычную форму входа и получает сессию
2. пока сессия есть на страницу выдается токен в виде метатега
3. работает с апи с помощью этого токена
итого апи токен не хранится на клиенте, но работа идет с апи все равно. гибридный вариант получается.

ну а если чисто через апи работать, то да хранить токен в браузере иначе придется при перезагрузке страницы логиниться каждый раз.

Александр Аксентьев, Почитал ваш ответ и посмотрел на исходники гвардов. То есть, как я понял, алгоритм аутентификации обоих гвардов такой:
сессия
1. получаем id сессии с клиента,
2. получаем id пользователя из сессии и загружаем его по этому id из базы. Если сессия умерла, то загружаем по remember_token (если есть).
токен
1. просто сверяем переданный токен с полем api_token таблицы users и загружаем юзера. Не совпало? Логинься заново, получай новый, который запишется в эту таблицу.
--------------------------------------------------

То есть по факту, если хранить токен на клиенте, получаем одно и тоже поведение, просто без лишней прослойки в виде самой сессии? Разница чисто идеологическая.

Меня смутило, что по умолчанию для обычных запросов в ларе используется один способ, а для rest - второй. Ведь в паре они точно работать не будут нормально! Авторизировавшись через веб, rest запрос попросит ещё раз, но через токен. В принципе, раз у меня SPA, то я могу отказаться от web-гварда и остановиться только на токенах.

то есть, как я понял, алгоритм аутентификации обоих гвардов такой:

Меня смутило, что по умолчанию для обычных запросов в ларе используется один способ, а для rest - второй.

l4m3r, а в целом никто не запрещает закинуть мидлварь сессии на группу api роутов или просто вынести в глобальный список мидлварей и сессии будут работать на апи и на вебе и не надо запариваться с апитокенами.
но это такое себе конечно. Александр Аксентьев, у меня последний вопрос. Зачем вообще может понадобиться иметь несколько гвардов? В документации написано, что в конфиге можно добавлять свои: например admin. Например, два session гварда с разным названием. В чем практическая польза? l4m3r, Мне кажется у вас обычное RPC апи, а не REST, и важно ли вам чтобы оно было stateless обычно должно обсуждаться отдельно (спойлер: 99% что в вашем случае, как и в большинстве, неважно)
P.s. Раз уж я уже влез: не бывает понятия "REST запрос", это звучит так же абсурдно как какой-нибудь "MVC запрос" или "SPA запрос"

l4m3r, SPA это и есть отправление на сервер команды/запроса и получение ответа в заранее определенном формате
Никаких особых правил нет, если мы говорим просто о протоколе RPC, а не о какой-нибудь более подробной спецификации как, например, JSON-RPC. Просто так следовать этим спецификациям смысла нет. Главное требование к АПИ - чтобы им было удобно пользоваться тем, кто им собирается пользоваться.

REST предполагает довольно жесткие ограничения для обеспечения некоторых принципов описанных в диссертации. Один из них - scalability.
В народе есть довольно странная мода, называть "API" только взаимодействие через RPC. То, как работает браузер с серверами сайтов - тоже API. Это сейчас мы используя JS можем расширять возможности браузеров до огромных масштабов, и делать из них RPC клиентов.

REST предполагает что клиент ничего не знает о сервере кроме одной точки входа(ограничение "Starting with null style из диссертации"), и не знает куда слать запросы, REST клиент лишь умеет отображать какой-то стандартный заранее обговоренный набор форматов, как браузеры умеют отображать (ограничение "Uniform interface", хотя его понять сильно сложнее) html, jpg и т.п.

Так вот, то как работал Веб до того как из браузеров стали с помощью JS делать полноценные приложения и можно назвать примерами взаимодействия по REST API, в описании ограничения "Uniform interface" есть подпункт HATEOAS (Hypertext as the engine of application state). Суть в том что переходы состояния клиента полностью контроллируются со стороны сервера, и в примере с Web`ом всё довольно просто - переходы состояния клиента контроллируются через теги <a> и <form> . Вобщем, количество сайтов в интернете росло и растет стремительно, а никаких изменений в наш клиент(браузер), чтобы они работали вносить нет необходимости, миллионы сайтов мы посещаем используя один и тот же клиент, потому что у них единый "Uniform interface".

Вобщем, сумбурно описал, я хотел лишь сказать что нет смысла пытаться соблюдать какие-то ограничения только за то что они есть в REST, если для вашего приложения нет потребности в этих ограничениях. SPA приложения, или там, АПИ для мобилки это по сути всегда RPC, нет нужды пытаться назвать его по другому. Создавать свой REST клиент(по сути новый браузер) это долго, дорого, и для обычного приложения никогда не окупится )

Да самый простой веб сайтик без JS-а)
Там будет и "Starting with null style", и "Client-server", и "Caching", и "Uniform interface". Единственное что, проблемы со stateless из-за сессий, и есть ли там " Layered System" мы на клиенте не узнаем )

Сброс забытого пароля

Модель и таблица

Восстановление забытого пароля - очень распространенная вещь в веб-приложениях. Чтобы не заставлять вас писать его вновь и вновь, Laravel предоставляет встроенные удобные методы для совершения подобных операций. Для начала убедитесь, что ваша модель User реализует (implements) интерфейс Illuminate\Auth\Reminders\RemindableInterface . Модель User , которая идет с фреймворком, уже реализует его - она включает в себя Illuminate\Auth\Reminders\RemindableTrait с методами, которые реализуют этот интерфейс.

Реализация RemindableInterface

Создание таблицы токенов сброса пароля

Далее, должна быть создана таблица для хранения токенов запросов сброса пароля. Для создания такой таблицы существует artisan-команда auth:reminders-table .

Контроллер восстановления пароля

Чтобы автоматически создать контроллер восстановления пароля, воспользуйтесь командой auth:reminders-controller . В папке controllers будет создан RemindersController.php :

Созданный контроллер содержит метод getRemind , который показывает форму для напоминания пароля. Вам надо создать эту форму во вьюхе password.remind (файл remind.blade.php в папке views/password - см. view). Форма должна отправлять POST c email на метод postRemind

Простейший пример password.remind :

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

Пользователь получит письмо со ссылкой на метод getReset , с токеном для индентификации пользователя. Этот метод вызывает вьюху password.reset (файл reset.blade.php в папке views/password ), в которой должна быть форма для смены пароля, со скрытым полем token и полями email , password , and password_confirmation , например такая:

Метод postReset производит замену паролей в вашем сторадже. По умолчанию считается, что пользователи хранятся в БД, с которой умеет работать Eloquent - ожидается $user, который передается в функцию-замыкание имеет метод save . Если это не так, измените функцию-замыкание в аргументе Password::reset в контроллере RemindersController исходя из вашей архитектуры приложения.

Если смена пароля прошла удачно, пользователь редиректится на главную страницу вашего приложения (вы можете изменить URL редиректа, если хотите). Если нет - пользователь редиректится обратно с установкой flash-переменной error .

Валидация паролей

По умолчанию Password::reset валидирует пароль пользователя исходя из двух правил - введенные пароли должны совпадать и пароль должен быть больше или равен 6 символам. Если вы хотите расширить валидацию паролей, вы можете определить свой Password::validator :

Примечание Токены сброса пароля валидны в течении одного часа. Вы можете изменить это в app/config/auth.php , параметр reminder.expire .

Добавление собственных провайдеров пользователей

Затем вы можете использовать этот провайдер в вашей настройке guards :

Контракт User Provider

Давайте взглянем на контракт Illuminate\Contracts\Auth\UserProvider :

Метод updateRememberToken обновляет поле remember_token пользователя $user значением нового $token . Новый ключ может быть как свежим ключом, назначенным при успешной попытке входа "запомнить меня", так и нулевым при выходе пользователя.

Контракт Authenticatable

Добавление собственных гвардов

Вы можете определить собственные гварды аутентификации, используя метод extend фасада Auth . Вы должны поместить этот вызов extend внутри сервис-провайдера. Так как в состав Laravel уже входит AuthServiceProvider , можно поместить данный код в провайдер:

Как видите, в этом примере переданная в метод extend анонимная функция должна вернуть реализацию Illuminate\Contracts\Auth\Guard . Этот интерфейс содержит несколько методов, которые вам надо реализовать, для определения собственного гварда. Когда вы определили своего гварда, вы можете использовать его в настройке guards своего конфига auth.php :

Гварды в виде анонимных функций

Функционалом аутентификации можно воспользоваться без создания классов гвардов, при помощи анонимной функции в Auth::viaRequest .

Вот пример аутентификации по токену, который передан в запросе:

Чтобы сообщить приложению, что аутентификацию нужно проводить при помощи драйвера, указанного в viaRequest , укажите его имя в конфиге auth.php в секции guards :

Хранение паролей

Класс Hash содержит методы для безопасного хэширования с помощью Bcrypt.

Хэширование пароля по алгоритму Bcrypt:

Проверка пароля по хэшу:

Проверка на необходимость перехэширования пароля:

Безопасность

Laravel стремится сделать реализацию авторизации максимально простой. Фактически, после установки фреймворка почти всё уже настроено. Настройки хранятся в файле app/config/auth.php , который содержит несколько хорошо документированных параметров для настройки поведения методов аутентификации.

"Из коробки" приложение Laravel включает в себя модель User в папке app/models , которая может использоваться вместе с дефолтным драйвером аутентификации Eloquent. При создании таблицы для данной модели убедитесь, что поле пароля принимает как минимум 60 символов.

Если ваше приложение не использует Eloquent, вы можете использовать драйвер database , который использует конструктор запросов Laravel.

Примечание: Перед тем как начать, пожалуйста, убедитесь, что таблица users (или другая, в которой хранятся пользователи) содержит nullable (с возможностью содержать NULL) столбец remember_token длиною 100 символов (VARCHAR(100)). Этот столбец испольдуется для хранения токена, когда пользователь при логине ставит галку "запомнить меня".

Краткое руководство по аутентификации

Роутинг

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

Эту команду надо использовать на свежем приложении, она установит шаблоны для регистрации и входа, а также роуты для всех конечных точек аутентификации. Также будет сгенерирован HomeController , который обслуживает запросы к панели настроек вашего приложения после входа. Но вы можете изменить или даже удалить это контроллер, если это необходимо для вашего приложения.

Шаблоны

Как было упомянуто в предыдущем разделе, команда php artisan make:auth создаст все необходимые вам шаблоны для аутентификации и поместит их в директорию resources/views/auth .

Команда make:auth также создаст директорию resources/views/layouts , содержащую основной макет для вашего приложения. Все эти макеты используют CSS-фреймворк Bootstrap, но вы можете изменять их как угодно.

Аутентификация

Теперь, когда у вас есть роуты и шаблоны для имеющихся контроллеров аутентификации, вы готовы регистрировать и аутентифицировать новых пользователей своего приложения! Вы можете просто перейти по этим роутам в браузере. Контроллеры аутентификации уже содержат логику (благодаря их типажам) для аутентификации существующих пользователей и сохранения новых пользователей в базе данных.

Изменение пути

Когда пользователь успешно аутентифицируется, он будет перенаправлен на URI /home . Вы можете изменить место для перенаправления после входа, задав свойство redirectTo контроллеров LoginController , RegisterController и ResetPasswordController :

Если для пути перенаправления требуется собственная логика генерации, можно задать метод redirectTo вместо свойства redirectTo :

Метод redirectTo имеет приоритет над атрибутом redirectTo .

Настройка имени пользователя

По умолчанию для аутентификации Laravel использует поле email . Если вы хотите это изменить, то можете определить метод username в своем LoginController :

Настройка гварда

Вы также можете изменить "гварда", который используется для аутентификации и регистрации пользователей. Для начала задайте метод guard в LoginController , RegisterController и ResetPasswordController . Метод должен возвращать экземпляр гварда:

Настройка валидации / хранения

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

Метод validator класса RegisterController содержит правила проверки ввода данных для новых пользователей приложения.

Метод create класса RegisterController отвечает за создание новых записей App\User в вашей базе данных с помощью Eloquent ORM. Вы можете изменить каждый из этих методов, как пожелаете.

Получение аутентифицированного пользователя

Вы можете обращаться к аутентифицированному пользователю через фасад Auth :

Определение, аутентифицирован ли пользователь

Чтобы определить, что пользователь уже вошёл в ваше приложение, вы можете использовать метод check фасада Auth , который вернёт true , если пользователь аутентифицирован:

Хотя и возможно определить аутентифицирован ли пользователь, используя метод check , обычно вы будете использовать посредников для проверки был ли пользователь аутентифицирован ранее, позволяя этому пользователю получать доступ к определенным роутам / контроллерам. Для получения дополнительной информации смотрите документацию о защите роутов.

Защита роутов

Конечно, если вы используете контроллеры, вы можете вызвать метод middleware из конструктора контроллера, вместо присоединения его напрямую к определению роута:

Указание гварда

Во время прикрепления посредника auth к роуту, вы можете также указать, какой гвард должен быть использован для выполнения аутентификации. Указанный гвард должен соответствовать одному из ключей в массиве guards вашего конфига auth.php :

Троттлинг аутентификации (ограничение числа неудачных попыток входа)

Если вы используете встроенный в Laravel класс LoginController , трейт Illuminate\Foundation\Auth\ThrottlesLogins уже будет включён в ваш контроллер. По умолчанию пользователь не сможет войти в приложение в течение одной минуты, если он несколько раз указал неправильные данные для входа. Ограничение происходит отдельно для имени пользователя/адреса e-mail и его IP-адреса.

Завершение сессии

Чтобы разлогинить пользователя используйте метод logout фасада Auth . Он очистит информацию об аутентификации в сессии пользователя:

Инвалидация сессий на других устройствах

В Laravel есть механизм для завершении сессии на других устройствах (браузерах), оставляя сессию на данном устройстве активной. Например, это требуется когда пользователь изменяет свой пароль.

Теперь вы можете использовать метод logoutOtherDevices фасада Auth . В качестве аргумента он принимает текущий пароль пользователя.

При вызове метода logoutOtherDevices все сессии пользователя кроме текущей будут инвалидированы, что означает, что пользователь будет "разлогинен" во всех гвардах, в которых он был ранее аутентифицирован.

Аутентификация и роутинг

Вы можете использовать Фильтры роутов, чтобы позволишь только залогиненным пользователям обращаться к заданному роуту или группе роутов. Изначально Laravel содержит фильтр auth , который содержится в файле app/filters.php .

Защита роута аутентификацией

Защита от подделки запросов (CSRF)

Laravel предоставляет простой способ защиты вашего приложения от подделки межсайтовых запросов (cross-site request forgeries, CSRF).

Вставка CSRF-ключа в форму

Проверка переданного CSRF-ключа

По умолчанию, фильтр basic будет использовать поле email модели объекта при аутентификации. Если вы хотите использовать иное поле, можно передать его имя первым параметром методу basic в файле app/filters.php :

Авторизация без запоминания состояния

Аутентификация пользователей

Для аутентификации пользователя в вашем приложении вы можете использовать метод Auth::attempt .

Заметьте, что поле email не обязательно и оно используется только для примера. Вы должны использовать любое поле, которое соответствует имени пользователя в вашей БД. Метод Redirect::intended отправит пользователя на URL, который он пытался просмотреть до того, как запрос был перехвачен фильтром аутентификации. Также в этом методе можно задать дополнительный URL, куда будет осуществлен переход, если первый URL не доступен.

Когда вызывается метод attempt , запускается событие auth.attempt . При успешной авторизации также запускается событие auth.login .

Проверка авторизации пользователя

Для определения того, авторизован ли пользователь или нет, можно использовать метод check .

Если вы хотите предоставить функциональность типа "запомнить меня", то вы можете передать true вторым параметром к методу attempt , который будет поддерживать авторизацию пользователя без ограничения по времени (пока он вручную не выйдет из системы). В такоем случае у вашей таблицы users должен быть строковой столбец remember_token для хранения токена пользователя.

Примечание: если метод attempt вернул true , то пользователь успешно вошёл в систему.

Имеет ли пользователь токен "запомнить меня"

Метод viaRemember позволяет узнать, вошел ли пользователь при помощи фичи "запомнить меня".

Авторизация пользователя с использованием условий

Вы также можете передать дополнительные условия для запроса к таблице:

Примечание Для повышения безопасности после аутентификации фреймворк регенерирует ID сессии пользователя.

Доступ к залогиненному пользователю

Как только пользователь аутентифицирован, вы можете обращаться к модели User и её свойствам.

Чтобы получить ID залогиненого пользователя, воспользуйтесь методом id :

Для простой аутентификации пользователя по ID используется метод loginUsingId :

Проверка данных для входа без авторизации

Метод validate позволяет вам проверить данные для входа без осуществления самого входа.

Аутентификация пользователя на один запрос

Выход пользователя из приложения

Шифрование

Laravel предоставляет функции устойчивого шифрования по алгоритму AES с помощью расширения mcrypt для PHP.

Шифрование строки

Примечание: обязательно установите 16, 24 или 32-значный ключ key в файле app/config/app.php . Если этого не сделать, зашифрованные строки не будут достаточно надежными.

Расшифровка строки

Изменение режима и алгоритма шифрования

Вы также можете установить свой алгоритм и режим шифрования:

События

Добавление собственных гвардов

Вы можете определить собственные гварды аутентификации, используя метод extend фасада Auth . Вы должны поместить этот вызов provider внутри сервис-провайдера. Так как в состав Laravel уже входит AuthServiceProvider , можно поместить данный код в провайдер:

Аутентификация

В Laravel сделать аутентификацию очень просто. Фактически, почти всё сконфигурировано для вас уже изначально. Конфигурационный файл аутентификации расположен в config/auth.php , который содержит несколько хорошо описанных опций для тонкой настройки поведения служб аутентификации.

Требования для базы данных

Ручная авторизация

Если вам нужно войти существующим пользователем, просто передайте его модель в метод login :

Это эквивалентно аутентификации пользователя через его данные методом attempt .

Краткое руководство по аутентификации

Роутинг

Laravel обеспечивает быстрый способ создания заготовок всех необходимых для аутентификации роутов и шаблонов при помощи пакета laravel/ui :

Эту команду надо использовать на свежем приложении, она установит шаблоны для регистрации и логина, а также роуты, требуемые для системы аутентификации. Также будет сгенерирован HomeController , на коорый будет сделан редирект залогиненного пользователя. Но вы можете изменить или даже удалить это контроллер, если это необходимо для вашего приложения.

Если вы хотите запретить регистрацию, удалите контроллер RegisterController , который также делает эта команда, и измените роуты аутентификации: Auth::routes(['register' => false]); .

Создание системы аутентификации вместе с созданием приложения

На этапе создания приложения вы можете указать флаг --auth и инсталлятор сразу добавит систему аутентификации:

Шаблоны

Как было упомянуто в предыдущем разделе, команда php artisan ui vue --auth из пакета laravel/ui создаст все необходимые вам шаблоны для аутентификации и поместит их в директорию resources/views/auth .

Команда ui также создаст директорию resources/views/layouts , содержащую основной макет для вашего приложения. Все эти макеты используют CSS-фреймворк Bootstrap, но вы можете изменять их как угодно.

Аутентификация

Изменение пути

Когда пользователь успешно аутентифицируется, он будет перенаправлен на URI /home . Вы можете изменить место для перенаправления после входа, задав константу HOME в сервис-провайдере RouteServiceProvider :

Если вам нужна более гибкая настройка ответа, возвращаемого при аутентификации пользователя, Laravel предоставляет пустой метод authenticated(Request $request, $user) , который, при желании, может быть переопределен:

Настройка имени пользователя

Настройка гварда

Настройка валидации / хранения

Метод validator класса RegisterController содержит правила проверки ввода данных для новых пользователей приложения.

Получение аутентифицированного пользователя

Вы можете обращаться к аутентифицированному пользователю через фасад Auth :

Определение, аутентифицирован ли пользователь

Хотя и возможно определить аутентифицирован ли пользователь, используя метод check , обычно вы будете использовать посредников для проверки был ли пользователь аутентифицирован ранее, позволяя этому пользователю получать доступ к определенным роутам / контроллерам. Для получения дополнительной информации смотрите документацию о защите роутов.

Защита роутов

Вы также можете вызвать метод middleware из конструктора контроллера, вместо присоединения его напрямую к определению роута:

Обработка неаутентифицированных пользователей

Указание гварда

Защита повторным вводом пароля

Особо важные места сайта (изменение критичных настроек - например, платёжной информации) можно защитить путём повторного запроса пароля у пользователя.

Для этого защитите роут или группу роутов посредником password.confirm . При заходе на этот урл будет произведён редирект на промежуточную страницу с формой ввода пароля.

После успешного ввода пароля произойдёт редирект на защищаемый роут. При повтором входе на этот роут пароль не будет спрашиваться в течении трёх часов. Вы можете изменить это время путём редактирования опции auth.password_timeout в конфиге.

Троттлинг аутентификации (ограничение числа неудачных попыток входа)

Аутентификация пользователей вручную

Вы можете написать свои контроллеры аутентификации пользователей, не пользоваться теми, что генерирует фреймворк, если по какой-то причине они вас не устраивают. Для этого вам нужно использовать в своих контроллерах классы аутентификации Laravel. Не волнуйтесь, это просто.

Метод attempt принимает массив пар ключ/значение в качестве первого аргумента. Значения массива будут использованы для поиска пользователя в таблице базы данных. Так, в приведённом выше примере пользователь будет получен по значению столбца email . Если пользователь будет найден, хешированный пароль, сохранённый в базе данных, будет сравниваться с хешированным значением password , переданным в метод через массив. Вы не должны хешировать пароль, указанный в качестве значения password , поскольку фреймворк автоматически хеширует значение, прежде чем сравнивать его с хешированным паролем в базе данных. Если два хешированных пароля совпадут, то для пользователя будет запущена новая аутентифицированная сессия.

Метод attempt вернет true , если аутентификация прошла успешно. В противном случае будет возвращён false .

Указание дополнительных условий

В этих примерах email не является обязательным вариантом, он приведён только для примера. Вы можете использовать какой угодно столбец, соответствующий "username" в вашей базе данных.

Обращение к конкретным экземплярам гварда

Передаваемое в метод guard имя гварда должно соответствовать одному из защитников, настроенных в конфиге auth.php :

Завершение сессии

Запоминание пользователей

Если вы хотите обеспечить функциональность "запомнить меня" в вашем приложении, вы можете передать логическое значение как второй параметр методу attempt , который сохранит пользователя аутентифицированным на неопределённое время, или пока он вручную не выйдет из системы. Ваша таблица users должна содержать строковый столбец remember_token , который будет использоваться для хранения токенов "запомнить меня".

Если вы используете встроенный в Laravel LoginController , логика "запоминания" пользователей уже реализована трейтами, используемыми контроллером.

Другие методы аутентификации

Аутентификация экземпляра пользователя

Конечно, вы можете указать, какой экземпляр гварда надо использовать:

Аутентификация пользователя по ID

Однократная аутентификация пользователя

Замечание по FastCGI

Читайте также: