23 марта 2021 в 12:08
Есть ли возможность скрыть оригиналы фото (доступ по прямой ссылке) которые находятся в папке с общедоступными файлами ("Конфигурация - Мультимедиа - Файловая система" - "Общедоступный путь файловой системы" ). Но при этом сохранить функционал (автосоздание стилей при сбросе кэша и т.п.)
Сейчас достаточно удалить пару каталогов в url фото что бы без проблем открыть оригинал.
https://drupal.ru/node/136745 - похожая теме без ответа...
Комментарии
Запросы фото по прямым ссылкам обрабатываются непосредственно веб-сервером безо всякого участия Друпала. Что если в настройках веб-сервера (.htaccess etc) закрыть доступ к оригиналам фото?
Пробовал. Добавлял в корень с фото "Deny from all" (для файлов ico|jpg|jpeg|png|gif|) - в этом случае для новых фото не создаются стили ("мультимедиа" - "стили изображений" ).
Это надо делать только для директории(й) с оригиналом, а не глобально.
Только для директории с фото и делал. В ней лежат и папки со стилями (в них наоборот добавлял хтаксесс с разрешениями)
Если всё так, и правильно работает, это не мешает создавать и отдавать порезанные картинки, и всё должно работать... Надо смотреть логи, и проверять .htaccess.
Оригинал и стили не могут лежать в одной папке. Стили друпал хранит в отдельной папке styles
так и есть: "в отдельной папке styles" в папке с фото
Утверждение в корне НЕ верно.
P.S. Для примера, удали любой стиль и затем открой его по прямой ссылке... Друпал его заново сгенерирует.
P.P.S. Есть нюансы с imagick и кривыми конфигами сервака.
Вообще говоря, верно. Запрос к существующему файлу, в большинстве конфигураций обработается без участия php. Веб сервер просто отдаст файл. А вот если файла не будет, может передать обработку дальше. Там было об этом написано.
Странно - казалось бы для создания стилей друпал добывает исходный файл не по HTTP, а непосредственно открывает файл на диске, где ему настройки веб-сервера не указ... А запрет доступа к фото точно касался только оригиналов и не захватывал директории со стилями?
для директорий стилей писал свои htacсess (наоборот разрешал. хотя и без них работает)
Тогда сдаюсь...
поисковым ботам надо отдавать картинку с маленьким разрешением - превью например, а каталог с большим разрешениями запретить сканировать и запретить на внешнюю отдачу. Тогда и поисковики довольны и овцы целы. В картинках поисковиков не будет картинок с большим разрешением, и интерес любителей вставлять
палки в колесапрямые ссылки на картинки резко упадет.Еще вариант
проверять токены, если запрос идет без токена - от ворот поворот.
Никак, только переводить файлы в приватные и ставить контриб Image Style Access (в нем можно оригиналы скрыть).
Конечно, можно костыль написать, но тогда потеряете попап-превьюшку оригинального фото в редактировании.
P.S. "Похожая тема" - она совсем о другом.
Утверждение на 146% верно.
Естественно, потому что ошибка (отсутствие файла) передается на обработку Друпалу. Но если файл существует, то он отдается непосредственно веб-сервером, минуя Друпал. Это всё прямо прописано в .htaccess (для тех кто умеет его читать, конечно).
"У нас есть такие приборы!"(с)
Нет. Только, если есть какое-то статик-кэширование, то возможно.
В курсе, что мир одним apache не ограничивается?
Да. Кэширование ни при чем.
"Срезал!"© ;)))
Ты хочешь сказать, что под Апачем паблик-файлы отдаются напрямую, а под nginx или там iis пропускаются через Друпал? Я в шоке если честно, от тебя никак не ожидал...
PS Проведи небольшой эксперимент. На каком-нибудь дев-сайте удали или переименуй index.php. Сайт перестанет открываться. Теперь попробуй открыть любой существующий графической файл - хоть оригинал, хоть уже заведомо сгенеренный стиль. Открывается?
Понял. Мы про разные контроли и не/доступность папки через браузер говорим...
P.S. В контексте топика, как и говорил, только в приватные переводить и контриб.
А разве есть контриб, чтобы на приватные файлы делать публичные миниатюры?