Пользователь
0,0
рейтинг
7 июня 2013 в 17:33

Разработка → Как я учился защищать изображения


Изображение защиты

В этой статье хочу изложить нелёгкий путь, который я прошёл «защищая» изображения в вебе. Перед тем, как мы начнём это увлекательное путешествие, хочу обозначить два подхода в деле защиты изображений:
  1. ограничение/запрет постинга прямых ссылок на оригиналы изображений
  2. вы параноик и пытаетесь ограничить распростронение копий изображений

UPDATE
Универсальной защиты конечно же не существует. Статья о том, как не подставлять напрямую данные из GET в SQL-запросы. Только в контексте защиты изображений.


Ограничиваем копии: мой детский велосипед


Вначале моего пути традиционно был велосипед. Много лет тому назад я разрабатывал один замечательный проект. Там было очень много чудесных фотографий животных и природы. Именно эти фотографии (а точнее их полноразмерный вариант) надо было защищать со всей силой. Клиент хотел не просто запретить прямые ссылки на файлы изображений, а лишить пользователя возможнсти скачать эти самые изображения. При этом накладывать водяные знаки не желал.

Мы уже читали о том, что программисты всё время врут. Поэтому пришлось делать то, чего хотел клиент. Решение оказалось вполне даже симпатичным. При запросе страницы с фотографией, мы генерируем некий $secretKey и сохраняем в сессию под этим ключом путь к полноразмерной копии изоражения:

public function actionView()
{
    // ...
    $_SESSION['protected-photos'][$secretKey]['file'] = $photoPath;
    // ...
}

Во вьюшке же указываем путь к фотографии в следующем виде:

<img src="/photo/source/{secretKey}" />

Теперь в actionSource мы получаем из сессии путь к полноразмерной копии фото, отправляем её с правильными заголовками и очищаем путь к полноразмерному файлу:

public function actionSource()
{
    $secretKey= $_GET['key'];
    $session = &$_SESSION['protected-photos'];
    $file = $session[$secretKey]['file'];
    if (is_file($file)) {
        header('Content-type: image/jpeg');
        echo file_get_contents($file);
    }
    $session[$secretKey]['file'] = '';
}

В итоге если пользователь попытается скачать / открыть в новой вкладке / расшарить картинку, ему вернётся её маленькая копия.

Важно: Слабое место такого подхода довольно очевидно: если страницу с фотографией запросить не из браузера, а скажем через wget. В этом случае тег img не сделает запрос /photo/source/{secretKey}. Таким образом он будет содержать полноразмерную копию фотографии.

Ограничиваем прямые ссылки: .htaccess


Позже я узнал, что самый простой и распространённый способ защиты изображений — это настроить соответствующим образом .htaccess. Можно не только запретить прямые ссылки на изображения, но и указать заглушку, которая будет отображаться на сторонних ресурсах вместо оригинальных изображений с вашего сайта. Вот пример такой конфигурации:

RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://(.+\.)?mysite\.com/ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule .*\.(jpe?g|gif|png)$ http://i.imgur.com/qX4w7.gif [L]

Первая строка содержит директиву, которая включает работу механизма преобразований. Здесь всё просто. Второй строкой мы блокируем любые сайты, кроме нашего собственного mysite.com. Код [NC] означает «без вариантов», иными словами регистронезависимое соответствие URL. Третьей строкой мы разрешаем пустые рефералы. И, наконец, последняя строка мачит все файлы с расширением JPEG, JPG, GIF или PNG и заменяет их изображением qX4w7.gif с сервера imgur.com.

При необходимости можно поступть иначе: запретить прямые ссылки на изображения для конкретных доменов.

RewriteEngine On
RewriteCond %{HTTP_REFERER} ^http://(.+\.)?myspace\.com/ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(.+\.)?blogspot\.com/ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(.+\.)?livejournal\.com/ [NC]
RewriteRule .*\.(jpe?g|gif|png)$ http://i.imgur.com/qX4w7.gif [L]

Каждый RewriteCond, кроме последнего, должен содержать код [NC, OR]. OR означает «или следующий», т.е. совпадение с текущим доменом или следующим.

Также вместо изображения-заглушки можно вернуть HTTP ошибку с кодом 403:

RewriteRule .*\.(jpe?g|gif|png)$ - [F]

Важно: не пытайтесь вернуть вместо изображений HTML страницу. Вы можете вернуть либо другое изображение, либоHTTP-ошибку.

Ограничиваем прямые ссылки: nginx


Для nginx всё аналогично:

location ~* \.(jpe?g|gif|png)$ {
        set $bad_ref "N";
        if ($http_referer !~ ^(http://(.+\.)?myspace\.com|http://(.+\.)?blogspot\.com|http://(.+\.)?livejournal\.com)) {
           set $bad_ref "Y";
        }
        if ($bad_ref = "Y") {
           return 444;
        }
}

Update: VBart подсказал в своём комментарии, что намного лучше для этих целей использовать ngx_http_referer_module.

Ограничиваем прямые ссылки: Amazon CloudFront Signed URLs


Amazon CloudFront является одним из лучших вариантов доставки контента пользователям. Помимо своих прямых обязанностей рядового CDN'а, он также даёт возможность генерировать подписанные ссылки. Такие ссылки дают возможность ограничить доступ к файлу по временному диапазону, а также по IP. Таким образом, например, можно указать, что изображение будет доступно в течение 10 минут. Или 7 дней начиная с завтрашнего.

Всреднем, ссылка на файл имеет следующий вид:

1d111111abcdef8.cloudfront.net/image.jpg?2color=red&size=medium3&Policy=eyANCiAgICEXAMPLEW1lbnQiOiBbeyANCiAgICAgICJSZXNvdXJjZSI6Imh0dHA 6Ly9kemJlc3FtN3VuMW0wLmNsb3VkZnJvbnQubmV0L2RlbW8ucGhwIiwgDQogICAgICAiQ 29uZGl0aW9uIjp7IA0KICAgICAgICAgIklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiI yMDcuMTcxLjE4MC4xMDEvMzIifSwNCiAgICAgICAgICJEYXRlR3JlYXRlclRoYW4iOnsiQ VdTOkVwb2NoVGltZSI6MTI5Njg2MDE3Nn0sDQogICAgICAgICAiRGF0ZUxlc3NUaGFuIjp 7IkFXUzpFcG9jaFRpbWUiOjEyOTY4NjAyMjZ9DQogICAgICB9IA0KICAgfV0gDQp9DQo4&Signature=nitfHRCrtziwO2HwPfWw~yYDhUF5EwRunQA-j19DzZrvDh6hQ73lDx~ -ar3UocvvRQVw6EkC~GdpGQyyOSKQim-TxAnW7d8F5Kkai9HVx0FIu-5jcQb0UEmat EXAMPLE3ReXySpLSMj0yCd3ZAB4UcBCAqEijkytL6f3fVYNGQI65&Key-Pair-Id=APKA9ONS7QCOWEXAMPLE

А теперь по пунктам:
  1. Базовая ссылка на ваше изображение. Это ссылка, которую вы использовали для доступа к изображению и ранее, до подписанных ссылок.
  2. Произвольные параметры запроса, которые обычно используются для логирования доступа к изображениям. CloudFront позволяет передавать, кэшировать и логировать эти параметры. Важно: имя параметров не должно совпадать с зарезервированными самим CloudFront: Expires, Key-Pair-Id, Policy, Signature. Лучше всего добавлять к вашим параметрам префикс x-. Это будет особенно полезно, если ваши изображения хранятся на Amazon S3.
  3. Правила доступа к изображениб в JSON-формате и без пробелов (детали).
  4. Хэшированная и подписанная версия правил доступа из предыдущего пункта (детали).
  5. Ключ подписи (детали).

Важно: CloudFront не поддерживает CNAMEs с HTTPS. Т.е. вы не сможете заменить d111111abcdef8.cloudfront.net на images.example.com. Есть два варианта решений проблемы:
  1. Вернуть использование домена https://*.cloudfront.com для изображений.
  2. Оставить домен images.example.com, но использовать его через протокол HTTP.
Выбор одного из двух вариантов по сути это дело вкуса. Принципиально они между собой не отличаются.

Эпилог


Надеюсь описанные выше подходы помогут вам быстрее сориентироваться в нелёгком деле защиты изображений в вебе. И немного полезных ссылок по теме:

  1. Hotlinking: Генератор .htaccess
  2. Hotlinking: Конфигурация .htaccess
  3. Hotlinking: Пример настройки nginx
  4. Hotlinking: Проверка
  5. Amazon CloudFront Signed URLs
Олег Полудненко @uaoleg
карма
51,2
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (121)

  • +9
    А мне вот такой способ защиттить картинки нравится
    image
    • +13
      То ли конец недели, то ли старость… Не могу понять о чём картинка :)
      • +13
        Видимо речь идет о карточке с именем компании.
      • +9
        Фото товара для магазина сделано вместе с карточкой с именем магазина
    • +3
      Телевизионщики еще вот таким пользуются
      Не знаю почему подобные лайтбоксы не популярны, но не хотелось бы чтобы они появлялись.
    • 0
      Пока читал статью пришла забавная на мой взгляд мысль. А что если картинку «резать» скажем на 4 части, и отображать в браузере 4 картинки рядом.
      • +6
        А еще можно генерировать картинку, опять же 4 части которой будут перепутаны местами, а уже средствами js или css приводить ее к нормальному виду.
        • 0
          Можно. Без толку.
          • 0
            Да это понятно. Автор писал о требовании заказчика и вариантах которые он придумал. Я написал пару своих идей по теме. Как уже было сказано, полностью защититься от копирования нельзя.
        • 0
          Интересный вариант.
    • +6
      Именно такие картинки становятся популярными, разлетаясь по всему интернету, причем каждый онлайн магазин\ресурс стирает с карточки изначальные буквы и пишет своё имя.
    • +7
      Спасибо большое
      image
    • +3
      'Да, ничего способ
  • +18
    Расскажите это printscreen'у.
    • +2
      А я разве написал, что изобрёл серебряную пулю? :)
      • 0
        Это была шутка.
    • –2
      Например в Америке, если можно запостить прямую ссылку на изображение — то это не воровство. А если нельзя, но вы её скачаете или спринтскрините и запостите сами, то это уже будет воровством. Со всеми вытекающими.
      • +7
        Это бред как с технической точки зрения, так и с правовой. Такого не может быть ни в одной стране Бернской конвенции, так как противоречит принципу автоматической охраны. Авторы не обязаны генерировать случайные ссылки, накладывать водяные знаки, перекрывать изображения однопиксельным прозрачным img и совершать прочие странные действия.
        • –4
          Это мой личный опыт ;) О чём собственно и статья.
        • +1
          С другой стороны, размещение ссылки в атрибуте source тега img не нарушает авторских прав если разбираться с технической точки зрения, но с юридической может вполне считаться таковым, потому как пользователю предоставляется неотличимая картинка и меньше всего его волнует где хостится файл с графикой.
          • +3
            Под технической стороной я имел в виду невозможность существования такого закона в связи с бесконечным способом подключения изображений. Что если изображение подключается через imagemap? Через CSS? Через canvas? Через SVG? Через iframe с непосредственной загрузкой изображения? А через загрузку страницы с сайта автора через iframe с автопрокруткой до изображения со случайной ссылкой с помощью scrollTo? А если это вообще не браузер, а программа с движком браузера без правил ограничения домена?
            • 0
              Скорее всего конкретно такого закона несуществует. Я полагаю, что это из адвокатской практики. Видимо юристам в США легче доказать факт хищения в случае прямых ссылок.
              • +12
                Я вообще охреневаю от текущего положения вещей.
                Теперь хищение — это не когда у кого-то пропало, а когда у кого-то появилось абсолютно точно такое-же.

                В давнишние времена это бы называлось чудом :)
                • +16
                  Оно и неудивительно, ведь интеллектуальную собственность можно охарактеризовать одним словом: халява.
                  Это халява для пользователей, т.к. они могут без проблем насоздавать столько копий, сколько потребуется.
                  И это халява для владельцев-правообладателей, т.к. заполучив ИС однократно, дальше можно рубить бабло до конца вечности.
                  Так что идёт, по сути, жесточайшая драка за халяву: либо наслаждаться халявой будут пользователи, либо правообладатели. Ну а поскольку нет ничего слаще и желаннее халявы, обе стороны за неё готовы порвать кого угодно.
                  • +1
                    Требую занести это определение в энциклопедии и учебники!
                    Контрастно и лаконично, браво.
              • 0
                Легче как раз в случае реального копирования.
                • 0
                  Не могу ответить аргументированно, я не имею адвокатской практики в США.
            • +1
              Ну, наличие бесконечных способ никогда не останавливало законодателя, особенно в области авторского права — запрещено всё, что явно не разрешено (правообладателем и/или законом) и весь сказ.
              • 0
                Вот-вот, я об этом же :)
      • 0
        Не совсем так. Если можно сделать ссылку, но вместо неё разместишь копию изображения, то будет воровством всё равно, если правообладатель так решит. Наличие или отсутствие технических возможности ничего не значит при юридической оценке. Это как если угонишь машину, то ничего не значит была ли она заперта или нет.

        Ну и есть тревожные звоночки, что ссылки в скором будущем будут однозначно считаться воровством, если нет на то прямого разрешения правообладателя. Это даже не вспоминая про торренты и т. п., а при банальном img.
        • 0
          Я говорил о размещении ссылки не на копию, а на оригинал. А про тревожные звоночки тоже слышал, и это печально.
          • +2
            Так и я о том, что как раз в Америке вроде не один прецедент уже был когда наказывали за ссылку на оригинал. С копией-то и всё так я сно.
  • +1
    Просьба к моим строгим читателям, минусующим пост, оставить также негодующий комментарий.
    • +8
      Я минус поставил. Русский язык в статье местами ужасен:
      — симпотичным
      — ключём
      — в течении

      Сама статья вызвала нейтральные впечатления — вы особо нового ничего не открыли. Но подобные ошибки вызывают стойкое желание дать линейкой по рукам. Читателя надо уважать. Ничего личного, простите.
      • –1
        На сколько я знаю, обычно принято писать об этом автору в личку и он тут же исправляет свою неграмотность. Спасибо за отзыв!
        • +1
          «Вначале, Всреднем» — раздельно.
          • НЛО прилетело и опубликовало эту надпись здесь
            • +3
              Возможно, но глаз режет. Правил я не знаю, но читая много с очень раннего детства ошибки вижу «на глаз».
              Отталкиваюсь от этого: «Вначале моего пути...» = «В самом начале моего пути...»
              • 0
                "В начале моего пути", раздельно, существительное с предлогом.
        • +1
          На просьбу оставить негодующий комментарий обычно принято оставлять негодующий комментарий.
          Мы, IT-шники, люди прямые.
          • 0
            Просто сначала мне показалось что было написано «минус НЕ оставлял» )
    • +8
      Не минусовал, но думаю люди испытывали неудобства от работы на сайтах подобных вашему. Ещё можно понять почему не дают ставить прямые ссылки — трафик который деньги, но пытаться осложнить скачивание картинки глупо т.к. никого не остановит, а лишь вызывает неприятные эмоции.

      Например, только что понадобилось найти в поиске по картинкам фото с инстаграмма, а он не даёт прямую ссылку на фото и пришлось лезть в «Inspect element». В более сложных случаях приходится просматривать весь список картинок и зачем?

      В итоге вы и картинки свои не убережёте и лишних проблем людям доставите. Это как ставить автомобиль на тротуар в надежде, что его не эвакуируют.
      • 0
        люди испытывали неудобства от работы на сайтах подобных вашему

        Сайт не мой :) На этом варианте настоял заказчик. И лично мне этот вариант не нравился. А так я полностью с Вами согласен.
    • –6
      На Хабре сложно рассчитывать на плюсы к посту, рассказывающем о технических средствах защиты авторских прав.
      • +1
        (((
      • +2
        Почему же? Интересно было почитать. Именно с технической точки зрения.
    • +1
      Может я что-то не понимаю в вебе, но разве браузер перед тем как показать картинку не скачивает ее локально на машину? Затем из кеша можно прелестно достать картинку, даже если вы удалите оригинал. То что я не смогу никому отослать ссылку это да, в этом плане все отлично отработано, просто меня смутила фраза «нельзя сохранить»… правой кнопочкой по картинке сохранить как разве не сработает?
      • 0
        правой кнопочкой по картинке сохранить как разве не сработает?

        Да, так не работало. А так конечно, я уже много раз написал, что универсальной защиты быть не может.
  • +5
    А как же запрет контекстного меню и прозрачный gif над изображением? Мои любимые смешные способы защиты.

    А что думаете про подпись изображения в метатегах и жесткие периодические проверки на предмет копий изображений через картинко-поиски с письмами счастья авторам страниц/хостерам?
    • 0
      С контекстным меню вариант мне не очень нравится. А вот прописанные метатеги — это действительно очень хорошее дополнение, спасибо!
    • 0
      Лучше уж тогда картинку в качестве фона прописывать.
      • 0
        Полагаю тогда поисковая выдача пострадает.
        • 0
          Да, для профильных ресурсов это очень критично будет.
          • 0
            Робот все видит, просто он еще и прозрачный gif проиндексирует.
            • 0
              Если целевое изображение будет в виде фона, но это плохо скажется на индексировании. Целевая картинка в фоне — это семантически плохо.
              • 0
                Не обязательно размещать картинку в фон. Это один из методов, но далеко не последний.
                • 0
                  В этой ветке комментариев обсуждается именно фон
                  А про способы я отписал чуть ниже
        • 0
          Как фон не стоит, альт нельзя прописать.
  • 0
    По идее если открыть полноразмерное изображение и сделать принтскрин, то кроме как накладыванием водяных знаков его уже никак не защитить?
    • 0
      Универсальной защиты в принципе не существует, да.
    • 0
      да, от принтскрина/«ножниц» в win7 и от банальной фотосьемки экрана никакие мегатеги и отключения контекстного меню не спасут.
      • +2
        Безусловно. Но если у вас стоит задача украсть 100.000 фото для использования на собственном ресурсе, то ни «ножницы» ни видеосъёмка вам не помогут :) Всегда надо смотреть на соотношение затраченные ресурсы / достигнутая цель.
        • +1
          bash скрипт?
          • 0
            Это уже производительнее :)
          • 0
            ну или powershell/autoit какой.
            Если понимаешь логику способа защиты, взломать и получить желаемое дело навыков автоматизации.
            И это, в общем, печально — идеальная защита — не существует, разве что изображения в каком-нить 640х480 качестве, которое и годится для беглого просмотра…
        • +2
          Картинка в любом случае попадает в кеш браузера, откуда его не так и сложно вытащить. Для «плохого человека», которому надо скачать 100 тысяч фотографий, все ваши способы бесполезны. А вот конечному пользователю они мешают.
          • –2
            Ряд из описанных мною подходов помогают наказывать плохого человека в судебном порядке. А простому пользователю может помешать разве что первый способ, который мне и самому не нравится.
            • 0
              наказывать плохого человека в судебном порядке
              Для этого хватит скормить гуглопоиску по картинкам ваше изображение.
              Посоветуйте «Антисовестин» какой-нибудь пожалуйста, хочу бизнесом заняться.
              • +9
                Инструкция по применению.
                1) Фотографируем смешного котика на тапок
                2) Размещаем у себя на сайте превью 160х120 и продаем фуллсайз 640х480 за 100500 рублей
                3) Сами же сливаем оригинал во вконтактик/фейсбучек под левой учеткой с открытого wifi
                4) Получаем от гуглопоиска ссылки на все копии
                5) Нотариально заверяем скриншоты и отправляемся в суд
                6) Строим себе поместье за счет пожизненных рабов
      • 0
        да, от принтскрина/«ножниц» в win7 и от банальной фотосьемки экрана никакие мегатеги и отключения контекстного меню не спасут.

        Попадал на сайты, на которых на каждой странице размещена флешка, в которой циклом спамится буфер обмена пустыми строками. Понятно, конечно, какие эмоции вызывает такой сайт, даже если не пытаешься сохранять картинки (точнее, особенно если), но если кому-то припёрло «защититься»…
        • +2
          А вот это уже по-моему, под врендоносную программу попадает и/или НСД.
  • +1
    Разве все браузеры заново скачивают картинку при попытке сохранения?
    • 0
      На то время (года 4 назад) все основные браузеры так делали. Как сейчас обстоят дела не знаю.
    • 0
      Я полагаю, смотря какие заголовки изображению выдать.
  • 0
    RewriteCond %{HTTP_REFERER} !^$
    собственно так Вы разрешаете скачивать картинки wget'ом.
    Да и большинство качалок уже по умолчанию подставляют http://[site.com]/ в качестве referrer.
  • 0
    Все хорошо, но от принскрина не спасет )
  • 0
    Я одно время ради любопытства экспериментировал с наложением незаметного для глаза оверлея.
    Это были прямоугольные блоки пикселей со случайной дисперсией. Цвета этих пикселей зависели от изображения, смещались каналы. Таким образом чрезвычайно тяжело вычистить изображение от этих шумов. В автоматическом режиме наверное невозможно. Однако детектировать наличие этой маркировки было легко даже на пересжатом в jpeg изображении с изменением размера (вплоть до 320х240) и нарушением пропорций. Бросил за ненадобностью

    • 0
      Универсальной защиты конечно же не существует. Статья о том, как не подставлять напрямую данные из GET в SQL-запросы. Только в контексте защиты изображений.
      • +8
        Понятно что вы делаете, не до конца понятно зачем.
        У обычных пользователей, которые хотели бы просто сохранить картинку у себя на машине это вызовет лишь негатив. А те, кто хочет переопубликовать все равно вытащат. Подруга как-то раз принтскрином выдергивала мангу на перевод с китайского сайта, а китайцы постарались на славу.

        На странице в iframe размещалась куча абсолютно позиционированных дивов 100х100 пикселей, которым на фон через css файл в виде base64 натянуты тайлы, нарезанные из изображения.

        И что толку — наскринила, перевела, опубликовала.
        • +4
          На странице в iframe размещалась куча абсолютно позиционированных дивов 100х100 пикселей, которым на фон через css файл в виде base64 натянуты тайлы, нарезанные из изображения.

          Китайцы знают толк в извращениях…
        • 0
          Вот это крутая защита.
          А если отдавать не base64, а программу для JavaScript canvas API, то робота-сборщика изображений уже далеко не всякий школьник напишет.
          Открытый вопрос, что делать с поисковиками в таком случае, но тут охота пуще неволи, по всей видимости.
          • 0
            Поисковикам отдавать превью в теге img с нулевым размером и водяным знаком поперек.
          • +3
            canvas API
            Содержимое canvas можно экспортировать тем же API, а в некоторых браузерах даже «сохранить как...»

            робота-сборщика изображений уже далеко не всякий школьник напишет
            Не напишет сборщика, напишет робота-скриншотера

            Все что мы показываем автоматически становится публичным, с этим ничего не поделать
            • +1
              Phantomjs? Headless-браузер прекрасно отрендерит страницу так же, как обычный. И скриншотить руками уже не нужно…
        • 0
          Если Вы обратили внимание, я назвал первый подход «пароноидальным». И даже пометил красным маркером ;) Он мне самому меньшего всего нравится. Но это реальный пример из реального проекта, который успешно живёт по сей день. Именно поэтому я поделился им с коллегами.
    • 0
      Велосипед придумывали?
      Был такой старенький фильтр в фотошопе от Digimarc. Встраивал и читал водяной знак в изображение подобным способом. Да, шумело изрядно, но зато никакая деструктивная коррекция не позволяла от него избавиться. Но, опять же, в конечном счёте от кражи это не защищало, а лишь позволяло определить авторство, да ещё и на сильно «попорченном шумом» изображении.
    • 0
      Напомнило старый метод защиты библиотеки Альдебаран. Там при копировании текста в него вставлялись ошибки и посторонние слова.
  • +1
    мы защищали контент с помощью ngx_access_key_module
    • 0
      Ничего не гуглится на этот счёт. Не могли бы вы дать описание этого подхода?
  • 0
    Главное не забывать отключать защиту для картинок, включаемых в RSS, так как он может показываться на чужих доменах (например, гуглоридер).
  • НЛО прилетело и опубликовало эту надпись здесь
    • –2
      Ваш код наверняка не работает.

      Исправил. Конечно же я не делал копи-паста из реального проекта, код которого принадлежит клиенту. Написал пример код исключительно для наглядности.
      Зачем Вам эта бинарная операция? Вам нужен true?

      Не понял о чём Вы.
      пс: мне всегда было не понятно зачем защищать то, что ты хочешь показывать человечеству? Спрячь и не показывай.

      Уже много раз отвечал на этот вопрос. Даже добавил update в верх поста ;)
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          О да, это явный фэил, исправил.
  • +6
    Для всяких извращений, кстати, есть специальный статус 402 Payment Required.
    • 0
      Не всегда контент платный. Иногда, например, требуется просто запретить прямые ссылки. Но статус однозначно полезный.
      • +1
        Это просто название, более говорящее. Никто реально никогда не платит )
  • 0
    Меня интересует эта строчка RewriteCond %{HTTP_REFERER} !^http://(.+\.)?mysite\.com/ [NC]
    А как сделать, чтобы картинки разрешались на всем моем домене, на котором крутятся три сайта?
    • 0
      Не совсем понял, что значит на «всём»?
      • 0
        Если Вы о поддоменах, то они уже учтены в этом выражении, для них доступ будет открыт.
  • –1
    Вы параноик — ключевое.
  • +2
    Это можно сделать проще, используя две особенности nginx.

    Первая: закрываем прямой доступ к локейшену (/images/*) с помощью директивы internal.
    Вторая: с другого локейшена (/{{ SECRET }}/images/*) возвращаем ответ c заголовком X-Accel-Redirect в котором указываем путь к первому локейшену — это отменяет ограничение, заданное директивой internal и nginx проксирует нужную нам картинку.

    Более подробно можно гуглить по ключевым словам «X-Accel-Redirect internal».
    • 0
      * обработчиком для второго локейшена может быть маленький и, по возможности, быстрый модуль nginx на перле (ngx_http_perl_module), чтобы не проваливаться в медленный бекенд. Быстро сходили в мемкеш, сгенерировали ответ и сразу отпустили процесс nginx.
      • 0
        Интересный вариант. Но, пожалуй, самым лучшим с точки зрения производительности будет использовать Amazon CloudFront с ихними Signed URLs.
  • 0
    Так и не понял, как в итоге автор предлагает защищать картинку. В любом случае, если картинка загрузилась в браузере, можно через меню правой кнопки мыши сохранить или копировать её. Думаю это такое же бессмысленное занятие, как попытка запретить посетителю копировать текст страницы.
    • +1
      А от чего Вы хотите защищать картинки? Если от копирования — то это вряд ли получится, я об этом писал в статье. Да и идею эту назвал пароноидальной. Даже красным маркером пометил ;)

      А если хотите защититься от хотлинкинга, то Amazon CloudFront Вам в этом отлично подойдёт. Или пара других методов, описанных в статье.
      • 0
        Я того же мнения, это просто бессмысленно) Единственный выход — это не выкладывать картинки, которые жалко, в открытый доступ.
        • +1
          Есть вариант с водяными знаками, который активно используется фотобанками. А вообще у Вас же есть замок на входной двери, не смотря на то, что для профи это не помеха ;)
          • 0
            Ну да, это единственный доступный вариант. Хотя при желании можно их удалить фотографии)
          • +1
            За водяной знак вам даже спасибо скажут. Он подмешан к исходной фотографии, а значит элементарно убирается. Где-то видел даже специальные наборы для вычитания под популярные стоки. И даже если ничего подобного нет — сделать элементарно.
            • 0
              Сами по себе эти картинки ещё ничего не доказывают. На сколько я понимаю, всё зависит от метода нанесения водяных знаков.
              • 0
                Верно, есть два решения.
                Первое и очевидное — делать водяной знак непрозрачным. Таким образом часть информации будет безвозвратно утеряно. В прочем это уже с натяжкой можно назвать водяным знаком.
                Второе технологичное — генерировать каждый раз новый водяной знак. Например накладывать его через маску с рандомным шумом. Тогда автоматически вычесть начисто не получится, придется ручками муторно править.
                • 0
                  Можно легко совместить — полупрозрачный, но с рандомным коэффициентом прозрачности.
                  • 0
                    Нет, коэффициент легко подбирается ползунком.
  • 0
    Спасибо за статью. Кстати, запрещая хотлинкинг, желательно убедиться, что картинки смогут «дергать» поисковики и разные полезные сервисы, в которые настроен экспорт контента (если настроен, конечно).

    У нас картинки лежат на S3, хотлинкинг запрещен такой политикой бакета (сработал именно такой вариант, а не тот, который можно встретить в интернете):

    { 
       "Version":"2008-10-17", 
       "Id":"policy1", 
       "Statement":[ 
          { 
             "Sid":"1", 
             "Effect":"Deny", 
             "Principal":{ 
                "AWS":"*" 
             }, 
             "Action":"s3:GetObject", 
             "Resource":"arn:aws:s3:::bucketname/*", 
             "Condition":{ 
                "StringNotLike":{ 
                   "aws:Referer":[ 
                                         "http://*oursiteurl/*",
    				  "http://*feedburner.com/*",
    				  "http://*yandex.ru*",
    				  "http://*google.com*",
    				  "https://*facebook.com/ourname*",
    				  "http://vk.com/ourname*"
                   ] 
                },
    "Null": {
    					"aws:Referer": false
    				} 
             } 
          }, 
          { 
             "Sid":"2", 
             "Effect":"Allow", 
             "Principal":{ 
                "AWS":"*" 
             }, 
             "Action":"s3:GetObject", 
             "Resource":"arn:aws:s3:::bucketname/*", 
             "Condition":{ 
                "StringLike":{ 
                   "aws:Referer":[ 
                                         "http://*oursiteurl/*",
    				  "http://*feedburner.com/*",
    				  "http://*yandex.ru*",
    				  "http://*google.com*",
    				  "https://*facebook.com/ourname*",
    				  "http://vk.com/ourname*"
                   ] 
                } 
             } 
          } 
       ] 
    }
    
  • +3
    Ограничиваем прямые ссылки: nginx

    Для nginx всё аналогично:

    location ~* \.(jpe?g|gif|png)$ {
        set $bad_ref "N";
        if ($http_referer !~ ^(http://(.+\.)?myspace\.com|http://(.+\.)?blogspot\.com|http://(.+\.)?livejournal\.com)) {
           set $bad_ref "Y";
        }
        if ($bad_ref = "Y") {
           return 444;
        }
    }
    

    Это наверное наикривейший способ из тех, что можно было изобрести.

    ngx_http_referer_module + избавиться от программирования на set-ах.
    • 0
      Согласен. Добавлю Ваш вариант в статью. Спасибо.
  • 0
    А вот и Google выкатил возможность накладывать вотермарки на проиндексированные изображения:
    pixabay.com/ru/blog/posts/hotlinking-protection-and-watermarking-for-google-32/

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.