Как стать автором
Обновить

Комментарии 16

4) Заходим в панель управления доменным именем domain.com и создаем поддомены, аналогичные названиям бакетов. В IN A записи прописываем Endpoint из настроек бакета.


Не уверен, что такое IN A на domain.com, но видимо это A record. В таком случае endpoint надо прописывать не в A но в CNAME.
Спасибо. Действительно «поспешил». Разумеется CNAME. Исправил.
> класс для криптования в RC4
Как же это небыстро, наверное работает. Плюс, имя нечитаемое. Чем вам не угодил вариант photo15_100x100.fd34ab89.jpg, где fd34ab89 — md5 от photo15_100x100 и пароля?

Еще не понял, зачем понадобилось 4 бакета.
4 бакета для балансировки. чтобы параллельно загружать в браузере
Все верно. Браузер одновременно с одного домена загружает не более чем в 4 потока (могу ошибиться с числом). Для того, чтобы оптимизировать скорость загрузки страницы в целом — статический контент мы вынесли на отдельные поддомены. И чем больше их будет, тем быстрее страница загрузится. Нам для миниатюр хватило 4.
Cейчас их в среднем по больничке 6 по умолчанию (4 было этак лет 5 назад).
Спасибо за вопрос. Из описания действительно не очень понятно, что сами изображения «не наши». Речь идет о «каталоге товаров» в который компании могут загружать свои xml прайс листы, в которых в свою очередь есть ссылки на изображения товаров на «их» сайтах (сайтах компаний).
Ссылки там настолько разнообразные, что простым photo15_100x100 у нас не получилось «отделаться». Пришлось изобретать велосипед, для того.

Что касается скорости работы RC4 и md5 — скажу честно — не замеряли.
Я без s3, но с подобным алгоритмом делал.
Пользователь обращался к nginx по адресу: /thumb/2013/08/120/160/12345.jpg
Nginx проверял существование файла, и если не находил — перенаправлял запрос в php скрипт.
Дабы папки не содержали по 100500 файлов, делил по месяцам.
/миниатюры/год/месяц/ширина/высота/id.jpg. Скрипт отображал клиенту миниатюру и клал сгенерированный результат по нужному пути. Следующий клиент смотрел миниатюру уже без участия php.
Это я все к чему, я не понимаю, зачем использовать криптовые ссылки?
обычно используют не криптованные ссылки, а подписанные. Смысл в том, чтобы защититься от такой зловредной атаки — мы делаем универсальный скрипт для тумб, и он может делать тумбы любого размера. Поэтому враг может генерировать много запросов для картинок разного размера, и таким образом забить дисковое пространство. В отдельных случаях и процессорные мощности играют роль, ибо ресайзинг требует проц, но главное таки место.
Если ссылка подписанная, то мы можем быть уверены, что сгенерированна она именно нашим скриптом.
Автор использовал именно шифрование потому, что в его приложении не было никакого смысла сохранять хоть что-то от исходного названия — они у него непригодны для жизни.
ИМХО шифрование должно быть тяжеловатым, но это только теория.
А может отресайзить 1 раз все нужные размеры?
Можно и даже нужно. И желательно в фоне.
Но, когда добавляется еще один «тип миниатюры», а в проекте уже имеется довольно большое количество исходных изображений, то проще клиенту отдавать динамику по запросу. И, конечно же, никто не запрещает фоном запустить процесс прегенерации миниатюры для других изображений.

Т.е. речь идет об использовании обоих подходов: генерация по запросу + прегенерация при загрузке или добавлении новых «миниатюр».
Как по мне — все зависит от ситуации.
Как я уже говорил, в нашем случае — картинки находятся на сторонних сайтах. Мне не кажется логичным «вытягивать» их все т.к. большинство из них вообще могут и не отобразиться в на сайте во многих размерах.
Возьмем к примеру товар мобильный телефон. В нашей БД к нему есть N ссылок на изображения:

h t t p: / / fptshop.com.vn/Content/Images/uploaded/Phone%20IMG/SONY/Sony%20Xperia%20V%20LT25i%20d.jpg
h t t p: / / w w w .mobile-review.com/review/image/sony/xperia-v-fl/01.jpg
h t t p: / / i1-news.softpedia-static.com/images/news2/IFA-2012-Sony-Xperia-V-Hands-on-6.jpg?1346338399
h t t p s: / / encrypted-tbn1.gstatic.com/images?q=tbn:ANd9GcTl0rA49eQb3TgPzec7qPcGUPqPoa4Y5aTMsswD2nPTK1eTbVr8

Ко всем из них нужно сделать миниатюры. Разумеется крипт для формирования ссылки не самый красивый вариант. Нас он устроил.
Не забывайте, если запрос попадает в скрипт, мы получаем «безграничные» возможности для работы с изображением, в том числе, мы можем сделать валидацию. Например ограничить варианты размеров, проверить реферала и принадлежность миниатюры к странице etc. Как по мне, так это вполне себе надежно и защитит от атаки. Конечно, все может быть сложно и валидацию не всегда можно сделать.
Вы бы еще HttpRedirectCode указали в конфиге. А то амазон по умолчанию отправляет 301.
Так как я не возвращал картинку из своего кода, а делал обратный редирект на амазон — зацикливание встретило меня.
Спасибо! А Вы планируете класс S3 переписать под работу c их новым шифрованием AWS4-HMAC-SHA256?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории