2010-08-09 5 views
2

Мне сказали, что хранить файлы, такие как пароли, имена пользователей и идентификаторы пользователей, в файлах cookie небезопасно, и вместо этого вы должны хранить sessionID в файле cookie. Вот где я заблудился.Доступ к данным сеанса с идентификатором сеанса связи

Моя цель состоит в том, чтобы иметь базовую функцию «запомнить меня». Обычно я хотел бы хранить данные входа пользователя в файл cookie, но поскольку это небезопасно, мне интересно, какая альтернатива. Я понимаю, что каждый раз, когда я создаю сеанс, он создает cookie, который создает уникальный идентификатор, но заканчивается, когда я закрываю браузер. Итак, как мне получить доступ к этой информации о сеансе после закрытия браузера?

Вся помощь приветствуется.

ответ

2

Возможно, лучший подход, как было предложено, и то, что большинство сторонних приложений сделать, это создать «user_sessions» таблицы базы данных со следующими полями:

session_id (var_char) 
user_id (int) 
ip_address (var_char) 
last_logged_in (unix timestamp) 

Затем использовать куки для хранения md5 хэш все, что вам нравится, возможно:

md5($username.$ip); //since md5 has a lot of reverse look ups now you should use a number of fields to validate. You could use a different crypto function to make it more difficult to crack, but md5 is the simplest version available in all php versions. 

EDIT: вы затем сравнить сохраненный хэш от печенья с базой данных session_id, чтобы увидеть, если они уже вошли в систему причина совместить coupl. e полей в функции md5 заключается в создании менее «допустимого» формата хэширования. Это делает его менее вероятным, кто-то сможет отредактировать файл cookie и войти как кто-то другой.

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

p_login=true || p_login=false 

Таким образом, вы узнаете, следует ли авторизоваться или принудительно войти в систему.

примечание: вы можете посмотреть http://www.openwall.com/articles/PHP-Users-Passwords для другого способа использования хеш-паролей, session_ids и пользователей.

+0

Спасибо за это! Пара вопросов: Является ли sessionID тем же самым, что хранится в файле cookie ('md5 ($ username.ip);')? // На основании вашего примера IP-адрес, по-видимому, используется для аутентификации, поэтому, если их IP-адрес изменится (прокси), им придется снова войти в систему, исправить? (не проблема, просто любопытно.) // Также, какова цель поля last_logged_in? (опять же, просто любопытно?) – williamg

+0

IP-адрес - это что-то уникальное для хэша. Для пользователя более вероятно, что вы просто хешируете имя пользователя. Затем они могут взломать куки-файлы и войти как кто-либо. Если это md5 ($ username. $ Ip), сложнее определить, что будет хешем. Не имеет значения, изменится ли IP-адрес, поскольку он хранится в файле cookie как хэш-метка md5. Поэтому вы просто проверяете, существует ли сеанс в БД с session_id = 'md5 ($ username. $ Id)'. если не создать его. если он обновляется с новым IP-адресом и хешем. Хранение последнего зарегистрированного времени и ip для обеспечения безопасности. Если вы можете проверить неавторизованный доступ u. – User123342234

+0

обновите свой ответ, чтобы уточнить немного больше. – User123342234

2

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

Для функции «запомнить меня» вы можете отправлять файлы cookie, содержащие идентификатор пользователя, и хэш этого хэшированного пароля этого пользователя хэшируется с помощью известного, но секретного токена. Это решение не позволяет удаленно истекать чей-то логин, однако, не перезагружая чей-то пароль.

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

+0

определенно последний подход ... –

+0

Но не использовал бы токен так же уязвим, как хранение пароля или идентификатора пользователя? – williamg

+0

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

Смежные вопросы