Является ли cookie общей и надежной реализацией сеанса?

Question

Я использую каркас пирамиды. Меня смущала связь между файлом cookie и сеансом. После поиска в википедии я знал, что сеанс является абстрактным понятием, а cookie может быть просто подходом (на стороне клиента).

Итак, мой вопрос: какая самая распространенная реализация (как на клиенте, так и на сервере)? Может ли кто-нибудь привести пример (возможно, просто описание) кодов? (Я бы не хотел использовать предоставленную поддержку сеанса внутри пирамиды, чтобы узнать)

Answer 1

В общем, файл cookie, хранящийся с клиентом, представляет собой только длинную, труднодоступную хэш-строку кода, которая может использоваться в качестве ключа в базе данных. На стороне сервера у вас есть таблица, сопоставляющая эти хэши сессии с первичными ключами (хэш сеанса должен никогда не быть первичным ключом) и отметки времени истечения срока действия.

Поэтому, когда вы получаете запрос, первое, что вы делаете, - это поиск файла cookie. Если его нет, создайте запись сеанса (cookie + время истечения срока действия) в таблице базы данных. Если он есть, найдите его и убедитесь, что он не истек; если он есть, создайте новый. В любом случае, если вы создали новый файл cookie, вы можете передать этот факт до более позднего кода, чтобы он знал, нужно ли ему запрашивать логин или что-то еще. Если вам не нужно было создавать новый файл cookie, установите временную метку истечения срока действия, чтобы вы не закончили сессию слишком рано.

При обработке кода представления и генерировании ответа вы можете использовать первичный ключ этого сеанса для индексации в другие таблицы, у которых есть данные, связанные с сеансом. Наконец, в ответе, отправленном обратно клиенту, установите cookie в хэш-код сеанса.

Если у кого-то есть файлы cookie отключены, то их cookie-сессия всегда будет новой, и любые функции, основанные на сеансе, не будут работать.

Answer 2

Наиболее распространенная реализация сеансов - использование файла cookie.

Куки-файл обеспечивает способ хранения произвольного фрагмента текста, который обычно используется в качестве идентификатора сеанса. Когда cookie отправляется вместе с HTTP-запросом, сервер (технически используемый на нем код) может использовать текст cookie (если он существует), чтобы распознать, что он видел клиента раньше. Текст в файле cookie обычно предоставляет достаточную информацию для извлечения дополнительной информации из базы данных об этом клиенте.

Например, очень наивная реализация может хранить первичный ключ в таблице shopping_cart в базе данных, так что, когда сервер получает текст печенья, он может напрямую использовать его для доступа к соответствующей корзине покупок для этого конкретного клиента.

(И это наивный подход, потому что пользователь может сделать что-то вроде изменения своего собственного файла cookie на другой первичный ключ и получить доступ к чужой телеге таким образом. Выбор правильного идентификатора сеанса isn't as simple as it seems, поэтому почти всегда лучше использовать существующая реализация сессий.)

альтернативный подход для хранения идентификатора сеанса, чтобы использовать параметр GET в URL (например, в чем-то вроде http://example.com/some/page?sid=4s6da4sdasd48, то sid GET паров выполняют ту же функцию, что и печенье строка). В этом подходе все ссылки на другие страницы сайта содержат приложенные к ним параметры GET.

Answer 3

Сессия (обычно) является файлом cookie, который имеет уникальное значение. Это значение отображает значение в базе данных или хранится в памяти, а затем указывает, какой сеанс загружается.PHP имеет альтернативный метод, в котором он добавляет уникальное значение в конец каждого URL-адреса (если вы когда-либо видели PHPSESSID в URL-адресе, который теперь знаете почему), но это имеет последствия для безопасности (теоретически).

Конечно, поскольку куки-файлы отправляются туда и обратно с каждым запросом, если вы не разговариваете по HTTPS, вы отправляете единственный способ узнать (надежно), что клиент, с которым вы сейчас разговариваете, является тем же самым, что вы вошли в систему десять секунд назад кому-то в той же беспроводной сети. Смотрите программы типа Firesheep по причинам, почему переключение на HTTPS - хорошая идея.

Наконец, если вы хотите построить свой собственный я, ему был дан совет по этому вопросу университетским профессором. Выдайте новый токен при каждой загрузке страницы и аннулируйте все токены пользователей, если используется недействительный токен. Это означает, что если злоумышленник получает токен и регистрируется в нем, пока он все еще действует, когда жертва щелкает ссылку, обе стороны выходят из системы.