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

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

Фрагмент Django Snippets: Require login at all site предлагает, как выполнить аутентификацию на всем сайте, но я ожидаю, что он потеряет компонент GET строки (а именно потому, что request.path не включает его) и определенно потеряет данные POST.

Как можно сохранить POST и GET через эти неудобные тайм-ауты. Я считаю, что утонченные веб-сайты, как правило, справляются с этим разумно, и я хотел бы иметь возможность делать это в Django (как и другие, я думаю!).

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


authentication python django middleware wsgi
person Brian M. Hunt    schedule 24.02.2009    source источник
comment
Изучив вопрос и доступные ответы, я предлагаю вам заменить формы и django-middlewear на wsgi и промежуточное ПО, чтобы привлечь больше экспертов. Вопрос связан с WSGI, а не с Django.   -  person myroslav    schedule 25.02.2009

Ответы (4)


arrow_upward
3
arrow_downward

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

Редирект/промежуточное ПО

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

  1. Если вы не вошли в систему, захватите данные GET и POST в промежуточном программном обеспечении и сохраните их в сеансе.
  2. Если пользователь аутентифицирован, проверьте значения, установленные в #1. Если они существуют, измените request.GET и request.POST, чтобы отразить их, и удалите данные сеанса.

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

Аякс техника

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

person Daniel Naab    schedule 25.02.2009

arrow_upward
2
arrow_downward

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

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

person Alexander Lebedev    schedule 24.02.2009

arrow_upward
2
arrow_downward

Это не совсем специфично для Django, но специфично для HTTP (без сохранения состояния)... В случае, если система завершается выдачей перенаправления при обработке POST (переключение на GET из исходного POST) и рискуя потерять данные, нужно где-то хранить данные (db, memcached и т. д.) и сделать так, чтобы ключ, под которым они хранятся, проходил через процесс аутентификации (или другой процесс).

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

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

person myroslav    schedule 24.02.2009

arrow_upward
0
arrow_downward

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

Без сеансов я бы сделал что-то похожее на ответ Дэниела, т. е. поймал бы исходный POST/GET в промежуточном программном обеспечении, но я бы изменил перенаправление, чтобы включить опубликованную информацию.

Это проще для GET, и обычно это просто полная строка GET, закодированная в компоненте перенаправления URL-адреса входа.

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

Выполнение этого в django сложно, поскольку вы не можете выполнить перенаправление, поэтому я бы использовал промежуточное программное обеспечение, чтобы вручную вызывать представление входа в систему и писать оттуда в HttpResponse. РЕДАКТИРОВАТЬ После некоторого изучения этого, по-видимому, волшебная сторона администратора fo django уже реализовала нечто подобное, как было найдено Джерри Стрэттон

Вроде хороший вариант. Я попробую и отпишусь.

person RonaldHobbs    schedule 25.02.2009