1つのFessで複数の仮想ホストを使うとき、検索結果だけでなく、文書IDを指定して取り出す経路も確認しておきたいところです。文書IDによる取得に、通常検索と同じ仮想ホストの条件を加える修正がマージされました。
ロールが同じでも仮想ホストが違う場合
従来のgetDocumentByDocIdとgetDocumentListByDocIdsはロールの条件を適用していましたが、仮想ホストの条件がありませんでした。利用者のロールが一致すると、別の仮想ホストに属する文書をID経由で取得できる場合がありました。
修正は、v2のキャッシュAPI、/go/による転送、サムネイル、お気に入りなどで使う共通の文書取得処理に条件を加えます。対象文書の仮想ホストが現在のリクエストと違えば、取得処理は文書を返しません。各エンドポイントの応答形式はそれぞれの実装に従います。
有効になる条件と例外
新しいオン・オフ設定は追加されません。リクエストから仮想ホストのキーが解決された場合、そのキーと文書のvirtual_hostフィールドを照合します。キーが設定されたリクエストでは、仮想ホストの値を持たない文書も通常検索と同様に対象外です。
初期設定のindex.field.virtual_hostはvirtual_hostで、virtual.host.headersは空です。ただし、この値だけでリクエストにキーが付くわけではありません。既存の仮想ホスト設定と、実際に解決されるキーを確認してください。
キーが解決されないデフォルトホストやリクエストのないバックグラウンド処理には、この条件は加わりません。管理者検索の一覧取得も対象外です。この変更を、すべての経路を無条件に分離する仕組みとして扱うことはできません。
更新前後で試したいこと
同じ検索ロールの利用者を使い、ホストAの文書がAの通常検索とキャッシュで表示されること、ホストBから同じIDを使った取得では返らないことを確認します。仮想ホスト未設定の文書と、管理者検索も別に試します。
通常検索の条件を共通の取得処理へそろえる修正なので、文書を登録し直すこと自体は変更の必須条件ではありません。ただし、既存文書の仮想ホスト値が誤っている場合は、元のクロール設定と再登録を含めて修正します。ユーザータグの仮想ホスト別管理とは別の変更です。