Хотелось бы узнать, какой подход при разработке авторизации используете Вы?
Дело в том, что большинство статей, которые рассказывают - "авторизацию нужно делать так", упускают очень важный факт - они игнорируют то, что пользователь использует несколько гаджетов/браузеров для интернет серфинга.
Основная модель - это генерировать хеш при удачной авторизации, и хранить его в куках и БД.
user_id + user_hash это круто. Но, в случае новой авторизации на другом устройстве - хеш в БД обновляется - и предыдущая сессия вылетает.
user_session:
user_id
token
ip
.. еще что душе угодно (агент, дата старта и т.п.)
В куках храните token, по нему же и ищите юзера в user_session
При успешной авторизации создаете запись в user_session, с указанием токена.
Токен вешаете клиенту.
Можно реализовать также привязку к IP (подсети), дабы снизить риск кражи сессии.
Я бы предложил их не трогать :) Имхо, если предположить что куки стирает 2% юзеров, то это всего лишь 2% неактуальных записей.
Если у вас не Over 9000+ логинов в день, то не стоит парится. Больше будете писать код :)
Ну, а если очень хочется, то
Delete from user_session where last_active < NOW() - interval X days
не ну как удалить я знаю, я вот думал может их чистить в какой то определенный момент, например когда юзер авторизуется или еще когда, но вдруг пользователь авторизовался год назад, и тут он разлогинется, а пароль не помнит, и есть возможность потерять пользователя.
Их чистить вообще не надо, т.к. это не стогигабайтные таблицы (в 99% случаев), и юзер может заюзать старую сессию даже через полгода, и если он оказался авторизован - то карма плюс вашему проекту.
Когда юзер авторизуется - это не факт, что он не войдет по старой сессии (ноут, телефон, планшет). Посему, чистить ничего ненадо.
На самом деле, Вы думаете о проблемах, которых у Вас еще нет.
Когда поиск по таблице хешей будет тормозить, тогда и задайтесь вопросом - как их чистить. А до тех пор - преждевременная оптимизация.
Может подход тоже норм, но все можно сделать проще, главное понять по какому критерию удалять не нужную запись, кроме даты конечно же. Например пользователь авторизуется а в БД есть две сессии, одна из них это авторизация на планшете, другая не нужная, и перед тем как создать третью мы удаляем второю, или же не удаляем а принимаем ее как свободную, но как определить что она свободная никем не используемая сессия )
Я просто хотел сказать, что определять авторизацию только по кукам не безопасно. Допустим я авторизуюсь, мне выставляется кука с хэшем из БД, так же второй пользователь (злоумышленник) не введя логина и пароля просто подставляет мою куку и уже авторизован, то есть ему даже мой логин с паролем не нужен. Ну а если при запросе сверять не только хэш из кук но еще и ip и еще чего, то уже одной кукай злоумышленник не обойдется, но в таком случае не получится авторизоваться с нескольких устройств, потому как такие поля как ip будут обновляться, и пользователь с первого устройства просто разлогинется.
Если вы имели в виду под ua userAgent, то да, при обновлении эта строка станет немного другой
"Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.152 YaBrowser/15.6.2311.3473 (beta) Safari/537.36"
Но не вся. Но про IP не понял, вы хотите сказать что ip может меняться при каждом открытии страницы. На сколько я знаю IP меняется при отключении/подключении сети интернет.
Средний
