FessのStaticテーマ配信で、公開を禁止したファイルのチェックを見直しました。あわせて、エラーページのHTTPステータスと、壊れたリクエストパラメーターへの応答を修正しています。テーマを運用する際の安全性と、障害を判断しやすい応答に関わる変更です。
パスを解決した後に公開可否を判定する
テーマのtheme.ymlやREADME、ドットで始まるファイルなどは、配信時の拒否リストで公開を防いでいます。しかし従来は生のリクエストURIで判定していたため、重複スラッシュ、ドットのパス、パーセントエンコードなどの表記と、サーブレットコンテナが解決したファイルのパスが一致しない場合がありました。
今回、コンテナが解決したパスでテーマの配信経路を判断し、拒否対象のファイル名を確認します。非アクティブなテーマに属するファイルでも、拒否リストの対象なら404を返します。通常のJavaScriptやCSSなどのアセットは引き続き配信します。
拒否リストはすべてのドキュメントを非公開にする機能ではありません。例えばDESIGN.mdのようにリストにない名前は対象外です。テーマ内に公開すべきでないファイルを置く場合は、配信対象の確認も必要です。
エラーページとHTTPステータスを一致させる
従来は/error/404や/error/not_foundでもHTTP 500を返す場合がありました。数値コードと名前の表記を整理し、例えば次のように応答します。
| パス | HTTPステータス |
|---|---|
/error/404 | 404 |
/error/not_found | 404 |
/error/400 | 400 |
/error/502 | 502 |
専用の画面がないコードでもHTTPステータスは維持し、近いエラーページを表示します。例えば401ではアクセス拒否の画面、502ではサーバーエラーの画面を使います。不明な名前などは従来どおり500です。
読み取れないパラメーターを400として扱う
不正なパーセントエンコードなどを含むパラメーターは、サーバー内部の不具合とは区別してHTTP 400を返すようにしました。API v2ではinvalid_requestのエラー形式を使い、他の画面では通常の400応答にします。フォームのサイズ制限を超えた場合は413を返します。
これにより、監視で500を数えている環境でも、壊れたリンクや不正な入力と、アプリケーションの障害を区別しやすくなります。他の例外まで400に変換するものではありません。
今回の対応を含むビルドを適用した後は、テーマの通常画面とアセットに加えて、404などの応答も確認するとよいと思います。