Приветствую тебя, %имя%.
Как правильно построить логику безопасного механизма создания изображений на лету?
В моей архитектуре все изображения раздаются с отдельного домена.
Например
img.site.com/user/ab/cd/abcd22352435245.jpg
Нужно уметь получать тумбы динамических размеров.
В ходе размышлений я пришел к такому рецепту:
1. В ссылке на изображение можно указать что мы хотим.
Например:
img.site.com/user/ab/cd/abcd22352435245.jpg@100x100
2. Далее Nginx пытается найти файл и если не находит - редиректит на php обработчик.
3. Обработчик генерирует изображение и отдает его клиенту предварительно сохранив на диск, чтобы в следующий раз php не запускался.
Но в этом всем есть один минус - можно забить сервер копиями изображения с клиента.
Как вариант, можно разрешить генерировать только некоторые размеры. Но не буду же я для каждой картинки указывать разрешенные размеры.
Так же была мысль при построении html-ответа собирать все пути картинок требуемых на странице и с сервера, перед отдачей клиенту html, слать запрос по API на сервер картинок с командой "Создай эти размеры". Но это сильно затормозит ответы клиенту.
Третим вариантом я рассматриваю шифрование в имени картинки данных об ее оригинале и требуемых размерах.
Например есть файл:
http://img.site.com/cache/{base64hash}.jpg
{base64hash} - это хэш, в котором указано "/path/to/origin.jpg:100x100:salt"
Если Nginx увидит что картинки нет, передаст работу php а уже там расшифруется имя, поймем что требуется, создадим файл и отдадим картинку. Не будет ли проблем с длинной имени файла?
Как решают эту задачу грамотно с учетом всех нюансов?