Pull to refresh

Comments 25

Я использовал такую систему и не раз в разных проектах, только хеши не применял. Так в чем изюминка статьи?
Я же написал — «Простые решения». Я видел много проектов, где такая схема не применяется, эта статья для них.
Ну… Давайте же поддержим Mail.ru бурными аплодисментами ))
А как насчет возможного совпадения хешей для разных URL или тел изображений? Или я один из немногих, у кого паранойя по этому поводу?
Это может случиться, но, я думаю, это слишком редкая ситуация в реальном мире. А если уже совсем хочется перестраховаться, можно хешировать двумя алгоритмами(например md5+sha1) и, соответственно, сохранять два хеша.
Я один раз зашел на какой-то сайт и увидел ошибку о невозможности вставки сгенерированного хеша в таблицу сессий из-за уникальности колонки. После рефреша всё стало хорошо. Так что моя паранойя только укрепилась.
Это нельзя считать фактом коллизии, т.к. легко могло произойти из за того, что совпали строки из которых вычислялся md5, например генератор ID сессии
Всем, кто боится коллизий в md5:
1) 2 ^ 128 это ОЧЕНЬ БОЛЬШОЕ ЧИСЛО. Количество элементарных частиц во Вселенной меньше.
2) найденные коллизии, которых все боятся — это результат кропотливого подбора параметров с глубоким пониманием алгоритма MD5, а не просто «вдруг совпало».

Поэтому вероятность найти коллизию у двух файлов, или урлов, или любых других данных произвольно взятых из WWW не просто мала, а охренеть как мала. Если не использовать специализированные алгоритмы подбора для нахождения коллизий до конца существования человеческой цивилизации можно не волноваться.

Проблема коллизий в md5 на самом деле в другом — если у вас УЖЕ ЕСТЬ фиксированное сообщение, от которого считается хеш, то тогда возможно нахождение коллизии. Но для этого нужно очень сильно потрудиться.
Если что-то плохое может произойти, то оно обязательно произойдет :)
Любой алгоритм хеширования будет иметь колизии, так как из нескончаемого множества сообщений получается вполне конечное множество хешей.

Но алгоритм хеширования считается стойким если никому не удалось найти два разных сообщения с одинаковым хешом.

md5 — считается не стойким, уже найдено много разных сообщений с одинаковыми хешами.
sha1 — не могу точно утверждать, но помоему пары находились
sha256 — еще не найдено колизий.

Используйте sha256, а найденая колизия — большая удача, переведт алгоритм в категорию не стойких.
Я не утверждаю, что md5 является стойким алгоритмом. Еще раз повторяю, если есть готовое сообщение (файл) то намеренно подобрать другое сообщение(файл) с тем же md5 реально. Для решения задач обеспечения безопасности md5 сейчас действительно недостаточно.

Но для данной задачи его более чем достаточно. Самое худшее развитие в случае коллизии — фотография не загрузится, а будет использоваться другая, загруженная ранее. Можно вполне смириться с этим.

Плюс sha256 еще и медленнее md5 (вроде в несколько раз)
По чистке фото можно так:

1. Определяем сколько хранятся фото. Пусть три месяца.
2. Находим все фото старше трех месяцев.
3. Если фото устарело — удаляем. Если нет — делаем touch и забываем о нём на три месяца.

Таким образом при каждой чистке нужно смотреть только те фото, которые вот-вот стали старше трех месяцев, а не все подряд.
Мне вот что интересно, какова вероятность загрузки той же фотки?
Можно же смотреть на хеши и цеплять уже загруженную, вместо crop/resize/etc
Или это экономия на спичках?
Дык вроде именно про это статья. Мы именно смотрим на хеши и цепляем уже загруженную вместо crop/resize/etc. И второй раз никогда этого не делаем
Не ожидал такой простой темы от mail.ru. А расскажете как храните ресайзы? Я в данный момент храню картинки в папках ceil(id/10000), а ресайзы в подпапках, что не совсем удобно.
Это разумный комментарий, плюсанул его, действительно тема очень простая.
Тем не менее у многих знакомых на проектах такая схема не используется, т.к. эта задача очень часто решается в лоб. Еще раз повторяю, это простое решение, я и не претендовал за представление нового супер-алгоритма
Ресайзы мы храним просто набором файлов с соотв. постфиксами, типа
/a7/b8/a7b8a284fb75cf4c41913679b5b56a9b_530x240.jpg
/a7/b8/a7b8a284fb75cf4c41913679b5b56a9b_200x100.jpg
и т.п.
Так удобнее для формирования урлов, чистки и переезда на новые схемы. Мы храним лишь несколько базовых размеров, а все остальные (всего у нас около десятка) ресайзим на лету, используя ближайший подходящий размер и nginx.

Кстати, возможно, скоро парни напишут про результаты исследования нескольких алгоритмов ресайза и их слепое тестирование на дизайнерах, думаю будет интересно.
Для фотографий более приятный результат получается с небольшим добавлением шарпинга после ресайза
У нас для данной задачи время обработки фотографии один из важнейших параметров. А дополнительные фильтры сразу увеличивают время обработки в разы. Когда писали краулер, пробовали несколько вариантов, в т.ч. и с sharpen, но как то не удалось подобрать комбинацию, удовлетворяющую нас по скорости и качеству, по моему дело было в артефактах, которые иногда давал sharpen. Поэтому мы ограничиваемя только ресайзом
Спасибо за ответ. Часто встречаю такой способ хранения, но почему то забыл о нем, когда писал модель. Возможно, это хороший способ, но разве такой способ позволяет избежать хранение более 10000 файлов в одной директории?
Приходится делать мелкие шарды, как раз чтобы не плодить кучу файлов в каталоге. Кроме того базовых размеров не так много (по моему 3 или 4), остальные нарезаются из них на лету.
Можно body_hash фотки считать на клиенте и не загружать фотку на сервер, если она уже там есть.
Мы использовали стандартный загрузчик фоток, и не стали копать в эту сторону, а мысль очень здравая, спасибо.
не секьюрно получается. легким движением руки можно проверить есть ли фотография в сервисе.
У нас были полностью публичные картинки, распространять которые собственно и являлось основной задачей сайта :) Можно, наверное, прятать оригинал фотки, и выкладывать обработанную версию, хешировать тоже по ней (с пострипанным EXIF-ом, заресайзенную, с нашим водяным знаком, тогда одним движением не получится — проверящему придется сделать нужную обработку собственной фотки.
Only those users with full accounts are able to leave comments. Log in, please.