Pull to refresh

Comments 14

А почему не хранить в этой бд теперь и саму сессию?)
И, например, использовать Redis для хранения сессий, который подходит отлично: быстрый доступ по ключу (идентификатору сессии), удобный инструментарий для сериализации/десиарилизации, надежность не критична.
И все таки я бы не доверял шифрованным кукам. Какой алгоритм шифрования у них используется?
Ага, непонятно, если они все равно сверяются с БД. Вообще какая-то странная штука, статические сайты конечно хорошо масштабируются, но они же сами говорят про БД, а это уже не статика. Шифрование cookies ключем сервера вообще относительно распространненая вещь, например у IIS/ASP.NET (MachineKey)
Заголовок статьи как бы намекает — «чтобы упростить масштабирование приложения».
Есть у вас, к примеру, 20 web серверов с балансировкой. Пускай на каждом есть своя БД и между ними настроена репликация.
Ответ на вопрос «Как будет чувствовать себя репликация, если данные будут меняться в n-раз чаще?» совпадает с ответом на Ваш вопрос.

Можно пойти дальше и добавить сайты на других доменах, партнерский сайты, разные дата центры, мобильные приложения и т.д.
Обычно при шифровании да ещё и подписи результат довольно большой по размеру. Cookies гоняются туда-сюда на «каждый чих». Насколько это влияет на нагрузку сети, user expirience?

В принципе я встречался с фреймворками на Java и C#, которые хранят сессию в cookies или передают параметром при каждом запросе, если cookies недоступны. Но мне показалось, что это плохое решение.
Взгляните на комментарии к оригиналу. Там тоже дискуссия примерно на эту тему. Резюмируя в двух словах: такой способ хранения сессий далеко не всем подойдёт, конкретно для Persona он подошёл хорошо, разработчики довольны. Возможно дело в том, что Persona используется прежде всего для аутентификации на других сайтах, то есть сеанс работы с ней очень короткий, и то, что на каждый запрос гоняется толстая кука — не проблема. С другой стороны, им дорога каждая миллисекунда задержки, чтобы не раздражать пользователя долгой аутентификацией. Наверное, из-за такой специфики сценариев использования им этот метод и подошёл.
Результат не сильно большой, если данных хранится не много + нужно использовать gzip.
Если БД не на том же сервере, то сеть в любом случае будет грузится этими данными.

Из реального опыта — кука по размеру сравнима с картинкой логотипа twitter(700 Байт), тока на куку не надо делать отдельный запрос.

Есть еще минус(помимо ранее упомянутых) — если статика раздается с того же домена принимающего куки и тогда данные сессии слишком много раз будут передаватсья и разбираться web сервером.
Безопасность, по сравнению с сессиями, снизилась. Проблемы остались те же. Где профит?
UFO landed and left these words here
Привет, __VIEWSTATE! За который столько матерят asp.net…
1. в такой сессии много данных не сохранишь, ибо есть ограничение на размер куки (желательно не превышать 4кб)
2. понимаю что перевод, но все же
Хотя схема с установкой времени жизни работает неплохо, особенно, если время не очень большое, в случае с Persona нам нужен был способ немедленно закрывать сессию на всех клиентах, если пользователь менял пароль.

не проще ли было дополнительно шифровать сессию еще и с помощью пароля пользователя? тогда не надо было бы и в бд ничего хранить
1. gzip + разделение на несколько cookie
Т.е. сначала мы хранили у клиента ключ, у себя сессию. Теперь мы будем хранить у себя ключ, а у клиента сессию.
Так как при каждом запросе передаются cookie, то всю сессию мы будем гонять туда-сюда. В чем, собственно, плюс?
Почему время жизни сессии не зашифровано? Его же в таком случае можно изменить, продлив время жизни сессии.
Only those users with full accounts are able to leave comments. Log in, please.