Django + apache: HTTPS только для страницы входа - PullRequest
1 голос
/ 10 августа 2011

Я пытаюсь выполнить следующее поведение:

Когда пользователь получает доступ к сайту посредством: http://example.com/ Я хочу, чтобы он был перенаправлен на: https://example.com/

В промежуточном программном обеспечении, если пользователь не вошел в систему, шаблон входа обрабатывается при доступе к /. Если пользователь вошел в систему, / является основным видом. Когда пользователь входит в систему, я хочу, чтобы сайт работал по http.

Для этого я использую один и тот же сервер на портах 80 и 443 (действительно ли это необходимо? У меня сложилось впечатление, что я использую два отдельных сервера с одним и тем же приложением, а мне нужен сервер, прослушивающий два порта) .

Когда пользователь уходит от входа в систему, из-за перенаправления на http-сервер данные в request.session отсутствуют (хотя они присутствуют на https), таким образом показывая, что пользователь не вошел в систему. Итак, учитывая правильную настройку apache (запуск одного и того же сервера на двух разных портах), я думаю, мне нужно передать cookie с сервера, работающего по протоколу https, в http.

Кто-нибудь может пролить свет на это? Спасибо

1 Ответ

0 голосов
/ 10 августа 2011

Прежде всего убедитесь, что для параметра SESSION_COOKIE_SECURE установлено значение false.Пока домены одинаковы, куки в браузере должны присутствовать и информация о сеансе должна оставаться там.

Посмотрите на ваши куки с помощью плагина.Найдите сессионный cookie, который вы установили.По умолчанию эти куки называются «sessionid» от Django.Убедитесь, что домены и пути действительно правильные как для безопасного сеанса, так и для обычного сеанса.

Однако я хочу предупредить об этом.В последнее время такие вещи, как Firesheep, использовали проблему, о которой люди давно знали, но игнорировали, что эти cookie-файлы никоим образом не защищены.Для кого-то было бы легко «перехватить» cookie-файл по HTTP-соединению и получить доступ к сайту, когда вы вошли в систему.Это по существу устраняет всю причину, по которой вы создали защищенное соединение для входа в систему.

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

Apache должен иметь по существу 2 разных сервера, работающих, потому что: а) он прослушивает 2 разных порта и б) один добавляет дополнительную логику шифрования.Тем не менее, это нормальная вещь для Apache.Я запускаю серверы с десятками «серверов», работающих на разных портах и ​​выполняющих разную логику.По большому счету, это на самом деле не должно приводить к снижению нагрузки на ваш сервер.

Тем не менее, если вы передадите тот же запрос в * WSGI или mod_python, вам потребуется логика, чтобы никто не могпытается войти через незашифрованное соединение, потому что единственным отличием от Django будет ответ в request.is_secure ().Все URL-адреса и представления в вашем urlconf будут доступны.

Вот как много.Я надеюсь, что это помогает.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...