Ответы пользователя по тегу Сессии
  • Где хранить сессии? SQLite? MySQL? Memcached? Redis? FS?

    @deliro
    SQLite и ФС — абсолютно не подходят, если приложение будет масштабироваться

    Серверы БД (MySQL/PostgreSQL/etc.) — надёжный но самый медленный вариант

    In-memory БД (Redis/memcached) — отличный вариант, из всех выше, самый производительный, но можно упереться в оперативку

    Signed Cookie Session (и его частный случай — JWT) — неописанный тобой вариант, самый экономный по памяти и диску и самый производительный. Сессия хранится прямо в куке. Сами данные сериализуются, например, JSON'ом и сжимаются, например, gzip'ом (но можно и msgpack + lzma взять, как угодно). После, чтобы пользователь (или хакер) не поменял куку по своему желанию, она подписывается, например, HMAC'ом + любой криптостойкой хэш-функцией
    Из плюсов: 0 байт занятой оперативы (кроме момента выполнения запроса), 0 байт занимаемого места на диске, нет зависимостей от баз данных
    Из минусов: нет возможности "разлогинить все остальные сессии" по запросу пользователя, небольшой сетевой оверхэд, так как сессия от браузера отправляется на каждый запрос, ограничение на размер данных в сессии, потому что данных должны влезть в куку, включая подпись и разделители. Но ради эксперимента, мне удалось засунуть в такую сессию первую главу Войны и мира сжатой, прежде чем упереться в лимит.
    Ответ написан
  • Как именно устроены session и cookies?

    @deliro
    1. Нет никакой синхронизации. Сервер может только указать клиенту, что ему нужно установить куку X в значение Y хэдером Set-Cookie и считать с пришедшего на сервер запроса куки (все куки отправляются в каждом запросе на сервер).
    2. Сессии могут храниться на клиенте (signed cookie session). При этом используется подпись куки с помощью HMAC, чтобы данные сессии не могли быть свободно изменены клиентом. Но обычно сессии хранятся на сервере. Тут выбор огромный: от баз данных и key-value хранилищ (Redis, например) до простых файлов. При этом, клиенту посылается кука ID сессии (так сервер идентифицирует юзера), которую злоумышленник может стащить. Таким кукам, дабы защитить юзеров от XSS, ставится флаг HttpOnly, который советует браузеру не давать эту куку скриптам вроде JS. В этом случае, стащить куку получится только завладев браузером, файловой системой юзера или через багу браузера.
    3. Смотри второй ответ. В некоторых случаях - да. Но редко.
    4. Можно передавать значение session id в строке URL (GET - параметром), вроде такого: example.com/some/page/?session_id=2af26905dcf31a1d... Некоторые сервисы используют это, как fallback вариант, однако, он очень небезопасен, т.к. любой XSS или простой безобидный JS вроде Яндекс.Метрика видит весь URL. Так что, посылаем юзера включать куки.
    Ответ написан
    4 комментария
  • Куки или сессию использовать в данном случае?

    @deliro
    Сделай ход конём: храни сессию в куке, а данные "вы смотрели" в сессии.
    Ответ написан
    2 комментария
  • Как в сессию Django добавить список из id?

    @deliro
    def add(request, prod_id):
        if 'items' not in request.session:
            request.session['items'] = []
        if prod_id not in request.session['items']:
        	request.session['items'].append(prod_id)
            request.session.modified = True
        return redirect('/product/%s' % prod_id)


    upd:
    Проверил. Всё работает и с .save() и c modified = True.
    Ответ написан
    7 комментариев
  • Как реализовать взаимодействие двух пользователей?

    @deliro
    Django или Flask тут можно использовать только как API. Само взаимодействие и реальное время - websockets, js.
    Ответ написан
    2 комментария