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

Открытый характер Интернета не мешает кому-либо использовать URL-адрес вашего изображения на своем личном веб-сайте или в приложении. Или загрузив свое изображение и сохранив его на свой компьютер, а затем используя его на своем веб-сайте или в приложении. В этом посте рассматриваются несколько основных методов, которые могут снизить вероятность прямого использования вашего URL-адреса на своем веб-сайте или в приложении (первая из двух проблем, упомянутых выше).

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

Для этого поста мы будем использовать следующее изображение в качестве примера.

https://ik.imagekit.io/demo/img/tr:f-jpg/medium_cafe_B1iTdD0C.jpg

Теперь предположим, что для предотвращения неправильного использования или, по крайней мере, чтобы получить заслуженное признание за изображение, вы хотите наложить на изображение водяной знак. Кроме того, вместо того, чтобы делиться большим исходным изображением, допустим, вы хотите использовать изображение размером 500 x 500 пикселей. Вы можете сделать это с помощью Photoshop или любого другого программного обеспечения для редактирования изображений. Но это не масштабируется, если вы обрабатываете несколько тысяч изображений.

Если бы вы использовали службу преобразования изображений в реальном времени, такую ​​как ImageKit, вы можете получить необходимое изображение, указав это изменение этих преобразований в URL-адресе. Обратите внимание, что URL-адрес содержит tr: h-500, w-500, oi-logo-white_SJwqB4Nfe.png, чтобы указать высоту (h), ширину (w ) и накладываемое изображение (oi).

http://ik.imagekit.io/demo/img/tr:f-jpg,h-500,w-500,oi-logo-white_SJwqB4Nfe.png/medium_cafe_B1iTdD0C.jpg

Сама цель преобразований на основе URL-адресов - обеспечить гибкость при различных операциях с изображениями. Это означает, что любые преобразования, применяемые к URL-адресу, можно изменить или удалить из URL-адреса, чтобы получить другой вариант изображения. Третья сторона с намерением злоупотребить вышеуказанным URL-адресом может просто изменить строку преобразования и получить доступ к изображению без водяных знаков с измененным размером, подобным этому.

http://ik.imagekit.io/demo/img/tr:h-500,w-500/medium_cafe_B1iTdD0C.jpg

Чтобы предотвратить это несанкционированное изменение преобразованного изображения, вот несколько методов, которые в определенной степени предотвратят несанкционированное использование ваших URL-адресов изображений или предотвратят изменение URL-адресов ваших изображений без авторизации. Эти методы характерны не только для ImageKit, но даже для сервера изображений, который вы, возможно, захотите создать.

1. Ограничения трансформации

Ограничение разрешенных преобразований изображений - самый простой способ предотвратить изменение URL-адресов изображений. Это то, что вам нужно будет закодировать на своем сервере изображений. Входящий запрос преобразования проверяется на соответствие разрешенным преобразованиям. Если совпадение найдено, то изображение обслуживается, в противном случае клиенту отправляется соответствующий ответ об ошибке.

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

Недостаток: преобразования изображения привязаны к пользовательскому интерфейсу вашего приложения. Любое обновление пользовательского интерфейса, которое требует преобразования нового изображения, потребует изменения в логике приложения, чтобы разрешить новое преобразование. Список потенциально может стать недоступным в течение многих лет разработки и изменений конструкции.

2. Ограничения на основе подписи

Вам не нужно проверять каждое преобразование изображения с карты, чтобы подтвердить его достоверность. В конце концов, основная проверка, которую нам нужно сделать, - это то, что URL-адрес изображения был получен из авторизованного источника.

Для этого всякий раз, когда ваш сервер приложений создает URL-адрес изображения, он должен вычислять дайджест HMAC-SHA1 (или любой хэш) всех преобразований в URL-адресе и имени изображения и использовать секретный ключ, который известен только вашему серверу приложений. и ваш сервер изображений. Этот хэш необходимо передать как параметр запроса или параметр пути к URL-адресу изображения.

Например,

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

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

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

3. Ограничения на основе подписи со сроком действия.

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

Предположим, вы хотите, чтобы URL-адреса автоматически истекали в конце месяца (выбор такого срока действия имеет другие преимущества, такие как CDN и кеширование на стороне клиента). Это означает, что даже если кто-то получит URL-адрес изображения из вашего приложения, он сможет использовать его только до конца текущего месяца. После этого для того же изображения потребуется новый URL.

Для этого мы получим временную метку UNIX конца текущего месяца, то есть предполагаемое время истечения срока действия. Таким образом, если текущий месяц - декабрь 2016 г., мы получаем метку времени 31 декабря 2016 г., 23:59:59. Эта временная метка - 1483208999. Мы будем использовать эту временную метку для вычисления хэша HMAC-SHA1, а также добавим ее в качестве параметра в URL-адрес.

Например,

Затем сервер изображений проверит соответствие хеш-значения преобразований, имени изображения и отметки времени истечения срока действия. Только в том случае, если хэш действителен, а отметка времени истечения срока в URL-адресе все еще находится в будущем, только тогда изображение может быть обслужено. Кроме того, если кто-то попытается изменить время истечения срока действия в URL-адресе или полностью его удалит, хеш станет недействительным. То же самое, когда кто-то пытается изменить преобразование изображения.

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

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

Делитесь своими предложениями и отзывами о вышеуказанных методах. Или, если вы используете какой-либо другой метод в своей организации, поделитесь ими в комментариях для других читателей.