Это может быть полностью допустимый подход и является его собственным типом аутентификации.Если все построено правильно, это доказывает, что у вас есть доступ к этому электронному письму (это ничего не доказывает, но доказывает, что очень много).
Эти значения часто не являются хешами.Они часто случайны, и это их сила.Если они являются хешами, их нужно сконструировать так, чтобы их выходные данные были «фактически случайными», поэтому обычно вы могли бы просто сделать их случайными в первую очередь.Для этого обсуждения я назову это «токеном».
Смысл токена в том, что он непредсказуем и чрезвычайно редок в своем пространстве поиска.Под непредсказуемым я подразумеваю, что даже если я точно знаю, для кого предназначен токен, фактически невозможно (т.е. в пределах практических временных ограничений) создать законный токен для этого пользователя.Так, например, если бы это был хеш имени пользователя и метка времени (даже метка времени в миллисекундах), это был бы ужасный токен.Я мог бы догадаться об этом очень быстро.Так что случайным лучше всего.
Под "разреженным" я подразумеваю, что из всех возможных токенов (т. Е. Строк правильной длины и формата), исчезающе небольшое число из них должно быть действительными токенами, и эти действительные токеныдолжны быть разбросаны по пространству поиска случайным образом.Например, если бы токены были последовательными, это было бы ужасно.Если бы у меня был токен, я мог бы найти другие токены, просто увеличив или уменьшив значение на единицу.
Таким образом, хороший токен выглядит следующим образом:
- Выберите случайную длинную строку
- Сохраните его в своей базе данных вместе с метаданными о том, что это значит, и отметкой времени
- Когда пользователь обнаружит это, прочитайте данные из базы данных
- ПослеЧерез некоторое время истекает токен, удаляя его из базы данных (необязательно, но желательно).
Другой способ реализации такой схемы - это кодирование зашифрованных метаданных (т. е. ИД пользователя, какая страницаэто идет, метка времени и т. д.).Тогда вам не нужно ничего хранить в базе данных, потому что это прямо там, в URL.Мне обычно не нравится этот подход, потому что он требует очень важного крипто-ключа, который вы затем должны защитить на производственных серверах, и который может быть использован для подключения как любой.Даже если у меня есть хорошие способы защиты такого ключа (как правило, подключенного HSM), мне не нравится такой ключ, даже существующий.Так что в целом я предпочитаю базу данных.Но для некоторых приложений шифрование данных лучше.Хранение метаданных в URL-адресе также значительно ограничивает объем метаданных, которые вы можете хранить, поэтому, опять же, токены лучше.