CODEのWOPIホストチェックを修正し、ホストオリジンを一致させる

Collabora Online CODEが「認証されていないWOPIホスト」と報告した場合、CODEのWOPIホスト許可リストに実際のファイルストレージホスト（通常はNextcloudオリジン）を追加してください。ホストは、Collaboraサーバーの公開URLではなく、CODEがWOPIリクエストで受け取るオリジンと一致する必要があります。Dockerでは、これは通常、aliasgroup1環境変数で設定されます。

CODEが拒否している内容

WOPIとはWeb Application Open Platform Interfaceの略で、オフィスサーバーがストレージプラットフォームを介してファイルを開いたり保存したりするために使用するプロトコルです。WOPIホストはNextcloudなどのストレージプラットフォームです。CODEは、WOPIリクエストで指定されたホストを、信頼できるホストと照合します。リクエストで指定されたホストがcloud.example.com、CODEが信頼するように設定されているホストのみを信頼する場合office.example.com、エディタはセッションを開く前に拒否することができます。

セルフホスト環境の場合、リクエスト内のホスト名は、nextcloudブラウザに表示されるホスト名ではなく、内部のDocker名（例：）になることがあります。リバースプロキシ、異なるポート、またはパブリックURLと内部URLの分離によっても、オリジンが異なる可能性があります。リクエストが実際に使用するホスト名を設定し、「メイン」サーバー名に見えるものだけを設定するのではなく、実際のオリジンを設定してください。

ホストCODEが拒否しているものを見つけてください

1. 一度障害を再現し、その時間帯のCODEコンテナのログを確認してください。Docker Composeを使用する場合は、をサービス名にdocker compose logs --since=10m collabora置き換えて を実行してください。collabora
2. のようなメッセージを探してくださいNo acceptable WOPI hosts found matching the target host [cloud.example.com] in config。括弧内に表示されているターゲットホストを記録してください。WOPI URL全体をコピーしたり共有したりしないでください。有効期限の短いアクセストークンが含まれている可能性があります。
3. そのホスト名とスキームを、ストレージ統合がCODEに通知するURLと比較してください。Nextcloudのトラブルシューティングガイドでは、設定されているURLがNextcloudのURLであり、CODEがそのURLにアクセスできることを確認することを推奨しています。WOPISrcクエリ文字列トークンは非公開にしたまま、統合ログにホスト名が記録されている場合は、そのホスト名を確認してください。

CODEで正しいオリジンを許可する

公式のCODE Dockerイメージの場合は、aliasgroup1信頼できるWOPIオリジンを正確に設定してください。単一のNextcloudインストールの場合、Composeサービスには以下を含めることができます。

services:
  collabora:
    image: collabora/code
    environment:
      aliasgroup1: "https://cloud.example.com:443"

例の部分を、実際の Nextcloud ホストと WOPI リクエストで使用するスキームおよびポートに置き換えてください。Compose ファイル内の既存のイメージ タグ、管理者設定、ネットワーク、その他のサービス オプションはそのままにしておいてください。この例ではポート 443 の HTTPS オリジンを使用していますが、別のデプロイメントでは別のポートまたは内部オリジンを使用する場合があります。

Compose ファイルを編集した後、更新された環境を受け取るように CODE コンテナを再作成します。

docker compose up -d --force-recreate collabora

の代わりに、実際の Compose サービス名を使用してくださいcollabora。単純な再起動では、変更されたコンテナ環境値がロードされない場合があります。サービスを再作成すると、更新された構成が適用されます。CODE を XML ファイルで構成する場合は、storage.wopi代わりに有効な構成のエイリアス グループを確認してください。公式の Collabora SDK マニュアルには、Docker エイリアス グループと WOPI ホスト エイリアスが記載されています。使用している CODE のバージョンに応じた構文に従ってください。

2つの許可リストは別々に保管してください。

CollaboraとNextcloudはそれぞれWOPI関連の制限を適用できるが、それぞれ異なる疑問に答えるものだ。

Nextcloudの送信元IPアドレスの許可リストを変更しても、CODEがホスト名を拒否する問題は解決しません。逆に、CODEにホスト名を追加しても、NextcloudでCODEの送信元IPアドレスが許可されるわけではありません。Nextcloudのドキュメントでは、WOPIリクエストをCollaboraサーバーのIPアドレスに制限することを推奨しています。コンテナやリバースプロキシが関与している場合は異なる可能性があるため、Nextcloudが認識するアドレスを使用してください。

インシデントをクローズする前に簡単なチェックを行う

• Target はcloud.example.com、その Nextcloud ホストと適切なオリジンを CODE で許可します。
• Target は次のように述べていますnextcloud: CODE はおそらく Docker ネットワークのホスト名を受信して​​います。その内部オリジンが意図されたものかどうかを判断し、対応する信頼できるホストを構成して、DNS とネットワークの到達可能性を確認してください。
• ターゲットは一致していますが、同じ拒否が残っています。編集された変数が実行中のCODEサービスに属していること、Composeがコンテナを再作成したこと、および後続の環境またはXML構成によって設定が上書きされていないことを確認してください。
• ログがDNS、TLS、タイムアウト、またはCheckFileInfoの失敗を示すようになった場合、ホスト認証チェックが合格している可能性があります。WOPIホストリストを拡大するのではなく、名前解決、証明書の信頼性、ルーティング、またはストレージ統合のファイル情報応答を調査してください。
• Nextcloud から不正なリクエスト アドレスが報告されました。Nextcloudの送信元 IP 許可リストと、実際に Nextcloud が認識しているクライアント IP を確認してください。

本番環境では、すべてのホストを信頼したり、無制限のワイルドカードを使用したりして不一致を解決しないでください。許可リストは、既知のストレージオリジンに限定してください。複数のストレージホストを意図的に使用する場合は、ワイルドカードの動作を推測するのではなく、インストールされているCODEバージョンのドキュメントに記載されているエイリアスグループを設定してください。

修正を確認してください

失敗したのと同じ Nextcloud 連携を使用してドキュメントを開きます。次に、新しい CODE ログを確認します。「許容できる WOPI ホストがありません」という拒否メッセージは消えているはずです。ドキュメントが読み込まれ、保存できることを確認します。新しいエラーが表示された場合は、そのメッセージを使用して次のレイヤーを特定します。2 つのホストチェックと Nextcloud のトラブルシューティング フローについては、Nextcloud Office のトラブルシューティングとNextcloud Office の構成を参照してください。CODE Docker エイリアス グループについては、 Collabora Online SDK 25.04 マニュアルを参照してください。構成が異なる場合は、インストールされているリリースに対応するドキュメントを使用してください。