ドット（。）が付いたSpringMVC@PathVariableは切り捨てられます

投稿日: 2019-10-18 2022-10-30
タグ: Spring MVC

1. 概要

この短いチュートリアルでは、Spring MVCを使用する場合の一般的な問題について説明します– @RequestMappingでSpring@PathVariableを使用して、ドットを含むリクエストURIの終わりをマッピングする場合最後のドットで切り捨てられた、変数の部分的な値になります。

次のセクションでは、これが発生する理由と、この動作を変更する方法に焦点を当てます。

Spring MVCの概要については、この記事を参照してください。

2. 不要な春のヘルプ

フレームワークは、パス変数を解釈する方法のために、このしばしば望ましくない動作を引き起こします。

具体的には、 Springは、最後のドットの後ろにあるものはすべて、.jsonや.xml。などのファイル拡張子であると見なします。

その結果、パラメータを取得するために値が切り捨てられます。

パス変数の使用例を見てから、さまざまな可能な値で結果を分析してみましょう。

@RestController
public class CustomController {
    @GetMapping("/example/{firstValue}/{secondValue}")
    public void example(@PathVariable("firstValue") String firstValue,
      @PathVariable("secondValue") String secondValue) {
        // ...  
    }
}

上記の例で、次のリクエストを検討し、変数を評価しましょう。

URL example / gallery / link の結果、 firstValue=「gallery」およびsecondValue=「link」が評価されます。
example / gallery.df / link.ar URLを使用すると、 firstValue =“ gallery.df”および secondValue =“ link”になります。
example / gallery.df / link.com.ar URLの場合、変数は次のようになります。 firstValue =“ gallery.df”および secondValue =“ link .com」

ご覧のとおり、最初の変数は影響を受けませんが、2番目の変数は常に切り捨てられます。

3. ソリューション

この不便を解決する1つの方法は、正規表現マッピングを追加して@PathVariable定義を変更することです。これにより、最後のドットを含むすべてのドットがパラメータの一部と見なされます。

@GetMapping("/example/{firstValue}/{secondValue:.+}")   
public void example(
  @PathVariable("firstValue") String firstValue,
  @PathVariable("secondValue") String secondValue) {
    //...
}

この問題を回避する別の方法は、@PathVariableの最後にスラッシュを追加することです。これにより、Springのデフォルトの動作から保護する2番目の変数が囲まれます。

@GetMapping("/example/{firstValue}/{secondValue}/")

上記の2つのソリューションは、変更する単一のリクエストマッピングに適用されます。

グローバルMVCレベルで動作を変更する場合は、カスタム構成を提供する必要があります。この目的のために、 WebMvcConfigurationSupport を拡張し、その getPathMatchConfigurer（）メソッドをオーバーライドして、PathMatchConfigurerを調整できます。

@Configuration
public class CustomWebMvcConfigurationSupport extends WebMvcConfigurationSupport {

    @Override
    protected PathMatchConfigurer getPathMatchConfigurer() {
        PathMatchConfigurer pathMatchConfigurer = super.getPathMatchConfigurer();
        pathMatchConfigurer.setUseSuffixPatternMatch(false);

        return pathMatchConfigurer;
    }
}

このアプローチはすべてのURLに影響することを覚えておく必要があります。

これらの3つのオプションを使用すると、同じ結果が得られます。 example / gallery.df / link.com.ar URLを呼び出すと、secondValue変数は「リンク」と評価されます。 .com.ar」、これが私たちが望んでいることです。

3.1. 非推奨の通知

Spring Framework 5.2.4 以降、 setUseSuffixPatternMatch（boolean）メソッドは、リクエストルーティングとコンテンツネゴシエーションにパス拡張機能を使用しないようにするために非推奨になりました。基本的に、現在の実装では Reflected File Download（RFD）攻撃からWebアプリケーションを保護することは困難です。

また、Spring Framework 5.3以降、サフィックスパターンマッチングは、任意の拡張を防ぐために、明示的に登録されたサフィックスに対してのみ機能します。

つまり、Spring 5.3の時点では、 setUseSuffixPatternMatch（false）はデフォルトで無効になっているため、使用する必要はありません。

4. 結論

この簡単な記事では、SpringMVCの@PathVariableと@RequestMapping を操作する際の一般的な問題と、この問題の原因を解決するさまざまな方法を検討しました。

いつものように、例の完全なソースコードは、GitHubでから入手できます。

getdocs

13036