Вопрос

Я предоставляю "конфиденциальную" информацию в загружаемых PDF-файлах и электронных таблицах в разделе регистрации пользователя на сайте.

Есть ли способ разрешить аутентификацию django для защиты этого носителя без обслуживать его (и не нужно вручную входить в систему, используя basic auth)?

Я предполагаю, что там (скрестив пальцы) не способ сделать это с помощью приведенного ниже псевдокода, но он помогает лучше проиллюстрировать конечную цель.

#urls.py
(r'^protected_media/(?P<filename>.*)$', 'protected_media')

#views.py
from django.contrib.auth.decorators import login_required

@login_required
def protected_media(request, filename):
    # @login_required bounces you out to the login url
    # if logged in, serve "filename" from Apache
Это было полезно?

Решение

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

Я что-то упускаю из вашего вопроса здесь?Пожалуйста, уточните, так ли это.

Редактировать:Что касается ссылки на django doc в вашем комментарии:это метод для простого обслуживания любого файла запроса из определенного каталога.Итак, в этом примере URL-адреса, подобные /site_media/foo.jpg, /site_media/somefolder/bar.jpg будет автоматически искать файлы foo.jpg и somefolder/bar.jpg под document_root.В принципе, каждая вещь под document_root будет находиться в открытом доступе.Это явно небезопасно.Таким образом, вы избегаете этого с помощью своего метода.

Это также считается неэффективным, потому что django просто добавляет много ненужных накладных расходов, когда все, что вам нужно, это что-то вроде Apache, чтобы принять запрос URL и сопоставить его с файлом на жестком диске.(Вам не нужны сеансы django, обработка запросов и т.д.)

В вашем случае это может быть не такой уж большой проблемой.Во-первых, вы обеспечили просмотр.Во-вторых, это зависит от ваших шаблонов использования.Сколько запросов вы ожидаете на эти файлы?Вы используете django только для аутентификации - оправдывает ли это другие накладные расходы?Если нет, вы можете рассмотреть возможность обслуживания этих файлов с помощью Apache и использования поставщика аутентификации.Подробнее об этом читайте в mod_wsgi Документация:

Существуют аналогичные механизмы, доступные в mod_python Я верю.(Обновление:только что заметил другой ответ.Пожалуйста, ознакомьтесь с ответом Андре на mod_python метод.)

ПРАВКА 2:Что касается кода для обслуживания файла, пожалуйста, смотрите этот фрагмент:

В send_file метод использует FileWrapper, который хорош для отправки больших статических файлов обратно (он не считывает весь файл в память).Вам нужно было бы изменить content_type в зависимости от типа файла, который вы отправляете (pdf, jpg и т.д.).

Другие советы

Читать это Билет на Джанго для получения дополнительной информации.Начните с самого низа, чтобы сэкономить себе немного времени.Похоже, он просто не попал в Django 1.2, и я предполагаю, что его нет и в 1.3.

Для Nginx я нашел это Фрагмент Django это использует преимущества заголовка X-Accel-Redirect, но я его еще не пробовал.

В настоящее время в рамках проекта Google SOC рассматривается возможность более эффективного обслуживания статических файлов с помощью Django.Для WSGI это будет использовать расширения wsgi.file_wrapper для WSGI, если они доступны, как и для mod_wsgi, и req.sendfile(), если используется mod_python.Он также будет поддерживать возврат заголовков, таких как 'Location', 'X-Accel-Redirect' и других, которые различные механизмы веб-хостинга и интерфейсы прокси-серверов принимают в качестве средства обслуживания статических файлов, где местоположение определяется внутренним веб-приложением, которое не так эффективно, как внешний интерфейс для обслуживания статических файлов.

Я не уверен, есть ли где-нибудь страница проекта для этого в Django wiki или нет, но изменения кода фиксируются в ветке branches /soc2009 /http-wsgi-improvements репозитория исходного кода Django.

Вам не нужно строго ждать этого материала.Это просто создание чистого и переносимого интерфейса для различных механизмов.Если вы используете nginx в качестве интерфейса перед Apache / mod_wsgi, вы могли бы использовать X-Accel-Redirect прямо сейчас.При использовании Apache / mod_wsgi 3.0 и режима daemon вы могли бы использовать Location сейчас, но необходимо убедиться, что вы правильно настроили Apache.В качестве альтернативы, вы могли бы реализовать свою собственную оболочку промежуточного программного обеспечения WSGI вокруг приложения Django, которая ищет некоторый собственный заголовок ответа, чтобы указать файл, который должен быть возвращен, и которая использует wsgi.file_wrapper для возврата этого вместо фактического ответа, возвращаемого из Django.

Кстати, механизмы подключения аутентификации, перечисленные другими как для mod_python, так и для mod_wsgi, будут использовать базовую аутентификацию HTTP, а это не то, что вы хотели.Это предполагает, что вы хотите, чтобы файлы были защищены механизмом входа на основе формы Django, использующим файлы cookie и серверные сеансы.

Если я правильно понял ваш вопрос, вы хотите ограничить доступ к файлам, которые не обслуживаются Django, например, с помощью сервера Apache?

Затем вам потребуется какой-нибудь способ, чтобы этот сервер Apache использовал Django в качестве источника аутентификации.

Это фрагмент django описывает такой метод.Он создает обработчик доступа в Django, который используется Apache при поступлении запроса на статический файл, который необходимо защитить:

<Location "/protected/location">
            PythonPath "['/path/to/proj/'] + sys.path"  
            PythonOption DJANGO_SETTINGS_MODULE myproj.settings
        PythonOption DjangoPermissionName '<permission.codename>'
        PythonAccessHandler my_proj.modpython #this should point to accesshandler
            SetHandler None
</Location>

Надеюсь, это поможет, фрагмент был опубликован некоторое время назад, так что все могло измениться между версиями Django :)

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top