Fessでファイルの所有者と最終更新者を検索する

Fessがクロールしたファイルに、所有者ownerと最終更新者last_modifierを記録する変更が入りました。検索結果の表示と詳細検索から、担当者を手がかりに資料を探せます。

どの情報を取り込むか

所有者はSMB、ローカルファイルシステム、FTPクライアントが取得したファイルのメタデータを使います。DOMAIN\aliceのような値はドメイン部分を除き、aliceを記録します。

最終更新者はOffice文書などから抽出するmeta:last-authorを優先し、なければ所有者を利用します。WebのHTMLにはファイル所有者がありませんが、HTTPで取得したOfficeファイルの最終更新者は対象になります。既にメタデータマッピングで値を設定している場合は上書きしません。

初期値と検索方法

fess_config.propertiesでは両方とも初期状態で有効です。

crawler.document.file.owner.enabled=true
crawler.document.file.last.modifier.enabled=true

個別のクロール設定のパラメーターではconfig.owner.enabled=false、config.last.modifier.enabled=falseのように上書きできます。所有者を無効にした場合は、最終更新者への代用にもその所有者を使いません。

標準bootstrapテーマの結果情報に値を表示し、詳細検索にも入力欄を追加します。検索例はowner:alice、last_modifier:"Taro Yamada"です。部分一致ではなく、keyword型の値との完全一致を使います。APIでもfields.owner=aliceによる絞り込みやfacet.field=ownerの集計に利用できます。

既存インデックスの移行

既存の文書インデックスには新フィールドのマッピングを自動追加しません。次のクロールの前に、管理画面のメンテナンスから再インデックスするか、ownerとlast_modifierをkeyword型として追加してください。最初のクロールで動的にtext型になると、完全一致の絞り込みやファセットを正しく利用できません。

クロールを無効化する設定は今後の取得を制御するもので、既に格納した値を即座に消す操作ではありません。アカウント名を表示する運用が適切かを確認し、必要に応じて既存データの処理と再クロールも計画してください。検索結果には従来どおり文書の閲覧ロールが適用されます。所有者名だけでアクセス権が増える機能ではありません。

利用できるバージョン

Fess 15.9.0に含まれる予定の機能になります。現時点では、まだ、リリースしていないので、今後のテストで変更される可能性もあります。

関連PR

Fessの増分クロールでnofollowを維持する修正と注意点

ページにnofollowを指定しているのに、2回目のクロールからリンク先が検索対象に入ってしまう問題を修正しました。変更のないページを増分クロールするときにも、最初のクロールで判断した「リンクをたどらない」という扱いを維持するための変更です。

変更のないページでもリンクをたどらない

初回の取得ではrobots metaタグやX-Robots-Tagヘッダーを読み、nofollowならリンク先をキューへ追加しません。一方、HEADで更新がないと判断した場合や、条件付きGETが304を返した場合は、本文を解析せず保存済みのanchorからリンクを処理します。従来はnofollowページにもanchorが残り、そこでリンク先を再びクロールしていました。

修正後はnofollowページをインデックスするときにanchorを空にします。本文を省略する増分クロールでも、たどるリンクが残らなくなります。nofollowのないページでは従来どおり保存済みリンクを使います。

指定方法と初期値

クロール先のHTMLで、ページ全体の指定を使います。

<meta name="robots" content="index, nofollow">

HTTPヘッダーのX-Robots-Tag: nofollowも対象です。Fessのcrawler.ignore.robots.tagsの初期値はfalseで、robotsタグを無視しない設定です。この修正のための新しい設定キーはありません。

nofollowはリンク追跡の指定で、ページ自体のインデックスを禁止する指定ではありません。ページを検索結果から除外するnoindexとは区別して運用してください。個々のaタグのrel=”nofollow”を新たに解釈する修正でもありません。

既存インデックスへの反映

すでに保存されたanchorは自動で消えません。修正を含むビルドでページの本文を再取得・解析し、文書を更新する必要があります。増分クロールで変更なしと判定され続けるページは、増分クロールを無効にして再取得するなど、本文を取り直す運用を検討してください。リンク先の既存文書を削除する処理も、このPRには含まれません。

更新後のnofollowページは、リンク先URLを指定するanchor:<URL>検索には一致しなくなります。また、Last-Modifiedを更新せずX-Robots-Tagだけを変えた場合などは、増分クロールで指定変更を検知できない点も従来どおりです。

関連PR

Fessのテーマ配信とHTTPエラー応答を改善する

FessのStaticテーマ配信で、公開を禁止したファイルのチェックを見直しました。あわせて、エラーページのHTTPステータスと、壊れたリクエストパラメーターへの応答を修正しています。テーマを運用する際の安全性と、障害を判断しやすい応答に関わる変更です。

パスを解決した後に公開可否を判定する

テーマのtheme.ymlやREADME、ドットで始まるファイルなどは、配信時の拒否リストで公開を防いでいます。しかし従来は生のリクエストURIで判定していたため、重複スラッシュ、ドットのパス、パーセントエンコードなどの表記と、サーブレットコンテナが解決したファイルのパスが一致しない場合がありました。

今回、コンテナが解決したパスでテーマの配信経路を判断し、拒否対象のファイル名を確認します。非アクティブなテーマに属するファイルでも、拒否リストの対象なら404を返します。通常のJavaScriptやCSSなどのアセットは引き続き配信します。

拒否リストはすべてのドキュメントを非公開にする機能ではありません。例えばDESIGN.mdのようにリストにない名前は対象外です。テーマ内に公開すべきでないファイルを置く場合は、配信対象の確認も必要です。

エラーページとHTTPステータスを一致させる

従来は/error/404や/error/not_foundでもHTTP 500を返す場合がありました。数値コードと名前の表記を整理し、例えば次のように応答します。

パスHTTPステータス
/error/404404
/error/not_found404
/error/400400
/error/502502

専用の画面がないコードでもHTTPステータスは維持し、近いエラーページを表示します。例えば401ではアクセス拒否の画面、502ではサーバーエラーの画面を使います。不明な名前などは従来どおり500です。

読み取れないパラメーターを400として扱う

不正なパーセントエンコードなどを含むパラメーターは、サーバー内部の不具合とは区別してHTTP 400を返すようにしました。API v2ではinvalid_requestのエラー形式を使い、他の画面では通常の400応答にします。フォームのサイズ制限を超えた場合は413を返します。

これにより、監視で500を数えている環境でも、壊れたリンクや不正な入力と、アプリケーションの障害を区別しやすくなります。他の例外まで400に変換するものではありません。

今回の対応を含むビルドを適用した後は、テーマの通常画面とアセットに加えて、404などの応答も確認するとよいと思います。

関連PR