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

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

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

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

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

Ответы [ 4 ]

3 голосов
/ 25 февраля 2009

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

Redirect / Middleware

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

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

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

Техника Ajax

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

2 голосов
/ 25 февраля 2009

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

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

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

2 голосов
/ 25 февраля 2009

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

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

0 голосов
/ 25 февраля 2009

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

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

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

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

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

Похоже, хороший вариант. Я попробую это и обратная связь.

...