Spring Validation データ検証の実装

1. Spring 検証の役割

1) SQL インジェクションに関して: Web フォームに SQL コマンドを挿入して、ドメイン名またはページリクエストのクエリ文字列を送信または入力し、最終的にサーバーをだまして悪意のある SQL コマンドを実行させることです。

2) SQL インジェクションの防止: (1) ユーザーの入力を決して信頼しないでください。ユーザーの入力を検証するには、正規表現を使用するか、長さを制限したり、一重引用符や二重 "-" を変換したりすることができます。(2) 動的にアセンブルされた SQL は決して使用しないでください。データのクエリとアクセスには、パラメータ化された SQL を使用するか、ストアドプロシージャを直接使用できます。(3) 管理者権限のデータベース接続は決して使用せず、アプリケーションごとに権限を制限した別のデータベース接続を使用してください。(4) 機密情報は平文で保存せず、パスワードや機密情報は暗号化またはハッシュ化してください。(5) アプリケーションの例外情報は、ヒントをできるだけ少なくする必要があるため、カスタムエラー情報を使用して元のエラー情報をパッケージ化し、例外情報を独立したテーブルに保存することをお勧めします。

3) したがって、Spring Validation が必要になります。Spring Validation の主な機能は、リクエストパラメーターの基本形式をチェックすることです。

2. リクエストパラメータの確認について

開発現場では、クライアント側プロジェクト (Web フロントエンドなど) であってもサーバー側プロジェクトであっても、ユーザーが入力および選択したデータを確認する必要があります。

実際、データが正しいかどうかを最終的に確認できるのはサーバー側の検査であるため、サーバー側ではリクエストパラメーターをチェックし、データの基本形式が正しい場合にのみ関連する処理を実行できます。

フロントエンドとバックエンドの分離モードでは、サーバーはすべてのクライアントが統一された効果的な検証ルールを採用していることを保証できません。クライアントのチェックが実施されていないため、ユーザ端末のクライアントソフトウェアのバージョンアップができなくなったり、クライアントソフトウェアさえも偽造・改ざんされたりする可能性がある。

クライアントのチェックが必ずしも信頼できるわけではありませんが、すべてのクライアントはリクエストパラメータをチェックする必要があり、パラメータの基本形式が要件を満たしていない場合は、リクエストを送信すべきではありません。結局のところ、サーバーへの負荷を軽減するために、クライアントの検査はほとんどのエラーをインターセプトすることができます (低レベルのエラー要求はサーバーに送信されません)。

3. 依存関係を追加する

Spring Boot プロジェクトで Spring Boot Validation を使用するための依存関係は次のとおりです。

<!-- Spring Boot Validation：用于检查请求参数的基本格式 -->
<dependency>
	<groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-validation</artifactId>
</dependency>

4. 基本的な使い方

リクエストを処理するコントローラーのメソッドで、検証する必要があるリクエストパラメーターに「@Valid」または「@Validated」アノテーションを追加して、このパラメーターが Spring Boot Validation によってチェックされる必要があることを示します。次に例を示します。

@PostMapping("/add-new")
public JsonResult addNew(@RequestBody @Valid BrandAddNewDTO brandAddNewDTO) {
    brandService.addNew(brandAddNewDTO);
    return JsonResult.ok();
}

リクエストパラメータをカプセル化する POJO クラスで、形式を検証する必要がある各属性の前に、形式をチェックするための注釈を追加して形式検証を実現します。次に例を示します。

@ApiModelProperty(value = "品牌名称", required = true, example = "华为")
@NotNull
private String name;

5. パラメータ形式確認時の注意事項

@NotNull: 「null」は許可されません。つまり、この名前に対応するパラメータを送信する必要があります。

注: プリミティブデータ型 (Integer、Long、Double など) で動作します。

@NotEmpty: 空の文字列 (長さ 0 の文字列) は許可されません

注: 現在の配列またはコレクションを null にすることはできず、長さを 0 にすることはできないことを決定するために、配列またはコレクション型の属性に適用されます。

@NotBlank: 空白は許可されません (文字列の長さは 0 より大きくてもかまいませんが、スペースやタブなどで入力されます)

注: 文字列形式のパラメータに適用されます

@Min: 数値型の最小値を設定します

数値型のリクエストパラメータのみ

@Range で置き換えることができます

@Max: 数値型の最大値を設定します

数値型のリクエストパラメータのみ

@Range で置き換えることができます

@Range: データ型の値の範囲を設定します。最小値と最大値を設定できます。

このアノテーションの min 属性のデフォルトは 0 で、max 属性のデフォルトは long 型の最大値です。

数値型のリクエストパラメータのみ

@Pattern: 正規表現を構成します

@NotNull アノテーションを置き換えることはできません

開発の実践では、文字列型のリクエストパラメータの場合、`@NotNull` (送信する必要があると思われる場合) と @Pattern を同時に使用する必要がありますが、`@NotEmpty`、`@NotBlank` は通常、その必要はありません。文字列の値に多くの要件はありませんが、数値型のリクエストパラメータの場合は、`@NotNull` と `@Range` を同時に使用する必要があります。

注: 数値タイプの属性の場合、送信されたリクエストパラメータを数値タイプに変換できない場合、これらの注釈は有効にならず、エラーが報告されます。

さらに、開発の実践では、使用される正規表現とエラー発生時のプロンプトテキストは通常、特別なクラスまたはインターフェイスにカプセル化され、各 POJO タイプを直接参照できます。