不正な設定のサイトからの壊れたonebox画像の処理

「ホットリンク」をブロックするさまざまな手法を採用しているが、埋め込みデータ(メタデータなど)には画像のリンクをそのまま返している、設定が不適切なサイトをかなり多く見かけます。

http://debug.iframely.com/ で確認したところ、これは Discourse 自体の問題というよりは、見た目が悪くなっているように思えます。

一つのアイデアとして、投稿を調理(cooking)する際にワンボックス生成が画像を取得し、後で提供するためのサムネイルを保存するか、取得できない場合は画像が指定されていないかのように振る舞う方法があります。

画像のコピーを保存すれば、かなり堅牢で将来にも対応でき、著作権の観点からも「フェアユース」の範囲内だと考えられます(元のサイトは、メタデータから取得した 130x90 のサムネイルを再利用しても不利益を被ることはないはずです。ただし、私は法律の専門家ではありません)。

それが不可能な場合、画像のエラーイベントをキャッチして、画像またはそのラッパーに display:none クラスを追加するコンポーネントを作成しようと試みました。しかし、decorateCookedElement() で行き詰まってしまい、まだ成功していません。私が探している場所が正しいのかどうかもわかりません。

ワンボックス内で画像が壊れて表示されることに頻繁に悩まされているのは私だけでしょうか?回避策を持っている人はいますか?

すでにその機能は実装されていますよ。もう一度投稿を確認してください!

もちろん、投稿の「調理」時に実行されるわけではありません。そのクリティカルパスにウェブリクエストを置かないためです。代わりに、バックグラウンドでキューイングしてワンボックスの画像をダウンロードしています。

「リモート画像をローカルにダウンロード」が有効(デフォルトで true)の場合、編集の猶予期間(デフォルト 300 秒)が経過してからダウンロードを実行します。

「いいね!」 4

素晴らしい!

「ボックス設定」の下を探していたため、「リモート画像をローカルにダウンロード」という項目(無効化されていました)に気づいていませんでした。

これを有効にし、いくつかの投稿のHTMLを再構築しました。これでいくつかの問題が整理されることを願っています。

ヒントをありがとうございます :heart:

「いいね!」 2

ありがとうございます!
実は、別のトピックでもこれについて質問していました。

「いいね!」 1

デフォルト設定を変更する際は、その影響を慎重に検討することが重要です。当製品は最適な設定で出荷されていますが、それらから逸脱すると意図しない結果を招く可能性があります。

「いいね!」 1

それはもっともなご指摘ですね。一般的にはデフォルト設定のままにしていますが、今回のケースでは以前的管理者が設定を変更したようです。なぜ変更されたのかはわかりません。

これで、Instagram のワンボックス内に表示される画像も永続的に表示されるようになることを願っています。

改めてありがとうございます。Discourse に愛をこめて :heart:

「いいね!」 2

はい、onebox は以前よりもずっと良いフィードバックを提供します。onebox ができない場合、その理由を説明しようと最善を尽くします。

「いいね!」 1