"Помни меня на этом компьютере" - как это должно работать?

Глядя на куки файлы Gmail, вам легко увидеть, что хранится в cookie "запомнить меня". Имя пользователя/одноразовый токен. Это может быть реализовано по-разному в случаях, когда имя пользователя также является секретным. Но что бы то ни было... вещь не очень высокая безопасность: вы крадете cookie, и вы готовы к работе.

Однако мой вопрос касается функциональной стороны: когда вы протираете свои токены доступа? Если пользователь регистрируется без, нажав "запомнить меня" на другом компьютере, должен ли он лишить их токенов доступа на всех машинах? Я спрашиваю, как это традиционно реализуется, а также как это должно быть реализовано.

Ответ 1

Я регулярно использую 2 или 3 машины одновременно и "помню меня" на всех из них. Если бы один из них отключил другие, которые были бы очень раздражающими, поэтому я бы не рекомендовал его.

Традиционно он будет использовать тайм-аут, cookie истекает через определенный промежуток времени (или когда пользователь выдает).

Все зависит от вашей модели безопасности. Если вы пишете внутреннее корпоративное приложение, в котором вы только ожидаете, что один пользователь будет находиться на одном компьютере, тогда вы можете захотеть иметь более жесткие ограничения, чем gmail.

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

Ответ 2

Статьи Persistent Login Best Practice и Улучшенный постоянный логин Best Практика - отличные рекомендации о том, как реализовать такую функциональность.

См. также эти вопросы StackOverflow

Ответ 3

Вход с другого компьютера не должен приводить к недействительности входа, связанного с файлом cookie, на другой машине. Однако, если пользователи logsout или "не вы? Войдите здесь", это должно очистить файл cookie, в котором работает пользователь.

Кстати, воровство cookie может быть затруднено, настаивая на https и не создавая его для сценариев.

Добавив "; HttpOnly" к выходу вашего cookie, это сделает cookie недоступным для javascript, например.

HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Vary: Accept-Encoding
Server: Microsoft-IIS/7.0
Set-Cookie: ASP.NET_SessionId=ig2fac55; path=/; HttpOnly
X-AspNet-Version: 2.0.50727
Set-Cookie: user=t=bfabf0b1c1133a822; path=/; HttpOnly
X-Powered-By: ASP.NET
Date: Tue, 26 Aug 2008 10:51:08 GMT
Content-Length: 2838

вы можете узнать больше об этом

Ответ 4

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

Дата истечения срока устанавливается обычно на разумный период (две недели) или после того, как пользователь явно вылетел из машины,

Ответ 5

Что бы я делал, это связать каждую сессию с IP-адресом. Если токен сеанса отправляется с другого IP-адреса, чем у вас, отклоните его.

Ответ 6

Ленты доступа должны быть специфичными для IP-адресов, так что они не могут быть легко переданы через машины.

Они также должны быть реализованы таким образом, чтобы пользователи могли видеть, на каких машинах есть активные токены.

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

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