Как лучше всего сделать авторизацию на сайте?

Question

[mrWan]

Делаю авторизацию для сайта.
Почитав пару статей, пришел к выводу, что надо делать все в такой последовательности:
1.Проверка определенной сессии, если она существует, даем доступ
2. Если сессии не существует, то проверяем куки, если нужные куки есть, то создаем нужную сессию и переходим к шагу 1.
3. Если куки не существует, то просим ввести логин, пароль, после чего создаем сессию и переходим к шагу 1, если ставим галочку "запомнить меня" , то создаем нужные куки и переходим к шагу 2.
Вопросов очень много. От "какие данные хранить в сесиях, куках от куда их брать и тп.

Comments

[Sergej]

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

[xmoonlight]

SharkMan, месяц и англо-язычный запрос - The BEST!

[FanatPHP]

Странный вопрос. "Вопросов очень много" и дальше полтора вопроса.
Если хочешь получить конкретный ответ, то задай конкретный вопрос.

[devalone]

а ещё есть jwt :)

Answer 1

[Yan-s]

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

Comments

[mrWan]

Да, интересно как работает, думаю так и сделаю, возьму готовое решение и буду смотреть как оно работает

Answer 2

[Arris]

https://github.com/PHPAuth/PHPAuth

Рекомендую.

Answer 3

[FanatPHP]

В сессии хранится минимально id юзера.
В куке уникальное значение, uuid например (разумеется каждый раз генерируется заново) + он же кладется в базу для проверки.

Comments

[mrWan]

Да, где-то читал об этом, что в таблице создаётся отдельное поле с уникальным ключом, который ложиться в куки, и после каждой авторизации этот ключ обновляется, но как быть если у меня доступ через куки с двух-трех компов?отдельная таблица для уникальных ключей, привязанная к таблице с юзерами ?

Answer 4

[Владимир Дубровин]

Если это простой, нерспределенный сайт для которого не планируется больших нагрузок и масштабирования, то обычно после ввода логина/пароля проставляется сессионная кука (с флагом HTTPOnly). При всех запросах проверяется валидность куки. Возможно:
1. Использовать стандартные сессии/сессионные куки PHP, при аутентификации по логину и паролю проставлять для сессии флаг авторизации и id пользователя. Самый простой и распространенный способ.
2. Выставлять свою куку и проверять куки на валидность по базе на каждом запросе. Плюсы - возможность создавать persitent-сессии, легко завершить сеанс - сессия инвалидируется в базе. Минусы - обращение к базе на каждом запросе.
3. Выдавать куки с подписью сервера, проверять подпись на запросах без обращения к базе. Минус - нельзя инвалидировать куки на стороне сервера.
4. Использовать сессионную куку, которую выдавать за логин и пароль и хранить в базе + access-куку, которую выдавать по сессионной куке и подписывать, в access-куку включать timestamp чтобы она быстро устаревала, при устаревании - проверять сессионную куку по базе и проставлять новую access-куку. Так не надо лазить в базу на каждом запросе, только когда протухает access-кука.

Если требуется распределенный масштабируемый сервис, то все становится сложнее. Например, у нас реализована вот такая схема.

Answer 5

[Stalker_RED]

Лучше не экспериментируйте с безопасностью, если не понимаете как это работает.

Берете стандартную сессию, проверяете есть ли там user_id
Если нет - показывайте форму ввода логин/пароль
Если пользователь ввел правильный пароль - пишете в сеcсию user_id
Всё.

При использовании стандартных сессий куки будут выставлены автоматически, можно о них не думать. (Разве что проверить, стоит ли в настройках "session.cookie_httponly on").
В базу никакие токены не нужно писать, пока вы не понимаете зачем оно вам.