問題は、CDN が 破綻した 動作を示している点です。これは明らかに避けるべきものです。正しく動作するのは非 CDN の方だけで、例えば「ダウンロード」をクリックすると、何かが実際にダウンロードされます。
なるほど、では修正しましょう。
なるほど。ライトボックスのカスタマイズ例で、着手の参考にできるものはありますか？
これは以下の通り、容易にハッキングされるものではありません：
Magnific Popup: Responsive jQuery Lightbox Plugin を読み込み、それがどのように動的に再設定可能かを確認する必要があります。
残念ですが、何か解決策を見つけられるか確認してみます。
単なる好奇心なんですが、なぜ Discourse はここで「ダウンロード」アクションを選択して「フルサイズで表示」を選択しないのでしょうか？ユーザーの視点から見ると、フルサイズで表示する方がより一般的な行動のように思えるのですが？
MIME の問題かと思っていたのですが、ヘッダーを見ると、もしかすると以下の可能性があります：
x-download-options: noopen
これは、ファイルをダウンロードした際に開くのを防ぎます。Sam さんが明確にしてくださることを願っています。
これは @codinghorror の判断だと思います。元のアップロードファイル名をきれいに保持できる方法の一つでしょうし、それを気にする人もいます。それに、Flickr も同様のことをしているようです。
この辺りは変更しないでしょう。専用ルートなどでアプリがプロキシするだけになるはずです。「ダウンロード」をクリックする人はごく少数なので、CDN を迂回しても問題ないかもしれません。いずれにせよ、@pmusaraj が最善策を判断してくれるでしょう。私の理解では、AWS に特別なコンテンツDisposition付きの署名付きURLを発行させるか、ファイルをプロキシするかのどちらかです。どちらの場合も S3 CDN の迂回が必要になります。アプリ経由でプロキシすれば、少なくともアプリの CDN を利用できます。
もう少し読むと、content-disposition: attachment; と x-download-options: noopen がこの動作の原因のようです。
「どうなっているか」は理解できましたが、「なぜそうなのか」についてはまだ不明です。もしセキュリティ上の理由であれば、それは非常に理にかなっています。
この PR は、以下の方法でこれを修正するはずです：
- S3 アップロードが有効な場合、lightbox のダウンロードリンクに
data-download-hrefを追加する - 使用される URL は、
dl=1パラメータを含む新しい短縮 URL スキームであり、これによりコントローラーが正しいコンテンツDispositionとファイル名を持つ署名付き S3 URL を生成する
つまり、lightbox 内のダウンロードリンクは、/uploads/short-url/mTGbg4Ld2iBYAbfTvEjGXP2LtVm.pdf?dl=1 のようになります。これは、content-disposition: "attachment; filename=original.png" を持つ署名付き S3 URL にリダイレクトされます。
これは最もシンプルで直接的なオプションだと考えられます。アプリを介してプロキシすると、ダウンロードされたファイルが S3 から Discourse サーバーを経由してクライアントに送られる必要があるため、わずかに効率が低下します。