Django Middleware + URL - PullRequest
Новая
       4

Django Middleware + URL

2 голосов
/ 16 апреля 2009

Может ли промежуточное ПО проверить, есть ли значение в URL, например, идентификатор изображения ("/ image / 152 /"), и если это так, выполните некоторые проверки, чтобы убедиться, что текущий пользователь имеет разрешение на просмотр это изображение, а если не перенаправить на другой URL-адрес?

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

Ответы [ 2 ]

8 голосов
/ 16 апреля 2009

Да, это возможно. Документы промежуточного программного обеспечения django для process_request указывают, что:

def process_request (self, request)

запрос является объектом HttpRequest. Этот метод вызывается при каждом запросе, прежде чем Django решит, какое представление выполнить.

process_request () должен возвращать None или объект HttpResponse. Если он возвращает None, Django продолжит обрабатывать этот запрос, выполняя любое другое промежуточное программное обеспечение и затем соответствующее представление. Если он возвращает объект HttpResponse, Django не будет беспокоиться о вызове ЛЮБОГО другого промежуточного программного обеспечения запроса, представления или исключения или соответствующего представления; он вернет этот HttpResponse.

Объект HttpRequest имеет атрибут path, который даст вам запрошенный URL.

Однако, если вы предпочитаете, обратите внимание, что вы также можете расширить систему Django для бэкэндов аутентификации, чтобы заполнить пользователя в запросе разрешениями, основанными на любых произвольных критериях, таких как, возможно, ваша откатанная вручную схема разрешений. Таким образом, вы можете использовать декораторы аутентификации по умолчанию (@permission_required и @user_passes_test), и другие приложения / администратор сайта также смогут соблюдать ваши разрешения. Созданный объект User и разрешения не обязательно должны находиться в таблицах пользователей / разрешений Django и могут создаваться виртуально при входе в систему; У меня было достаточно успеха с этим.

См. Написание аутентификационного бэкэнда , если это подходит.

0 голосов
/ 25 августа 2010

Если вы внедрите авторизацию (систему разрешений) в промежуточном программном обеспечении, у вас будет два варианта:

  1. Проверьте URL и разрешите доступ
  2. Проверьте URL и отклоните доступ

Если ваше требование настолько простое, это нормально, так как вам не нужно прикасаться к просмотрам.

Но в целом, система разрешений гораздо сложнее, например:

  1. Пользователь может получить доступ к FOO / show_all /
  2. Но он не может видеть или получить доступ к экземпляру foo, т.е. FOO / show / foo_1 /
  3. Так как он не может получить доступ к экземпляру foo_1, мы не должны показывать их в show_all (все экземпляры foo)

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

Чтение: http://docs.djangoproject.com/en/dev/topics/auth/#handling-authorization-in-custom-backends

...