Как Вы Требуете Входа в систему для Медиа-файлов в Django

Это не плохое высокоуровневое описание. Вот некоторые дополнительные соображения:

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

Шифрование включает хранить некоторые секретные данные, и безопасность секретных данных зависит от хранения отдельного "ключевого" сейфа от плохих парней.

Путаница скрывает некоторую информацию без отдельного ключа (или с фиксированным ключом). В этом случае хранить в тайне метод состоит в том, как Вы бережно храните данные.

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

27
задан TomFuertes 11 July 2009 в 20:26
поделиться

3 ответа

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

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

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

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

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

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

РЕДАКТИРОВАТЬ 2: Что касается кода для обслуживания файла, см. Этот фрагмент:

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

9
ответ дан 28 November 2019 в 05:52
поделиться

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

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

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

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

3
ответ дан 28 November 2019 в 05:52
поделиться

Если я правильно понял ваш вопрос, вы хотите ограничить доступ к файлам, которые не обслуживаются 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 все могло измениться. :)

1
ответ дан 28 November 2019 в 05:52
поделиться
Другие вопросы по тегам:

Похожие вопросы: