Как включить аутентификацию на сайте Django и прозрачно сохранять любые данные POST или GET?

Question

Предположим, кто-то редактирует HTML-форму, и время ожидания сеанса истекло, как можно заставить Django повторно аутентифицировать этого пользователя без потери содержимого, введенного пользователем в форму?

Фрагмент Фрагменты Django:Требовать входа на весь сайт предлагает, как выполнить аутентификацию по всему сайту, но я ожидаю, что при этом будет потерян компонент GET строки (а именно потому, что request.path его не включает) и, безусловно, будут потеряны данные POST.

Как можно сохранить СООБЩЕНИЕ и преодолеть эти неудобные тайм-ауты?Я нахожу, что усовершенствованные веб-сайты, как правило, справляются с этим разумно, и я хотел бы иметь возможность делать это в Django (как и другие, я полагаю!).

Мысли были бы оценены по достоинству.Спасибо.

Answer 1

У меня есть два предложения.

Перенаправление / Промежуточное программное обеспечение

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

1. Если вы не вошли в систему, запишите данные GET и POST в промежуточном программном обеспечении и сохраните их в сеансе
2. Если пользователь аутентифицирован, проверьте наличие значений, установленных в #1.Если они существуют, измените запрос.ПОЛУЧИТЕ и запросите.ОПУБЛИКУЙТЕ, чтобы отразить это, и удалите данные сеанса.

Я думаю, что это должно работать чисто, и многие люди сочли бы это полезным.Это был бы отличный пост на djangosnippets.org.

Техника Ajax

Это менее практично, если у вас уже есть обработка форм, но может улучшить пользовательский интерфейс.Если вы публикуете асинхронно, ваш обработчик Javascript может распознать код ответа "требуется вход", а затем отобразить всплывающее диалоговое окно с запросом входа.По завершении пользователь может повторно отправить форму.

Answer 2

Добавить onsubmit обработчик всех ваших форм, который будет проверять сеанс через JS и запрашивать use для входа в систему, прежде чем продолжить.Таким образом, отправка формы на самом деле не произойдет до того, как пользователь снова войдет в систему.

И убедитесь, что вы убедились, что вошедший в систему пользователь остается одним и тем же во время всех сеансов.

Answer 3

Это не совсем специфично для Django, но специфично для HTTP (Без состояния)...В случае, если система заканчивает выдачу перенаправления при обработке POST (переключение на ПОЛУЧЕНИЕ из исходного POST) и риск потери данных, следует где-то сохранить данные (db, memcached и т.д.) И сделать так, чтобы ключ, под которым они хранятся, передавался через аутентификацию (или другой) процесс.

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

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

Answer 4

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

Без сеансов я бы сделал что-то похожее на ответ Дэниелса, т. е.поймайте исходное сообщение / ПОЛУЧИТЕ в промежуточном программном обеспечении, но я бы изменил перенаправление, чтобы включить опубликованную информацию.

Это проще для GETs и обычно представляет собой просто полную getString, закодированную в компоненте перенаправления URL-адреса входа.

Для сообщений вы можете либо преобразовать в метод get, который отлично работает для небольших форм, но для больших форм, которые сделали бы URL-адрес слишком длинным, я бы сделал репост, разместив данные в форме входа, возможно, в кодированном виде, и сохранив их в одном скрытом (на самом деле почти как .net viewstate)

Сделать это в django сложно, так как вы не можете выполнить перенаправление, поэтому я бы использовал промежуточное программное обеспечение для ручного вызова login view и записи в HttpResponse оттуда.Редактировать После еще некоторого изучения этого, по-видимому, на стороне magic admin в django уже реализовано нечто подобное, как было обнаружено Джерри Стрэттон

Выглядит как хороший вариант.Я попробую это и оставлю отзыв.