В чем разница между доставкой файлов cookie с локального и удаленного компьютера для сервера разработки Django? - PullRequest
Новая
       14

В чем разница между доставкой файлов cookie с локального и удаленного компьютера для сервера разработки Django?

0 голосов
/ 19 марта 2011

У меня есть сайт Django 1.2.5 (стабильная версия), который разрабатывается и тестируется на машине с Ubuntu 10.10.Блок dev находится в локальной сети с некоторыми компьютерами Windows, которые также должны иметь возможность просматривать и тестировать сайт.Пока что это просто админ, которым я пытаюсь поделиться.

Сайт отлично работает на dev box и может работать на 127.0.0.1: 8080 / admin или 192.168.17.165:8080/ admin (IP-адрес локальной сети устройства разработки) при запуске сервера разработки с помощью команд . / manage.py runserver и ./manage.py runserver 192.168.17.165:8080 соответственно.Однако, когда машина с Windows пытается связаться с сервером по адресу 192.168.17.165: 8080 / admin , страница входа администратора загружается очень хорошо, поэтому все настроено почти правильно, но когда введены проверенные имя пользователя и парольи кнопка отправки нажата, сообщение терпит неудачу, и возвращается следующая ошибка: 

Forbidden (403) CSRF verification failed. Request aborted.
Reason given for failure:
No CSRF or session cookie.

(очень похоже на сообщение @ thomallen)

Вот некоторые вещи, которые у меня естьуже проверил, что, кажется, не имеет никакого эффекта:

Я знаю, что шаблон login.html имеет добавленный токен {% csrf_token%}.Когда я просматриваю источник страницы, присутствует тег 

{% block content %}
{% if error_message %}
<p class="errornote">{{ error_message }}</p>
{% endif %}
<div id="content-main">
<form action="{{ app_path }}" method="post" id="login-form">{% csrf_token %}
  <div class="form-row">
    <label for="id_username">{% trans 'Username:' %}</label> <input type="text" name="username" id="id_username" />
  </div>

.(stock admin login.html)

Я перепутал порядок всех строк Middleware, как показано здесь http://josh.gourneau.com/blog/2010/02/17/django-12-csrf-verification-failed/. Ничего.Вот что у меня есть: 

MIDDLEWARE_CLASSES = (
    'django.middleware.common.CommonMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.middleware.csrf.CsrfResponseMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware', )

Я подумал, что, может быть, мне стоит с ними поиграться, но, похоже, это не помогло 

SESSION_COOKIE_DOMAIN = '192.168.17.165'
CSRF_COOKIE_DOMAIN = '192.168.17.165'

Очистил все остальные файлы cookie и историю веб-поиска.Выключен брандмауэр.

Мое текущее подозрение: На блоке разработчика (тот, который работает) Firefox показывает наличие 2 файлов cookie, sessionid и csrftoken .Ящики с окнами, похоже, не получают эти жетоны.Я изучил заголовки HTTP, используя плагин Firefox Live HTTP headers на обеих машинах.Окно Linux (так же, как сервер) получает: 

Set-Cookie: csrftoken=83bae579460e9d123d9d904f4e2ef4d5; Max-Age=31449600; Path=/
Set-Cookie: sessionid=ec2b472837318347f6e6c8243f9e0afd; expires=Sat, 02-Apr-2011 04:29:46 GMT; Max-Age=1209600; Path=/

Окно Windows получает очень похожую информацию, но Max-Age для cookie установлен на 0 (Max-Age = 0).После этого машины Windows не хранят куки.Это очевидно убивает сессию немедленно согласно ietf.org/rfc/rfc2109.txt.Я попытался установить SESSION_COOKIE_AGE на 10000, но это не заняло.

Что мне нужно сделать, чтобы стандартный сервер разработки Django отправлял действительные куки на удаленную машину?Я не могу быть единственным ...

Другие подобные сообщения и ссылки на stackoverflow, которые казались многообещающими, но не работали: Почему логин администратора Django дает мне 403 CSRFошибка? Django выводит токен CSRF в качестве объекта вместо значения

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

1 Ответ

2 голосов
/ 20 апреля 2011

Это оказалось второстепенным программным обеспечением, которое не было выключено. В CA Anti Virus был запущен отдельный процесс, который блокировал файлы cookie по факту.

...