Clever Geek Handbook

画像を保護する方法を学んだ方法



保護イメージ


この記事では、Web上の画像を「保護」するハードな方法を説明します。 この魅力的な旅を始める前に、画像を保護する2つのアプローチの概要を説明します。

  1. 元の画像への直接リンクの投稿の制限/禁止
  2. あなたは妄想的で、画像のコピーの配布を制限しようとしています


更新

普遍的な保護は確かに存在しません。 この記事では、GETのデータをSQLクエリに直接代入しない方法について説明します。 画像保護のコンテキストでのみ。





copiesコピーの制限：私の子供用自転車



私の旅の初めには、伝統的に自転車がありました。 何年も前、私は素晴らしいプロジェクトを開発していました。 動物や自然の素晴らしい写真がたくさんありました。 あらゆる力で保護されなければならなかったのは、これらの写真（というよりは、フルサイズのバージョン）でした。 クライアントは、画像ファイルへの直接リンクを禁止するだけでなく、ユーザーがこれらの同じ画像をダウンロードできないようにしたいと考えていました。 同時に、透かしを課したくありませんでした。



プログラマーは常にうそをついていることをすでに読んでいます。 したがって、私はクライアントが望んだことをしなければなりませんでした。 解決策はとてもきれいでした。 写真付きのページをリクエストする場合、特定の$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



タグはrequest /photo/source/{secretKey}



作成しません。 したがって、写真のフルサイズのコピーが含まれます。



direct直接リンクを制限する：.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]


最初の行には、変換メカニズムの操作を含むディレクティブが含まれています。 ここではすべてが簡単です。 2行目は、mysite.com以外のサイトをブロックします。 コード[NC]は「オプションなし」、つまり、大文字と小文字を区別しないURL一致を意味します。 3行目では、空の紹介を許可しています。 最後に、最後の行では、拡張子がJPEG、JPG、GIF、またはPNGのすべてのファイルをダウンロードし、それらをサーバーimgur.comのイメージqX4w7.gifに置き換えます。



必要に応じて、別の方法で行うことができます。特定のドメインの画像への直接リンクを禁止します。 



 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は「または次」を意味します。 現在のドメインまたは次のドメインと一致します。



また、スタブイメージの代わりに、コード403でHTTPエラーを返すことができます。 



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


重要：画像の代わりにHTMLページを返そうとしないでください。 別の画像またはHTTPエラーを返すことができます。



direct直接リンクを制限する：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; } }


更新： VBartはコメントで、これらの目的にはngx_http_referer_module



を使用する方がはるかに良いと提案しました。



direct直接リンクを制限する：Amazon CloudFront署名付きURL



Amazon CloudFrontは、ユーザーにコンテンツを配信するための最良のオプションの1つです。 通常のCDNとしての彼の直接的な義務に加えて、彼は署名付きリンクを生成する機会も与えます。 このようなリンクにより、時間範囲およびIPごとにファイルへのアクセスを制限できます。 したがって、たとえば、10分以内に画像が利用可能になるように指定できます。 または、明日から7日間です。



平均して、ファイルへのリンクは次のとおりです。



1 d111111abcdef8.cloudfront.net/image.jpg?



2 color=red&size=medium



3 &Policy=eyANCiAgICEXAMPLEW1lbnQiOiBbeyANCiAgICAgICJSZXNvdXJjZSI6Imh0dHA 6Ly9kemJlc3FtN3VuMW0wLmNsb3VkZnJvbnQubmV0L2RlbW8ucGhwIiwgDQogICAgICAiQ 29uZGl0aW9uIjp7IA0KICAgICAgICAgIklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiI yMDcuMTcxLjE4MC4xMDEvMzIifSwNCiAgICAgICAgICJEYXRlR3JlYXRlclRoYW4iOnsiQ VdTOkVwb2NoVGltZSI6MTI5Njg2MDE3Nn0sDQogICAgICAgICAiRGF0ZUxlc3NUaGFuIjp 7IkFXUzpFcG9jaFRpbWUiOjEyOTY4NjAyMjZ9DQogICAgICB9IA0KICAgfV0gDQp9DQo



7IkFXUzpFcG9jaFRpbWUiOjEyOTY4NjAyMjZ9DQogICAgICB9IA0KICAgfV0gDQp9DQo 4 &Signature=nitfHRCrtziwO2HwPfWw~yYDhUF5EwRunQA-j19DzZrvDh6hQ73lDx~ -ar3UocvvRQVw6EkC~GdpGQyyOSKQim-TxAnW7d8F5Kkai9HVx0FIu-5jcQb0UEmat EXAMPLE3ReXySpLSMj0yCd3ZAB4UcBCAqEijkytL6f3fVYNGQI6



〜-ar3UocvvRQVw6EkC〜GdpGQyyOSKQim-TxAnW7d8F5Kkai9HVx0FIu-5jcQb0UEmat EXAMPLE3ReXySpLSMj0yCd3ZAB4UcBCAqEijkytL6f3fVYNGQI6 5 &Key-Pair-Id=APKA9ONS7QCOWEXAMPLE







次に、ポイントについて：

  1. 画像へのベースリンク。 これは、署名済みリンクの前に、以前にイメージにアクセスするために使用したリンクです。
  2. イメージアクセスのログに一般的に使用される任意のクエリパラメーター。 CloudFrontでは、これらのパラメーターを転送、キャッシュ、およびログに記録できます。 重要：パラメーター名は、CloudFront自体によって予約されているものと一致してはなりません： Expires 、 Key-Pair-Id 、 Policy 、 Signature 。 パラメータにx-プレフィックスを追加することをお勧めします。 これは、イメージがAmazon S3に保存されている場合に特に便利です。
  3. スペースなしでJSON形式の画像にアクセスするためのルール（ 詳細 ）。
  4. 前の段落のアクセスルールのハッシュ化および署名されたバージョン（ 詳細 ）。
  5. 署名キー（ 詳細 ）。


重要： CloudFront はHTTPSを使用したCNAMEをサポートしていません 。 つまり 交換できません d111111abcdef8.cloudfront.net



d111111abcdef8.cloudfront.net



on images.example.com



images.example.com



。 この問題には2つの解決策があります。

  1. イメージのhttps://*.cloudfront.com



    使用を返します。
  2. ドメインimages.example.com



    はそのままにしますが、HTTPプロトコルで使用します。
2つのオプションのいずれかを選択することは、基本的に好みの問題です。 基本的に、それらは互いに異ならない。



▌エピローグ



上記のアプローチが、Web上の画像を保護するという困難なタスクをすばやくナビゲートするのに役立つことを願っています。 そして、トピックに関するいくつかの便利なリンク：



  1. ホットリンク：.htaccess Generator
  2. ホットリンク：.htaccess設定
  3. ホットリンク：nginxの構成例
  4. ホットリンク：検証
  5. Amazon CloudFront署名付きURL


More articles:


All Articles