Comments 14
А почему не хранить в этой бд теперь и саму сессию?)
И, например, использовать Redis для хранения сессий, который подходит отлично: быстрый доступ по ключу (идентификатору сессии), удобный инструментарий для сериализации/десиарилизации, надежность не критична.
И все таки я бы не доверял шифрованным кукам. Какой алгоритм шифрования у них используется?
И все таки я бы не доверял шифрованным кукам. Какой алгоритм шифрования у них используется?
Ага, непонятно, если они все равно сверяются с БД. Вообще какая-то странная штука, статические сайты конечно хорошо масштабируются, но они же сами говорят про БД, а это уже не статика. Шифрование cookies ключем сервера вообще относительно распространненая вещь, например у IIS/ASP.NET (MachineKey)
Заголовок статьи как бы намекает — «чтобы упростить масштабирование приложения».
Есть у вас, к примеру, 20 web серверов с балансировкой. Пускай на каждом есть своя БД и между ними настроена репликация.
Ответ на вопрос «Как будет чувствовать себя репликация, если данные будут меняться в n-раз чаще?» совпадает с ответом на Ваш вопрос.
Можно пойти дальше и добавить сайты на других доменах, партнерский сайты, разные дата центры, мобильные приложения и т.д.
Есть у вас, к примеру, 20 web серверов с балансировкой. Пускай на каждом есть своя БД и между ними настроена репликация.
Ответ на вопрос «Как будет чувствовать себя репликация, если данные будут меняться в n-раз чаще?» совпадает с ответом на Ваш вопрос.
Можно пойти дальше и добавить сайты на других доменах, партнерский сайты, разные дата центры, мобильные приложения и т.д.
UFO just landed and posted this here
UFO just landed and posted this here
Результат не сильно большой, если данных хранится не много + нужно использовать gzip.
Если БД не на том же сервере, то сеть в любом случае будет грузится этими данными.
Из реального опыта — кука по размеру сравнима с картинкой логотипа twitter(700 Байт), тока на куку не надо делать отдельный запрос.
Есть еще минус(помимо ранее упомянутых) — если статика раздается с того же домена принимающего куки и тогда данные сессии слишком много раз будут передаватсья и разбираться web сервером.
Если БД не на том же сервере, то сеть в любом случае будет грузится этими данными.
Из реального опыта — кука по размеру сравнима с картинкой логотипа twitter(700 Байт), тока на куку не надо делать отдельный запрос.
Есть еще минус(помимо ранее упомянутых) — если статика раздается с того же домена принимающего куки и тогда данные сессии слишком много раз будут передаватсья и разбираться web сервером.
Безопасность, по сравнению с сессиями, снизилась. Проблемы остались те же. Где профит?
UFO just landed and posted this here
Привет, __VIEWSTATE! За который столько матерят asp.net…
1. в такой сессии много данных не сохранишь, ибо есть ограничение на размер куки (желательно не превышать 4кб)
2. понимаю что перевод, но все же
не проще ли было дополнительно шифровать сессию еще и с помощью пароля пользователя? тогда не надо было бы и в бд ничего хранить
2. понимаю что перевод, но все же
Хотя схема с установкой времени жизни работает неплохо, особенно, если время не очень большое, в случае с Persona нам нужен был способ немедленно закрывать сессию на всех клиентах, если пользователь менял пароль.
не проще ли было дополнительно шифровать сессию еще и с помощью пароля пользователя? тогда не надо было бы и в бд ничего хранить
Т.е. сначала мы хранили у клиента ключ, у себя сессию. Теперь мы будем хранить у себя ключ, а у клиента сессию.
Так как при каждом запросе передаются cookie, то всю сессию мы будем гонять туда-сюда. В чем, собственно, плюс?
Так как при каждом запросе передаются cookie, то всю сессию мы будем гонять туда-сюда. В чем, собственно, плюс?
Почему время жизни сессии не зашифровано? Его же в таком случае можно изменить, продлив время жизни сессии.
Sign up to leave a comment.
Храним сессии на клиенте, чтобы упростить масштабирование приложения (3-я из 12 статей о Node.js от команды Mozilla Identity)