Здравствуйте, peer, Вы писали:

P>·>В случае если тупо будут тыкать ссылку, то база не нужна. В ссылку можно зашить всю инфу вместе с криптографической защитой.
P>то есть когда длинная ссылка с токеном там внутри зашито на какой логин выдана ссылка
Ну да.

P>и потом надо еще сопоставить, что юзер не использует чужую ссылку?
Это как? Будет аналогично тому, что юзер не использует чужой пароль.

P>·> Разница лишь в том, что токен обычно большой блок base64, т.к. в нём все данные лежат, такое только кликнуть можно. А код — мелкий, т.к. там нет данных, они в базе, зато легко ввести вручную.
P>тут не понял. Если несложно поясните подробнее пожалуйста
ссылка с токеном будет выглядеть как-то так:
https://service/register?user=vasya&ttl=20250504T102345&signature=LonGBase64Block_jhj908235Koipo29Hpd93jJKx
На сервере обработка простая — достаём user и ttl и проверяем подпись. Подпись верна — ссылка валидна, человек может задать свой пароль.

ссылка с кодом валидации как-то так
https://service/register?code=JP8Q-4RQD
Сервер должен хранить у себя таблицу выданных кодов и искать там user и ttl. Запись найдена — код валиден, человек может задать свой пароль.

P>>>и я так понимаю лучше сделать одноразовый токен? типа если даже TTL не закончился, то второй раз уже невалидный и отсылаем на Restore
P>·>Я до сих пор не понимаю, почему сразу на Restore не послать-то, раз у тебя оно уже есть?
P>а вариант, я просто такую практику не встречал. тогда тут в принципе уникальная ссылка не нужна, просто ссылка на страницу Restore?
Ссылка на страницу restore это и есть уникальная ссылка, которая тебе письмом приходит "кликните тут чтобы задать новый пароль"...

Здравствуйте, peer, Вы писали:

P>·>В случае если тупо будут тыкать ссылку, то база не нужна. В ссылку можно зашить всю инфу вместе с криптографической защитой.
P>то есть когда длинная ссылка с токеном там внутри зашито на какой логин выдана ссылка
Ну да.

P>и потом надо еще сопоставить, что юзер не использует чужую ссылку?
Это как? Будет аналогично тому, что юзер не использует чужой пароль.

P>·> Разница лишь в том, что токен обычно большой блок base64, т.к. в нём все данные лежат, такое только кликнуть можно. А код — мелкий, т.к. там нет данных, они в базе, зато легко ввести вручную.
P>тут не понял. Если несложно поясните подробнее пожалуйста
ссылка с токеном будет выглядеть как-то так:
https://service/register?user=vasya&ttl=20250504T102345&signature=LonGBase64Block_jhj908235Koipo29Hpd93jJKx
На сервере обработка простая — достаём user и ttl и проверяем подпись. Подпись верна — ссылка валидна, человек может задать свой пароль.

ссылка с кодом валидации как-то так
https://service/register?code=JP8Q-4RQD
Сервер должен хранить у себя таблицу выданных кодов и искать там user и ttl. Запись найдена — код валиден, человек может задать свой пароль.
Даже можно сделать если человек пошел на https://service/ показать "вы новый пользователь? Введите код тут: [___]" — человек вводит 8 букв и готово.

P>>>и я так понимаю лучше сделать одноразовый токен? типа если даже TTL не закончился, то второй раз уже невалидный и отсылаем на Restore
P>·>Я до сих пор не понимаю, почему сразу на Restore не послать-то, раз у тебя оно уже есть?
P>а вариант, я просто такую практику не встречал. тогда тут в принципе уникальная ссылка не нужна, просто ссылка на страницу Restore?
Ссылка на страницу restore это и есть уникальная ссылка, которая тебе письмом приходит "кликните тут чтобы задать новый пароль"...