NB 2013 年 3 月 26 日 -- 元の回答を撤回する必要があるため、お詫び申し上げます。
HTTP_REFERER (つづりがいつも間違っている) は、簡単に偽装できるため、セキュリティ上信頼できないことが判明しました。
元のアイデアの一部を以下に残します。何をすべきでないかを示しているためです。安全であると信じていますが、最初に代替案を提示します。
キーベースの代替手段の基本的な課題は、Web サイト外のファイル アクセスのロックを解除するために送受信されるものが、PDF.js が実際に実行されてアクセスを要求するブラウザーを介してさまざまな方法で表示されることです。これは、認証メカニズムがメイン画面を回避する場合や、SSL を使用してチャネルを保護する場合でも当てはまります。
現時点で思いつく最善の方法は、時間制限付きの鍵ですが、これには実際的な困難があることを認めています。ただし、時折 Web の速度低下が見られる場合でも、ドキュメントのダウンロードの開始時にキー アクセスが発生するため、時間枠はかなり短い可能性があります。
SSL は、高度なセキュリティ対策の要件です。そうしないと、ネット接続がスヌープされ、タイムアウト内にキーが再利用される可能性があります。PDF.js を起動する認証システムは、PDF.js がコールバックしてアクセスするために使用するキーのドキュメント ゲートウェイと連携する必要があります。これは、CMS データベースが満たすオンサーバー メッセージングを使用して行うことができます。
したがって、これは 1 時間で完成するものではないにしても、可能な設計のように見えます。本来のユーザーログインだけでなく、時間ベースのキーにも SSL が使用されている場合、実生活の人事要素も含めて、オンライン バンキングと同じくらい安全であると考えられるかもしれません。
参考までに、元の欠陥のあるアイデアの意味を次に示します。
.htaccess 条件を使用して、ローカルで提供された pdf.js ファイルのアクセス許可のみを、pdf を保持するディレクトリに許可することにより、ファイルを保護するための簡単な、しかし今では間違った答えが見られました。pdf.js はファイル空間ではなく Web 空間にアクセスするため、そのディレクトリは Web サイト内にある必要があります。URL と pdf.js の場所に合わせて調整できる条件と応答の形式を次に示します。
Options -Indexes
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^(http|https)://(www.)?yourdomain\.com/yourfolder/s/pdf\.js$
RewriteRule .* - [F]