Дмитрий Тарасов, подписать токен - значит добавить к нему подпись, например sha256(secret, token,uid, datetime). Либо можно зашифровать информацию с помощью серверного ключа и расшифровать при получении.
Я тоже это имел ввиду. Если вы хотите привязать токен к сессии- то зачем он вам вообще нужен?
Вероятность того что два произвольных 16-байтных токена совпадут 2^-128 при правильной реализации, т.е. такая что ей можно пренебречь.
Если у вас есть сессия и вы хотите привязать аутентификацию к сессии, то никаких токенов не надо, достаточно просто для сессии внутри серверного объекта проставлять флаг что сессия атворизована, тогда фактически сессионная кука станет авторизационной.
Дмитрий Тарасов, да, так нормально.
Можно либо хранить в базе/мемкеше либо отдавать клиенту что-то вроде набора токен,uid,срок_действия,подпись_токена и не хранить в базе, а проверять подпись.
Что значит дублировать в сессии?
Kinhagen, определенные сложности все равно будут безотносительно авторского права - например сложно будет найти в поисковиках. Добавьте к названию что-нибудь. Типа "Барышня-Крестьянка: The Cook Book", это сейчас модно.
Igor, в том то и дело, что при посещении .onion сайта с https наружу полетит запрос на проверку CRL, без всякого шифрования, по которому будет понятно что такой-то юзер полез на такой-то onion сайт.
Troodi Larson, нормально, это бот - ответьте ему что вы не получаете сообщения об ошибке, но письма попадают в папках спам - ответ будет разбираться второй линией.
Alex Wells,
да, система основанная на публичных сертификатах не устойчива к MitM атакам (т.к. используется небезопасный процесс валидации) и неанонимна. Помимо обращений к сайту еще могут происходить обращения к CRL, что снижает анонимность. Помимо этого, могут всплывать TLS session persistance (aka SSL cookie) которые так же позволяют трекать пользователя.
