Прежде всего убедитесь, что для параметра SESSION_COOKIE_SECURE установлено значение false.Пока домены одинаковы, куки в браузере должны присутствовать и информация о сеансе должна оставаться там.
Посмотрите на ваши куки с помощью плагина.Найдите сессионный cookie, который вы установили.По умолчанию эти куки называются «sessionid» от Django.Убедитесь, что домены и пути действительно правильные как для безопасного сеанса, так и для обычного сеанса.
Однако я хочу предупредить об этом.В последнее время такие вещи, как Firesheep, использовали проблему, о которой люди давно знали, но игнорировали, что эти cookie-файлы никоим образом не защищены.Для кого-то было бы легко «перехватить» cookie-файл по HTTP-соединению и получить доступ к сайту, когда вы вошли в систему.Это по существу устраняет всю причину, по которой вы создали защищенное соединение для входа в систему.
Есть ли причина, по которой у вас нет безопасного соединения по всему сайту?Традиционные аргументы о том, что он более интенсивен на сервере, на самом деле больше не применимы к современным процессорам, и эксплойты, на которые я ссылаюсь выше, становятся настолько распространенными, что предельные (действительно предельные) затраты на шифрование всего вашего трафика вполне стоят того.
Apache должен иметь по существу 2 разных сервера, работающих, потому что: а) он прослушивает 2 разных порта и б) один добавляет дополнительную логику шифрования.Тем не менее, это нормальная вещь для Apache.Я запускаю серверы с десятками «серверов», работающих на разных портах и выполняющих разную логику.По большому счету, это на самом деле не должно приводить к снижению нагрузки на ваш сервер.
Тем не менее, если вы передадите тот же запрос в * WSGI или mod_python, вам потребуется логика, чтобы никто не могпытается войти через незашифрованное соединение, потому что единственным отличием от Django будет ответ в request.is_secure ().Все URL-адреса и представления в вашем urlconf будут доступны.
Вот как много.Я надеюсь, что это помогает.