Yii2: ограничить показ(отдачу) файлов в зависимости от роли юзера?

Question

[Микола]

Собственно сабж.
Файл кладу в папку web/tickets/{ID}/file.jpg
Как мне запретить просморт даного файла (даже если у юзера есть прямой линк) если файл не того юзера, что его загрузил?

Comments

[Евгений Безымянников]

Есть модуль nginx который занимается этим. По сути от ждет от php заголовков с редиректом который отмечается в локейшене как внутренний.
nginx.org/ru/docs/http/ngx_http_secure_link_module.html

[Алексей Уколов]

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

[Евгений Безымянников]

Алексей Уколов: Смысл такой, запрос идет на php, там проверяем права и редиректим на внутренний url прямого доступа к файлу и там его nginx отдает.
При этом тайный url не палится.

[Алексей Уколов]

Евгений Безымянников: это больше похоже на то, о чём говорит Vit, но там другая система.

[Евгений Безымянников]

Алексей Уколов: Да.

[Алексей Уколов]

Евгений Безымянников: так а модуль-то, на который вы дали ссылку как работает?

[Алексей Уколов]

Как работает в разрезе вопроса, разумеется, просто описание я по ссылке прочитал.

[Евгений Безымянников]

Алексей Уколов:
*Файл кладете в папку secret/tickets/{ID}/file.jpg
* Ссылку на него даете юзерам web/tickets/{ID}/file.jpg
* В локейшене web/tickets/ направляете все запросы на index.php, в нем проверяете права и возвращаете 404 или 301 на secret/tickets/{ID}/file.jpg .
* Nginx не пускает всех на secret/tickets/{ID}/file.jpg , за исключением внутреннего редиректа из php
* ...
* Profit!!!

Answer 1

[Алексей Уколов]

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

Comments

[Евгений Безымянников]

Александр А: Нормальная практика. нагрузка там мизерная

[Алексей Уколов]

Александр А: чем она плоха и как по-другому решить эту задачу?

[Vit]

Алексей Уколов: плоха тем, что отдача каждого файла блокирует php-процесс. Хороший вариант - использовать php только для проверки доступа, а для отдачи использовать nginx с механизмом x-accel-redirect

[Алексей Уколов]

Vit: согласен, но это имеет значение только для больших файлов или очень медленных каналов.

[Евгений Безымянников]

Александр А: Статистику чего?? Если нужно отдавать несчастных 500-1000 редиректов в секунду когда уже на бд начинает чуть расти нагрузка и надо уже переносить в редис связку файл-юзер, то:
1. такие крупные проекты точно не делают те кто задает такие вопросы.
2. система простая как 5 копеек и переписать на go тот же и связки файл-юзер в редис и на пятибаксовом DO сервере и под 10 тыс запросов вытянет.
3. Нагрузка более будет на БД есл она хитрая по структуре и джойнами тянет, а не 10 строк на php нативном.
4. Преждевременная и избыточная оптимизация не менее зло
5. Статистику на "плохая практика"? Или просто высказывание как "сферический конь в вакууме"? Обоснуйте.

[Евгений Безымянников]

Александр А: 1. файл отдает nginx и php после редиректа в этом не участвует
2. когда проект вырастет уже будут деньги на оптимизацию нечто что и так не тормозит.
3. "не использовать в принципе" - основано на ложном понимании варианта который предложен. Это типичная практика для которой написан модуль.

[Евгений Безымянников]

Александр А: см выше решение с nginx.org/ru/docs/http/ngx_http_secure_link_module.html

Answer 2

[Vit]

Никак не запретить

Неправда. Есть эффективный вариант - nginx и x-accel-redirect. См. тут: https://www.opennet.ru/base/net/nginx_x_accel_redi...
Это намного эффективней чем отдавать через php.

Comments

[Алексей Уколов]

Это намного эффективней

Ненамного.

[Алексей Уколов]

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

[Vit]

Алексей Уколов: Да, не для всех сайтов это может оказаться критично, но тем не менее: если у вас в php-fpm к примеру 20 рабочих процессов, то все они будут блокированы до тех пор, пока 20 пользователей будут качать файл. И пока не скачают, ваше приложение будет представлять из себя тыкву.
Если бы разница все время была ничтожна, как вы пишите, то nginx был бы не нужен, все были бы счастили с апачем.

[Алексей Уколов]

Если бы разница все время была ничтожна, как вы пишите, то nginx был бы не нужен, все были бы счастили с апачем.

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