Не работают куки django

Django Cookies, как я могу их установить?

У меня есть веб-сайт, который показывает различный контент на основе местоположения гость выбирает. e.g: пользователь входит в 55812 в качестве zip. Я знаю, что город и область lat / long. то есть и дать им их содержание соответствующих в ту область. Мой вопрос в том, как я могу сохранить это в cookie, чтобы когда они возвращаются, они не обязаны всегда вводить свой почтовый индекс?

Я вижу это следующим образом:

1. установить постоянный cookie на основе их области.
2. когда они вернуть чтение cookie, захватить zipcode.
3. возврат содержимого на основе почтового индекса в их cookie.

Я не могу найти никакой надежной информации о настройке cookie. Любой помощь очень ценится.

3 ответов

это помощник для установки постоянного cookie:

перед отправкой ответа используйте следующий код.

обновление: проверьте @Peter ответ ниже для встроенного решения:https://stackoverflow.com/a/5575578/174027

используя рамки сеанса Django должен охватывать большинство сценариев, но Django также теперь предоставляет прямые методы манипуляции cookie на объектах запроса и ответа (поэтому вам не нужна вспомогательная функция).

получение файлов cookie:

вы можете вручную установить cookie, но в зависимости от вашего варианта использования (и если вы захотите добавить больше типов постоянных/сеансовых данных в будущем), возможно, имеет смысл использовать Джанго функция. Это позволит вам GET и set переменные, привязанные внутренне к cookie сеанса пользователя. Классная вещь в этом заключается в том, что если вы хотите сохранить много данных, привязанных к сеансу пользователя, сохранение их всех в cookies добавит много веса HTTP-запросам и ответы. С сеансами cookie сеанса-это все, что отправляется туда и обратно (хотя есть накладные расходы на конец хранения данных сеанса Django, чтобы иметь в виду).

Источник

Русские Блоги

Компоненты Django — куки и сессия

Компоненты Django — куки и сессия

1. Технология отслеживания сеансов

1. Что такое технология отслеживания сеансов

Можно понимать как встречу между клиентом и сервером, встреча может содержать несколько запросов и ответов.

В JavaWeb клиент отправляет первый запрос на запуск сервера, и сеанс начинается, пока клиент не закроет браузер и сеанс не завершится.

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

Запросить домашнюю страницу банка;

• Запросить логин (параметры запроса — имя пользователя и пароль);
• Запрос на передачу (параметры запроса и данные, связанные с передачей);
• Запросить погашение кредитной карты (запросить данные параметра, относящиеся к погашению).  

В этом разговореИнформация о текущем пользователе должна быть передана в этом сеансеДа, поскольку логин — «Чжан Сан», то перевод и погашение должны быть связаны с переводом и погашением «Чжан Сан»! Это означает, что у нас должна быть возможность обмениваться данными во время сеанса.

2. Технология пути сеанса использует файлы cookie или сеансы для завершения

HTTP-протокол — это протокол без сохранения состояния , Что означает, что каждый запрос является независимым! Статус предыдущего запроса не может быть записан. Но протокол HTTP может использовать куки для завершения отслеживания сеанса! В веб-разработке, Используйте сеанс для завершения отслеживания сеанса ， Нижняя часть сессии опирается на технологию Cookie 。

2. Печенье

1. Обзор файлов cookie

(1) Что такое печенье?

Cookie переводится на китайский язык, что означает маленький десерт, маленькое печенье. В HTTP он представляет собой небольшой десерт, отправленный сервером клиентскому браузеру. На самом деле Cookie — это структура ключ-значение, похожая на словарь в Python.

С ответом на стороне сервера, отправленным клиентскому браузеру. Затем клиентский браузер сохранит файл cookie и снова отправит файл cookie на сервер при следующем обращении к серверу, чтобы сервер мог извлечь полезную информацию.

(2) принцип куки?

Cookie создается сервером, а затем отправляется клиенту через ответ Пара ключ-значение 。 Клиент сохранит файл cookie и отметит его источник (файл cookie этого сервера). , Когда клиент делает запрос к серверу Включите все серверные куки в запрос и отправьте на сервер , Чтобы сервер мог распознать клиента!

(3) Просмотр файлов cookie

(4) спецификация куки

• Максимальный размер файла cookie составляет 4 КБ;
• Сервер может хранить до 20 файлов cookie в браузере клиента;
• Браузер может хранить до 300 файлов cookie;

Приведенные выше данные являются лишь спецификацией Cookie HTTP, но сегодня в битве браузеров некоторые браузеры могут «расширить» спецификацию Cookie, чтобы победить своих оппонентов и показать свои способности. Например, размер каждого cookie составляет 8 КБ, Можно сохранить до 500 файлов cookie и т. Д. Но нет возможности пополнить свой жесткий диск!
Обратите внимание, что файлы cookie не используются разными браузерами. , Другими словами, когда вы используете IE для доступа к серверу, сервер отправляет cookie в IE, а затем сохраняет его в IE. Когда вы используете FireFox для доступа к серверу, невозможно отправить cookie, сохраненный IE, на сервер.

(5) Cookie и заголовок HTTP

Куки передаются HTTP-запрос и заголовки ответа Перешли на клиент и сервер:

• Cookie: заголовок запроса, который клиент отправляет на сервер;
• Формат: Cookie: a = A; b = B; c = C. То есть несколько файлов cookie отправляются с точкой с запятой: Set-Cookie: заголовок ответа, отправляемый сервером клиенту;
• Один объект Cookie и один набор cookie: набор cookie: a = набор cookie: b = B набор cookie: c = C

(6) Покрытие cookie

Если сервер отправляет дубликаты файлов cookie, исходные файлы cookie будут перезаписаны. Например, первый запрос от клиента на сервер отправляет файл cookie: Set-Cookie: a = A; второй запрос от сервера отправляет: Set-Cookie: a = AA, тогда клиент оставляет только один файл cookie, а именно: a = AA.

2. Синтаксис cookie в Django

(1) Установить печенье

Возврат HttpResponse (), return render (), return redirect () Все три тела ответа возвращаются HttpResponse, поэтому файлы cookie могут быть установлены. Подробнее см. Анализ исходного кода и настройки параметров ниже.

(2) Получить печенье

Request.COOKIES — это на самом деле словарь, который инкапсулирует все ключи cookie из этого запроса.

• по умолчанию: значение по умолчанию
• соль: зашифрованная соль
• max_age: время истечения фонового контроля

(3) Удалить куки

Тело ответа. Delete_cookie («ключ»)

Общий метод очистки куки браузера: ctrl + shift + delete

(4) JQuery cookie

3. Проверка версии файла cookie

(2) Модель и база данных

Создайте информацию о пользователе следующим образом:

(3) Просмотр функции

4. Введение в параметры set_cookie

Анализ исходного кода: класс HttpResponseBase имеет функцию set_cookie

（1）max_age

Если он не задан, файл cookie продолжается до тех пор, пока браузер не будет закрыт, а если установлено max_age = 15, файл cookie будет действителен в течение 15 секунд.

（2）expires

Недействительный в указанную дату, вам нужно ввести модуль datetime

По истечении срока действия страница индекса больше не будет отображать HI, юань вместо HI, None, поскольку срок действия файла cookie для имени пользователя истек.

（3）path

Функция просмотра, по которой путь может получить установленный cookie.

5. Практика печенья

(1) Случай 1: отображение времени последнего доступа.

Измените часовой пояс на пекинское, установите в settings.py:

Добавьте последний тег времени входа в index.html:

Измените функцию представления индекса в view.py:

(2) Случай 2: показать товары, просмотренные в последний раз.

Три, сессия

Сеанс является серверной технологией, при использовании этой технологии сервер может использоваться для браузера каждого пользователя при запуске Создать уникальный объект сеанса Поскольку сеанс является эксклюзивным для браузера пользователя, поэтому Когда пользователи получают доступ к веб-ресурсам сервера, они могут помещать свои данные в свои собственные сеансы. Когда пользователь заходит на доступ к другим веб-ресурсам на сервере, Другие веб-ресурсы извлекают данные из соответствующих сеансов пользователя для обслуживания пользователя. 。

Первый шаг: генерировать случайную строку;

Шаг 2: Сервер устанавливает set_cookie в теле ответа браузера, ключом является sessionid, а значением является соответствующая случайная строка.

Третий шаг: сгенерировать запись в таблице django-сессии, ключ сеанса — случайная строка, а данные сеанса — установленное значение сеанса [«username»] = «yuan».

Четвертый шаг: после того, как первые три шага завершены, браузер отправляет второй запрос функции просмотра. Если эта функция хочет выполнить сеанс: request.session [«username»], Этот шаг также делится на три этапа: (1) прочитать случайную строку, соответствующую sessionid, в cookie, (2) отфильтровать записи в таблице django-session, где ключ сеанса равен случайной строке. (3) Извлеките словарь, соответствующий данным сеанса, из отфильтрованного объекта записи, а затем .get («имя пользователя») может извлечь соответствующий «юань».

1. Синтаксис сессии в Джанго

(1) Основные операции

(2) Другие операции

2. Конфигурация сеанса

SESSION_SAVE_EVERY_REQUEST = True: означает, что расчет времени SESSION_COOKIE_AGE обновляется при каждом входе в систему, что задерживает время истечения срока действия cookie.

3. сеанс приложения

(1) Сохранить информацию о статусе входа

В файл urls.py добавлены два новых пути:

Добавьте две функции просмотра сеанса в views.py:

Примечание: метод и этапы выполнения записи сеанса и сеанса чтения.

(2) Сохранить время последнего входа

Добавьте в функцию view login_session:

Добавьте в функцию просмотра index_session:

(3) Операция обновления сеанса

Как упоминалось ранее, когда пользователь входит в систему, выполняется операция записи сеанса. Шаги операции следующие:

Но в реальных ситуациях, если вы используете браузер Chrome для повторного входа в юань пользователей. Можно обнаружить, что количество таблиц django_session в базе данных не увеличилось:

При многократном обновлении session_key остается неизменным, и только session_data перезаписывается и обновляется. Из этого мы видим:

Сервер сначала определит, есть ли результат в request.COOKIE.get («sessionid»), если это первый раз для входа в систему и результата нет, затем выполните операцию добавления, в противном случае — операцию обновления. То есть сервер и браузер всегда будут поддерживать только одну запись. Когда пользователь переключается, информация предыдущего пользователя полностью покрыта.

Однако при входе в систему с помощью браузера, такого как Firefox, он будет добавлен. Поэтому сервер использует запись, чтобы соответствовать браузеру, а не пользователю.

Источник

Не работают куки django

Внимание!

Глава 12. Сессии, пользователи и регистрация
Пред.	След.

Глава 12. Сессии, пользователи и регистрация

Данная глава временно взята из первой версии книги и подлежит корректировке. Вы можете помочь с этим!

Перевод © Попов Руслан

Пришло время для исповеди: до этого момента мы умышленно игнорировали очень важный аспект разработки.

До сих пор мы рассматривали общий случай создания HTML, но в этой главе мы пойдём другим путём и рассмотрим возможности Django для генерации других видов контента. До этого момента мы рассматривали посетителей нашего сайта как безликую, анонимную массу просматривающую наши аккуратно свёрстанные страницы.

Конечно, на самом деле всё не так. За браузерами, которые работают с нашим сайтом, сидят реальные люди (по крайней мере, иногда). Это нельзя игнорировать. Интернет предназначен для объединения людей, а не машин. Если мы стараемся разрабатывать совершенно неотразимые сайты, в конечном счёте нам придётся учитывать мнение людей.

К сожалению, не всё так просто. HTTP разработан так, чтобы не учитывать состояния. Таким образом, каждый запрос происходит как-бы в вакууме. Не существует взаимосвязи между одним запросом и другим. Соответственно, мы никак не сможем привязаться к какому-нибудь аспекту (IP адрес, тип браузера и так далее) для гарантированного определения запросов от одного конкретного пользователя.

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

Cookie

Разработчики браузеров давно поняли, что отсутствие поддержки состояний в протоколе HTTP вызвало большие трудности у веб разработчиков. И тогда были созданы cookie . Cookie — это небольшие кусочки информации, которые браузер сохраняет по просьбе веб сервера. При каждом обращении браузера к странице определённого сайта, он отсылает полученную ранее cookie.

Давайте рассмотрим как это работает. Когда вы открываете свой браузер и переходите на http://google.com/, ваш браузер отправляет HTTP запрос на Google, который начинается так:

Ответ Google выглядит обычно так:

Обратите внимание на заголовок Set-Cookie . Ваш браузер сохранит значение cookie ( PREF=ID=5b14f22bdaf1e81c:TM=1167000671:LM=1167000671 ) и будет отсылать его обратно, при каждом обращении к серверу Google. Таким образом, при следующем посещении Google, ваш браузер будет посылать такой запрос:

Google затем может использовать значение Cookie для определение того, что вы именно тот, кто обращался к сайту ранее. Значение, например, может быть ключом записи в базе данных, которая хранит информацию о пользователе. Google может (и будет) использовать её для отображения вашего имени на странице.

Получение и установка

Для сохранения состояний в Django большую часть времени вы пожелаете использовать высокоуровневые сессии и/или среду пользователя, которая будет рассмотрена в этой главе чуть позже. Однако, мы прервёмся и посмотрим как читать и писать cookie на низком уровне. Это поможет вам понять как работают инструменты, которые описаны далее. И это вам пригодится, если вам придётся напрямую работать с cookie для решения своих задач.

Прочитать уже установленный cookie невероятно просто. Каждый объект запроса обладает объектом COOKIES , который выглядит как словарь. Вы можете использовать его для чтения значения любого cookie, которые браузер отправил в представление:

Записать cookie гораздо сложнее. Вам потребуется использовать метод set_cookie() объекта HttpResponse . Ниже приведён пример установки cookie favorite_color , значение для которого берётся из параметра GET :

Вы также можете передать ряд необязательных аргументов в response.set_cookie() , которые управляют поведением cookie, подробности описаны в таблице « Опции cookie » :

Таблица 12.1. Опции cookie

Префикс пути для которого верен данный cookie. Браузеры отправляют cookie на сервер, только для страниц соответствующих указанному префиксу пути. Таким образом вы можете использовать этот параметр для отправления cookie в определённую секцию сайта.

Этот параметр очень полезен в случае, когда вы не контролируете высший уровень домена вашего сайта.

Домен для которого действителен cookie. Вы можете использовать этот параметр для установке cookie для другого домена. Например, domain=».example.com» установит cookie, который будет отправляться страницам доменов www.example.com , www2.example.com и an.other.sub.domain.example.com .

Если этот параметр установлен в None , то cookie будет доступен только для установившего его домена.

Параметр	По умолчанию	Описание
max_age	None	Время (в секундах) активности cookie. Если данный параметр имеет значение None, то cookie действует до закрытия браузера.
expires	None	Точная дата и время окончания действия cookie. Должна быть указана в формате Wdy, DD-Mth-YY HH:MM:SS GMT . Если этот параметр установлен, он имеет преимущество над max_age .
path	/
secure	False	Если параметр установлен в True , то браузер передаёт этот cookie на сервер по протоколу HTTPS.

Всеобщее счастье

Вы могли отметить ряд потенциальных проблем методики работы с cookie. Взглянем на наиболее важные из них:

Хранение cookie является исключительно добровольным. Браузеры ничего не гарантируют. В действительности все браузеры позволяют пользователям управлять политикой работы с cookie. Если вы желаете увидеть как важны cookie для веба, включите опцию браузера « Спрашивать разрешение для каждого cookie » .

Несмотря на их почти универсальное использование, cookie ненадёжны. Это означает, что разработчики должны проверять, что пользователь действительно принял cookie прежде чем начинать использовать их.

Самое главное, никогда не сохраняйте важную информацию в cookie. Интернет заполнен ужасными историями о разработчиках, которые сохраняли не восстанавливаемую информацию в cookie.

Cookie небезопасны, особенно те, которые отправлялись без использования протокола HTTPS. Cookie крайне легко прочитать, по причине того, что они пересылают информацию чистым текстом. Таким образом, атакующий прослушивает канал, ловит cookie и читает информацию. Это означает, что вы никогда не будете пересылать важную информацию в cookie.

Существует более хитрая атака, известная как человек посередине , когда атакующий перехватывает cookie и использует его, чтобы представиться вами. Глава 19 FIXME подробно описывает такие атаки и методы их предотвращения.

Cookie не защищены даже от того, кому они отсылаются. Большинство браузеров предоставляют простые способы изменения содержимого отдельных cookie, а изобретательные пользователи могут всегда воспользоваться такими инструментами, как mechanize для ручного создания HTTP запросов.

Таким образом, вы не можете хранить в cookie данные, которые могут быть чувствительны к взлому. Стандартная ошибка при работе с cookie — хранение чего-нибудь такого IsLogged=1 в cookie после авторизации пользователя. Вы удивились бы количеству сайтов в которых используется такой механизм при авторизации пользователей. Нужна только секунда для взлома таких « защищённых » сайтов.

Источник