Fessの英単語検索で大文字と語尾を考慮する曖昧検索の修正案

Fessで英単語の入力ミスを含む検索をすると、小文字なら見つかるのに先頭を大文字にすると見つからない場合があります。PR #3726は、通常の検索に自動で加わる曖昧検索を、検索語の解析後に行う修正案です。

入力した文字列と索引の語をそろえる

従来の処理では、索引側で小文字化や語尾処理を受けた語に対して、入力した文字列をそのまま使って編集距離を計算していました。修正案は検索解析器を通してから曖昧一致させます。PRの検証用索引では、fabianに対するFbian、onboardingに対するOnbordingのような入力で改善が報告されています。件数や改善幅は索引と解析器によるもので、すべての環境で同じ結果になる保証はありません。

foo-barのように複数のトークンへ分かれる入力は、曖昧検索部分でもすべてのトークンを要求します。一部だけの一致によって候補が広がりすぎることを抑えるためです。

設定の初期値は変わらない

新しい有効化設定はありません。修正を含む検証ビルドで、既存のquery.boost.fuzzy.*を引き続き使います。標準値は次のとおりです。

query.boost.fuzzy.min.length=4
query.boost.fuzzy.title=0.01
query.boost.fuzzy.content=0.005
query.boost.fuzzy.title.fuzziness=AUTO
query.boost.fuzzy.content.fuzziness=AUTO

titleとcontentの両方で、prefix_lengthは0、expansionsは10、transpositionsはtrueです。最小長4の判定は入力文字列の長さですが、AUTOが許す編集距離は解析後の各トークンの長さに応じて決まります。短くなった語では許される編集回数も変わりえます。

日本語の誤字訂正を追加する変更ではない

漢字・ひらがな・カタカナ・ハングルを含む入力には、この暗黙の曖昧検索を追加しません。日本語などの誤字訂正を新たに提供する機能ではありません。明示的なfoo~1の構文、フレーズ検索、言語別フィールドの処理も今回の変更対象外です。解析後にストップワードだけになる入力は、この部分から近似語のヒットを得ません。

検証時は同じ索引で、小文字と大文字、語尾変化、ハイフン入り、正しく綴った単語を比較します。通常の単語にも低スコアの候補が増える可能性があり、上位順位が常に同じとは限りません。適合率と検索結果の順序も確認してから導入を判断します。

関連PR

Fess開発版のinitコマンドで初回起動前のパスワードと暗号鍵を設定する

Fessを新規に導入するときは、管理者の初期パスワードと、保存した認証情報の暗号化に使う鍵を最初に決めておきたいところです。開発版に追加されたfess-setup initで、この2項目を初回起動前に設定できるようになります。

初回起動前に実行する

出荷時のindex.user.initial_passwordはadmin、app.cipher.keyは___change__me___です。対応する開発版を展開し、まだFessを起動していない状態で、Fessの配置ディレクトリーから次を実行します。設定ファイルを書き換えられる権限が必要です。

bin/fess-setup init

オプションを省略すると、英数字16文字の管理者パスワードと英数字32文字の暗号鍵をランダム生成します。既定の設定ファイルはFess配下のapp/WEB-INF/classes/fess_config.propertiesです。RPM・DEB形式の配置では、対象ファイルを明示します。

bin/fess-setup init --config /etc/fess/fess_config.properties

成功後に表示される生成パスワードを安全に控えてから、Fessを初めて起動します。生成パスワードはコマンド実行時に表示され、設定ファイルにも書き込まれます。ターミナル出力や設定ファイルを不必要に共有しないようにします。暗号鍵そのものは通常の成功メッセージには表示されません。

既存環境のパスワード変更には使わない

初期パスワードはユーザーインデックスの作成時に読み込まれます。既に起動してユーザーを作成した環境で設定ファイルを変更しても、既存の管理者パスワードは変わりません。

また、暗号鍵を変えると、以前の鍵で保存したクロール設定などの認証情報を復号できなくなります。出荷時の値から変更済みの鍵がある場合、通常はコマンドが書き換えを拒否します。--forceで上書きはできますが、既存データを新しい鍵で暗号化し直す機能ではありません。新規導入向けのコマンドと考え、既存環境の鍵を安易に置き換えないようにします。移行や復元のためにも、設定ファイルと暗号鍵を安全に保管します。

値を指定する場合の条件

--admin-passwordと--cipher-keyで値を指定することもできます。ただし、コマンドライン引数は同じマシンの他の利用者から見える場合があるため、通常は自動生成を使う方が扱いやすいでしょう。

パスワードには空文字、前後の空白、制御文字、出荷時のadminを指定できません。明示する暗号鍵は空白を含まない印字可能なASCII文字の16・24・32文字で、出荷時の鍵も拒否されます。暗号方式がaes以外に設定されているファイルには対応しません。

対象の設定ファイルは既に存在する必要があります。2項目の既存行を置き換え、項目がなければ追記します。Fessを起動したり、既存ユーザーをリセットしたりするコマンドではないので、実行後の設定内容と初回ログインを確認して導入を進めます。

関連PR

FessのOIDCログインにnonce検証を追加する修正案

FessのOIDCプラグインに、認証要求とIDトークンをnonceで対応付ける修正が提案されています。以前のissuer・有効期限・対象クライアントの検証に加わる変更で、プロバイダーとの互換性に影響します。

ログインごとに発行してコールバックで照合する

修正案では、認証要求ごとにランダムなnonceを作り、stateとともにセッションへ保存します。プロバイダーから返ったIDトークンのnonceクレームが文字列で、保存値と一致することを確認します。

nonceがない、文字列ではない、値が違う、セッションに対応値がない場合は拒否します。コールバック到着時にセッションのnonceを取り除くため、同じコールバックを再利用する前提にもできません。nonceそのものは警告ログへ出しません。

初期値や無効化スイッチはない

この検証を任意で緩める設定は提案されていません。修正を含むプラグインを使う場合、プロバイダーが認証要求のnonceをIDトークンへ反映する必要があります。

検証環境で通常のログインを試し、認証要求からトークンまで対応する値が返ることを確認します。ログへトークンやnonceの値を出す運用は避け、拒否時はログインをやり直して設定を確認します。

プラグイン更新前に開始したログインは、セッションにnonceを持たないため一度失敗し、最初からやり直す必要があります。更新時の問い合わせ対応へ織り込んでおくとよい点です。

ほかの検証も引き続き確認する

nonceを追加しても、すべてのOIDC機能を実装するわけではありません。このPRではPKCE、iat、nbfの検証は追加されません。issuerの指定やHTTPS、既存のクレーム検証と併せて確認してください。

以前の記事にある「nonce未実装」という制限を変える提案ですが、マージ・配布を確認するまでは実運用で利用可能と判断しないでください。

関連PR