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

Делаю авторизацию для сайта.
Почитав пару статей, пришел к выводу, что надо делать все в такой последовательности:
1.Проверка определенной сессии, если она существует, даем доступ
2. Если сессии не существует, то проверяем куки, если нужные куки есть, то создаем нужную сессию и переходим к шагу 1.
3. Если куки не существует, то просим ввести логин, пароль, после чего создаем сессию и переходим к шагу 1, если ставим галочку "запомнить меня" , то создаем нужные куки и переходим к шагу 2.
Вопросов очень много. От "какие данные хранить в сесиях, куках от куда их брать и тп.
  • Вопрос задан
  • 903 просмотра
Пригласить эксперта
Ответы на вопрос 5
@Yan-s
Если нужна реализация: ставьте готовое решение.
Если интересно разобраться как правильно: берете готовое решение, смотрите как оно работает.
Ответ написан
Arris
@Arris
Сапиенсы учатся, играя.
https://github.com/PHPAuth/PHPAuth

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

Если требуется распределенный масштабируемый сервис, то все становится сложнее. Например, у нас реализована вот такая схема.
Ответ написан
Комментировать
Stalker_RED
@Stalker_RED
Лучше не экспериментируйте с безопасностью, если не понимаете как это работает.

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

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы