Spring徹底入門#

5.3.5 Handlerメソッドの戻り値#

• Handlerメソッドは戻り値として様々なオブジェクトを返却できる

• メモ

  • 返却できるオブジェクトはorg.springframework.web.method.support.HandlerMethodReturnValueHandlerインターフェースの実装クラスを作成することで拡張できる

• SpringMVCがサポートしている主な型

  • java.lang.String
  • Model
  • ModelAndView
  • void
  • ResponseEntity<?>
  • HttpHeaders

5.3.6 View Controllerの利用#

• Viewを呼び出すだけであれば、SpringMVCが提供しているViewControllerの仕組みを利用することができる

5.5.4 コンパイルオプションの注意点#

• @PathVariable,@RequestParam,@RequestHeader,@CookieValueのvalue属性を省略する場合、
• -gオプションまたはJavaSE8から追加された-parametersオプションのどちらかのコンパイルオプションを有効にしておく必要がある
  • TODO: バインドされないとき確認

5.5.7 アノテーションを使用したフォーマットの指定#

• @org.springframework.format.annotation.DateTimeFormat

• @org.springframework.format.annotation.NumberFormat

• JSR354 : Money and Currency APIというものがあるらしい

  • TODO: 後で確認する

5.6.1 フォームオブジェクトのスコープ#

• スコープの種類

  • リクエストスコープ
  • フラッシュスコープ：PRGパターンのリクエスト間でオブジェクトを共有するためのスコープ
  • セッションスコープ：HttpSessionに格納され、明示的に破棄するまで残り続ける

• フラッシュスコープ

  • RedirectAttributesのaddFlashAttribute()メソッドを使用して詰める

1
@RequestMapping(path = "create", method = RequestMethod.POST)
2
public String create(
3
  @Validated AccountCreateForm form, BindingResult result,
4
  RedirectAttributes redirectAttributes) {
5
    redirectAttributes.addFlashAttribute(form);
6
    return "redirect:/account/create?complete";
7
  }

5.6.2 フォームクラスの作成#

1
@Data
2
public class LoginFormRequestDto implements Serializable {
3
  private static final long serialVersionUID = 1L;
4
  private String id;
5
  private String password;
6
}

• Serializableインターフェスを実装しておく。これが必要なのはオブジェクトをセッションスコープで管理する場合だが、スコープに関係なく定義しておくのが無難

5.7.1 入力チェックの有効化#

• 入力チェックを行う場合、
  • 入力チェックを行うメソッドの引数にフォームクラスを定義して、
    • @org.springframework.validation.annotation.Validatedまたは
    • @org.springframework.validation.annotation.Valid を指定する
      • @Validatedを使用すると、BeanValidationのバリデーショングループの仕組みが使用できるらしい

5.7.2 入力チェック結果の判定#

• BindingResultで処理する

5.7.3 未入力の扱い#

• 未入力は許容するが、入力された場合は６文字移譲であること

  • という要件をBeanValidation標準アノテーションを使用して満たすことができない

• この場合は、Springが提供しているorg.springframework.beans.propertyeditors.StringTrimerEditorを使用することを検討

• TODO: 普通に独自アノテーションを作成した方がシンプルなような気がする

5.7.5 ネスト下JavaBeansの入力チェック#

• ネストしたJavaBeansやコレクション内のJavaBeansに定義したプロパティに対して入力チェックを行いたい場合は、@Validを指定する

  • チェック対象とすることを明示する必要がある

• @Validと@Validatedの違い

  • http://moondream.hatenablog.com/entry/20131006/1381031027

5.7.6 入力チェックルールの追加#

• 独自の入力チェックツール追加方法２つ

  • 既成ルールを合成して作成する方法
  • 独自のバリデータを実装して作成する方法

• 既成ルールを合成して作成する方法

  • →こっちは使った方がよい

1
import static java.lang.annotation.ElementType.*;
2
import static java.lang.annotation.RetentionPolicy.*;
3

4
import java.lang.annotation.Documented;
5
import java.lang.annotation.Retention;
6
import java.lang.annotation.Target;
7

8
import javax.validation.Constraint;
9
import javax.validation.Payload;
10
import javax.validation.ReportAsSingleViolation;
11
import javax.validation.constraints.Pattern;
12

13
@Documented
14
@Constraint(validatedBy = {})
15
@Target({ METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER })
16
@Retention(RUNTIME)
17
@ReportAsSingleViolation
18
@Pattern(regexp = "[a-zA-Z0-9]*")
19
public @interface AlphaNumeric {
20

21
  String message() default "{validation.AlphaNumeric.message}";
22
  Class<?>[] groups() default {};
23
  Class<? extends Payload>[] payload() default {};
24

25
  @Target({ METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER })
26
  @Retention(RUNTIME)
27
  @Documented
28
  public @interface List {
29
    AlphaNumeric[] value();
30
  }
31

32
}

• メモ TODO: 覚えておく

  • 上の例では１つしか既成ルールを使用していないが、既成ルールを複数まとめた合成アノテーションを作成することもできる
    • なお、既成ルールをまとめた合成アノテーションを作成する場合、@ReportAsSingleViolationも付与するのが一般的で、付与すると、message属性で指定したメッセージが利用される用になる。付与しない場合は、既成ルールに指定したメッセージが利用される

• 独自のバリデータを実装して作成する方法

  • →冗長になりがちだと思うので作成しないほうが良いのでは？
    • 相関チェックも実装できそうだが、@AssertTrueを使用したほうがシンプル

• @AssertTrueの使用方法

  • https://qiita.com/t-iguchi/items/ea3dd8691d52d7abe695

5.7.7 入力チェックツールの切り替え#

• コントローラーのメソッドでパラメータ指定して、呼び出すメソッドを変更することで実現する例を記載している

5.7.8 エラー情報の表示#

• <form:errors path="name">

  • このように記載することでエラー情報取れますよという説明がある

• エラーメッセージ要素の構成案

1
<div class="error-message d-none">
2
  <form:errors path="name">
3
</div>

1
document.querySelectorAll(".error-message").forEach(el=>{
2
  if(el.innerText) el.classList.remove("d-none");
3
})

• みたいな感じにすればいいのではなかろうかと

5.7.9 エラーメッセージの解決#

• エラーメッセージの定義方法

  • Springが提供するMessageSourceで読み込んだプロパティファイルにメッセージを定義する
  • BeanValidation管理のプロパティファイルにメッセージを定義する
  • 制約アノテーションのmessage属性に直接メッセージを定義する

• Spring管理プロパティファイル

  • 制約アノテーションのクラス名＋「.」＋フォームオブジェクトの属性名＋「.」＋プロパティ名
  • 制約アノテーションのクラス名＋「.」＋フォームオブジェクトの属性名
  • 制約アノテーションのクラス名＋「.」＋プロパティ名
  • 制約アノテーションのクラス名＋「.」＋プロパティの型名（FQCN）
  • 制約アノテーションのクラス名

• BeanValidation管理のプロパティファイルにエラーメッセージを定義

  • クラスパス直下のValidationMessages.propertiesにメッセージを定義する
    • →あまり使用する機会無いのではと思う

5.7.10 BeanValidationのカスタマイズ#

• java configに設定
  • →あまりメリットが理解できなかったのでスキップ

5.7.11 Spring Validatorの利用#

• 割愛

5.8.1 遷移先の指定方法#

• View名をHandlerメソッドの戻り値として返却することで実現

5.8.2 リクエストパスへのリダイレクト#

• View名に「redirect: + リダイレクト先のリクエストパス」
• RedirectAttributesを使用してパラメータを設定する
• パス変数を指定することもできる

5.8.3 リクエストパスへのフォワード#

• 「forward: + 転送先のリクエストパス」
• return "forward:/auth/authenticate";
• MEMO: 使い所が知りたい

5.8.4 Viewとのデータ連携#

• JavaオブジェクトをModelに格納する方法は、以下の２つがある
  • ModelのAPIを直接呼び出す
  • ModelAttributeアノテーションを付与したメソッドを用意する

5.8.5 リダイレクト先とのデータ連携#

• RedirectAttributesのフラッシュスコープの説明

5.13.1 例外の種類#

• Webアプリケーションで発生する例外は大きく３つある
  • システム例外:処理を継続することができない例外
    • アプリケーション自体のバグ
    • 依存ライブラリのバグ
    • ミドルウェアやハードウェアの故障
    • システムリソースの枯渇
    • ネットワーク障害
  • リクエスト不正を通知する例外：リクエストの内容が不正なときに発生する例外
    • 存在しないパスへのリクエスト
    • バインディングエラー
    • 入力チェックエラー
  • アプリケーション例外：ビジネスルールに違反したときに発生する例外
    • ユーザー登録時のIDの重複エラー
    • 排他エラー
    • 在庫数の不足エラー

5.13.2 例外の発生箇所とハンドリング方法#

• 以下の箇所で例外が発生する可能性があり、それぞれ例外ハンドリングの方法も異なる
  • 1. Servlet Fileter
    • サーブレットコンテナへのエラーページ機能（web.xmlの<error-page>要素）を使用してエラー処理を実装する
  • 2. DispatcherServlet: SpringMVCが提供する例外ハンドリングの仕組み（HandlerExceptionResolver）
  • 3. アプリケーション(Controller, Service, Repositoryなど)：SpringMVCが提供する例外ハンドリングの仕組み（HandlerExceptionResolver）
  • 4. View（JSPなど）
    • Viewの中で発生した例外は、サーブレットコンテナのエラーページ機能を使用して絵r-あ処理を実装

5.13.3 サーブレットコンテナのエラーページ機能を利用#

• web.xmlにerror-pageを記載する方法を紹介

5.13.5 @ExceprtionHandlerメソッドの利用#

• 複数のController間で共通の処理

  • @ControllerAdviceを用いる
  • https://terasolunaorg.github.io/guideline/5.0.1.RELEASE/ja/ImplementationAtEachLayer/ApplicationLayer.html#id160

• @ExceptionHandlerメソッドの引数

  • Exception
  • HandlerMethod
  • java.util.Locale
  • java.util.Timezone
  • java.time.ZoneId
  • java.security.Principal

• 戻り値について

  • String
  • ModelAndView
  • void
  • ResponseEntity<?>

5.13.6 @ResponseStatusを指定した例外クラスの利用#

1
@ResponseStatus(HttpStatus.NOT_FOUND)
2
public class ResourceNotFoundException extends RuntimeException {
3
  // *****
4
}

• TODO: 独自Exceptionを作成していくべきかどうか

6.1.1 Resouce Oriented Architecture (ROA)#

6.1.2 フレームワークのアーキテクチャ#

• 割愛 TODO: 詳細を知りたくなったら読む

6.2.1 ライブラリのセットアップ#

• リソース形式としてJSONを使用する際に利用する「FasterXML Jackson Databind」を依存ライブラリに追加する
  • MEMO: SpringBootだと不要みたい

6.2.2 サーブレットコンテナの設定#

• HiddenHttpMethodFilterの適用

  • RESTAPIを提供する場合、HTTPメソッドとして、PUT、PATCH、DELETEなども使用するが、
  • Webブラウザなどクライアントの実装によっては、GETとPOSTしか使用できなかったりする
  • そこをサポートするためにorg.springframework.web.filter.HiddenHttpMethodFileterクラスを利用する
    • _method=putというパラメータでリクエストが送られると、サーブレットコンテナ内で行われる処理はPUTメソッドでアクセスしたときとおなじになる

• HttpMessageConverterのカスタマイズ

  • MEMO: Converterの設定をしているが、SpringBootだと不要だと思うので飛ばす

7.1.1 セッション属性（@SessionAttributes）#

• １つのController内で扱う複数のリクエスト間でデータを共有する場合に有効な方法
  • 入力画面が複数のページで構成される場合や、複雑な画面遷移を伴う場合は@SessionAttributesを使用することを検討
• シンプルな画面構成の場合（入力画面→確認画面→完了画面とかの場合）は、HTMLフォームのHiddenで値を持ち回る方法を検討すること

7.1.2 セッションスコープBean#

• 複数のControllerをまたぐ画面遷移において、Controller間でデータを共有する場合に有効な方法

7.2.2 ファイルアップロード機能のセットアップ#

• web.xmlに<multipart-config />を追加するとのこと

• Servlet標準のファイルアップロード機能をデフォルトのまま利用するとアップロードできるファイルのサイズに上限がないため、上限を設けたい場合は、ファイル単位の最大サイズ、アップロード時のリクエスト全体の最大サイズ、一時ファイル出力有無の閾値サイズの３つを指定する必要がある

• 上限に引っかかると、MultipartExceptionが発生するので、Handlerでハンドリングすること

• メモ

  • SpringMVCのDispatcherServletより前にリクエストパラメータにアクセスする処理があると、MultipartExceptionが発生しない可能性がある
  • SpringWEBから提供されているフィルターを利用すると制御できるとのこと
    • TODO: SpringBootだとどのように記載するか確認

7.2.3 アップロードデータの取得#

• Formクラスの作成

  • 普通にFormクラスの作成 MultipartFile型で変数定義する

• Viewの作成

  • input type=“file”で作成して送るだけ

• Controller

  • ファイルを取得して永続化操作

• Validation

  • ファイルサイズや、コンテンツタイプ、ファイル名などをチェックする場合は、Validatorを作成してチェック

• TODO: 実際にアイコン画像などをDBで保持できる永続化ロジックまで書く

7.3.1 非同期リクエストの仕組み#

• 非同期実行が終了してからHTTPレスポンスを開始

  • 勘違いしやすいのが、HTTPレスポンスは非同期実行している処理が終了したあとに行うため、クライアント側から見ると、同期処理と同じ動作になる

• SpringMVCはこのパターンの非同期処理をサポートするために以下の２つの方法を提供

  • SpringMVC管理のスレッドを使用した非同期処理
  • SpringMVC管理外のスレッドを使用した非同期処理

• 非同期実行の処理中にHTTPレスポンスを開始

  • ロングポーリングを使用した非同期処理
  • SSE（Server-Sent Events）に準拠した非同期処理

7.3.2 非同期実行を有効にするための設定#

• web.xmlに設定追記
• java configにBean定義追加

7.3.3 非同期処理の実装#

• 以下の２つの非同期処理の実装方法を紹介

  • CompletableFutureを使用した非同期処理
  • SseEmitterを使用したPush型の非同期処理

• @Asyncの利用

  • 本書で説明する非同期処理は、どちらもSpringMVC管理外のスレッドを使用した非同期処理
  • SpringFrameworkは、特定のメソッドを別スレッドで実行する仕組みを提供しており、別スレッドで実行したいメソッドに、org.springframework.scheduling.annotation.Asyncを付与するだけ

• MEMO: SpringBootでの利用に参考

  • https://qiita.com/mitsuya/items/c21907ab10919111e773

• CompletableFutureを使用した非同期処理の実装

  • CoompletableFuture<String>を返却する

• SseEmitterを使用したPush型の非同期処理の実装

  • new SseEmitter();でイベント処理を行う
    • 具体的な使用方法について説明なし

7.3.4 非同期実行の例外ハンドリング#

• DeferredResultを使用して結果を設定する
• TODO: 結果を非同期で画面に通知する方法確認

7.3.5 非同期実行に対する共通処理の実装#

• CallableProcessingInterceptorもしくはDeferredResultProcessingInterceptorのAdopterを実装したクラスを作成

• 現在は、interfaceにデフォルトメソッドが定義できるようになったので、Adopterではなくて、interfaceの方を使用すべきとのことで、@Deprecatedになっている

• CallableProcessingInterceptorインターフェース

7.4.1 サーブレットフィルタの利用#

• SpringMVCの呼び出し前後に共通する処理を実行するには、javax.servlet.Filterインターフェースの実装クラスを作成する

• Filterクラスを直接実装してもよいが、ここではSpringが提供しているサポートクラスを利用する方法を紹介

• サポートクラス

  • GenericFilterBeanクラス
  • OncePerRequestFilterクラス

• DIコンテナで管理しているBeanのインジェクション方法

  • サーブレットフィルター内の処理でDIコンテナ管理しているBeanを利用したい場合は、サーブレットフィルタをDIコンテナに登録し、DelegatingFilterProxy経由でサーブレットフィルタの処理を実行する
  • DelegatingFilterProxyは、SpringのDIコンテナに登録されているサーブレットフィルターに処理を移譲するサーブレットフィルタクラス

7.4.2 HandlerInterceptorの利用#

• Controllerでハンドリングする処理に対してだけ共通処理を実行したい場合は、

  • org.springframework.web.servlet.HndlerInterceptorインターフェースの実装クラスを作成する

• メソッド

  • preHandle：実行前
  • postHandle：例外時は呼び出されない
  • afterCompletion：実行後

1
@Slf4j
2
public class LoggingInterceptor extends HandlerInterceptorAdapter {
3

4
  public void postHandler(HttpServletRequest request, HttpServletResponse response, Object handler,
5
      ModelAndView modelAndView) {
6
    if (log.isInfoEnabled()) {
7
      HandlerMethod handlerMethod = (HandlerMethod) handler;
8
      Method method = ((HandlerMethod) handler).getMethod();
9
      log.info("[SUCCESS CONTROLLER] {}.{}", method.getDeclaringClass().getSimpleName(), method.getName());
10
    }
11

12
  }
13
}

1
    @Override
2
    public void addInterceptors(InterceptorRegistry registry) {
3
        registry.addInterceptor(new LoggingInterceptor())
4
                .addPathPatterns("/**")
5
                .excludePathPatterns("/resources/**");
6
    }

7.4.3 @ControllerAdviceの利用#

• Controllerクラスには、Handlerメソッドとは別に、Controller専用の特殊なメソッド（@InitBinderメソッド、@ModelAttributeメソッド、@ExceptionHandlerメソッド）を実装することができる
• これらのメソッドを複数のControllerクラスで共有するには、@ControllerAdviceを付与したクラスを作成する

1
@Slf4j
2
@ControllerAdvice
3
public class ErrorController {
4

5
  @GetMapping("/error")
6
  public String handleError() {
7
    return "error";
8
  }
9

10
  @ExceptionHandler(Throwable.class)
11
  public String handleThrowable(Throwable exception, Model model) {
12
    model.addAttribute("", "");
13
    return "error";
14
  }
15

16
  @ExceptionHandler(Exception.class)
17
  public String handleException(Exception exception, Model model) {
18
    model.addAttribute("", "");
19
    return "error";
20
  }
21

22
  @ExceptionHandler(IOException.class)
23
  public String handleIOException(IOException exception, Model model) {
24
    model.addAttribute("", "");
25
    return "error";
26
  }
27
}

7.4.4 HandlerMethodArgumentResolverの利用#

• SpringMVCのデフォルトでサポートされていないオブジェクトをControllerのHandlerメソッドの引数に渡したい場合は、org.springframework.web.method.support.HandlerMethodArgumentResolverインターフェースの実装クラスを作成します。
• あまり利用するシーンがわからないため割愛する

7.5.1 デフォルトサーブレットとDispatcherServletの共存#

• Servletの使用では、ルートパス（）にマッピングされたサーブレットのことを「デフォルトサーブレット」と呼び、デフォルトサーブレット経由でWebアプリケーションのドキュメントルート配下のファイルにアクセスすることができる
• SpringMVCアプリケーションでは、DispatcherServletをルートパスにマッピングするスタイルを採用することがよくあるが、DispatcherServletをルートパスにマッピングすると、Webアプリケーションのドキュメントルート配下のファイルにアクセスできなくなってしまいます。
• この動作を変更するには、SpringMVCが提供している「DispatcherServletで受けたリクエストをデフォルトサーブレットへ転送する機能」を有効化する必要がある

7.5.2 SpringMVC独自の静的リソース解決の仕組み#

• HTTPのキャッシュ制御

• ResourceResolverとResouceTransformerの利用

  • ResourceHttpRequestHandlerには
    • バージョン付き公開パスを使用した静的リソースへのアクセス
    • Gzip化された静的リソースへのアクセス
    • WebJars内の静的リソースのバージョン番号の隠蔽
      • を行う機能がある

• ResourceResolverインターフェース

  • 静的リソースにアクセスするための公開パス
  • サーバー上の物理的な静的リソースを相互に解決するためのメソッドを提供

• ResourceTransformerインターフェース

  • 静的リソースのコンテンツデータを書き換えるためのメソッドを提供

• バージョン付きの公開パスを使用した静的リソースへのアクセス

• Thymeleafでのアクセス方法について確認する

  • ここで紹介されていたhttps://ksoichiro.blogspot.com/2015/04/spring-boot_14.html
  • th:href="@{/css/main.css}"などと記載する

7.6.1 ロケールの解決#

• アプリケーション内で扱うロケール解決には、org.springframework.web.servlet.LocaleResolverインターフェースを使用する

• SpringMVCは、ロケールの保存場所に応じて以下の実装クラスを提供しており、デフォルトではAcceptHeaderLocaleResolverが有効になっている

• 提供されているLocaleResolverの実装クラス

  • AcceptHeaderLocaleResolver
  • SessionLocaleResolver
  • CookieLocaleResolver
  • FixedLocaleResolver

• クライアントからロケールの指定がない場合、デフォルトロケールが利用され、

  • LocaleResolverに指定したデフォルトロケール
  • JVMに指定したロケール
  • OSに指定したロケール
    • の順番で解決されます。

7.6.2 ロケールの利用#

• VIEWからロケールにアクセスするときはSpringのタグを使用する
• Handlerメソッドからロケールにアクセスするときは引数にLocaleを指定する
• Handler以外の場所からロケールにアクセスするときは、RequestContextUtilsのgetLocaleメソッドを使用する

7.6.3 UIを使用したロケールの切り替え#

• 画面などのUIを使用してロケールを切り替える方法について説明

• ロケールの切り替えは、org.springframework.web.servlet.i18n.LocaleChangeInterceptorを利用することで簡単に行うことができる

• LocaleResolverのBean定義

• LocaleChangeInterceptorのBean定義

• ロケール切り替え用の画面要素の表示

1
<a href="?locale=en">English</a>
2
<a href="?locale=ja">Japanese</a>

このリンクをクリクすると、LocaleChangeInterceptorが呼び出され、 リクエストパラメータで指定されたロケールがSpringMVCアプリケーションに反映される

8.2.1 Beanの単体テスト#

• Serviceクラスをテスト

• 依存しているコンポーネントはできるだけモック化することを検討する

  • 外部ファイル参照サービスやDBアクセスなど

8.2.2 DIコンテナ内のBeanに対する結合テスト#

• Springの機能を使用して、DIコンテナ内のリソースを取得してテストを行う
• 単体テストは本当にクラス単体の観点なのに対して、結合テストはプロジェクト内のリソースを結合したテストとみなしている

8.2.3 Spring Testcontext Framework#

• 他のランナーとSpringを併用したい場合は、@ClassRuleと@Ruleを使用すれば実現できるという説明
• TODO: 使用するランナーによって何が違うのかを後で確認する必要ある

8.2.4 DIコンテナのコンフィギュレーション#

DIコンテナを作成するには、 @org.springframework.test.context.ContextConfigurationをテストクラスケースに付与する

• デフォルトのBean定義ファ入りう

• Webアプリケーション向けのDIコンテナのコンフィギュレーション

  • @WebApplicationConfiguration付与について説明
    • Webアプリケーション向けのDIコンテナに加えて、
    • ServletAPIに依存する各種モックオブジェクトなどをテストケースクラスにインジェクションできる

8.2.5 DIコンテナのライフサイクル制御#

• Spring TestContext Framework上に生成されたDIコンテナは、テスト実行時のJavaVMが終了するまでキャッシュされ、必要に応じてテストケース間で共有される仕組みになっています。

• DIコンテナのキャッシュ

  • デフォルトの動作では、同一テストケースクラスのテストメソッドで同じDIコンテナが使われる
  • さらにテストケースクラスが別の場合でも、@ContextConfigurationなどに指定した属性値が同じであれば、キャッシュ済みのDIコンテナが利用される

• DIコンテナの破棄

  • 割愛…TODO: 実際のテストケースの組み方について調査する必要あり

8.2.6 プロファイルの指定#

• Springのプロファイル機能を使用しているアプリケーションに対してテストを行う場合は、@org.springframework.test.context.ActiveProfilesを使う

8.2.7 テスト用のプロパティ値の指定#

• テスト用のプロパティ値を設定できる

  • @org.springframework.test.context.TestPropertySourceを使う

• プロパティ値の指定には２つの方法がある

  • アノテーションに直接指定する
  • プロパティファイルに指定する

8.3.1 テスト用のデータソースの設定#

• Test用のConfigクラスを作成して、既存のコンフィグクラスを上書きする説明

8.3.2 テストデータのセットアップ#

• @Sqlを使用すると、テストケース・メソッドの呼び出し前に任意のSLQを実行できる

1
  /**
2
   * Sqlを付与することで、テストメソッド実行前に任意のSQL文を実行することができる
3
   */
4
  @Test
5
  @Sql({ "/account-delete.sql", "/account-insert-data.sql" })
6
  final void testFindOne() {
7
    Account account = accountRepositry.findOne("001");
8
  }

• メモ
  • @SqlにはJavaSE8で追加された@Repeatableが付与されているため、JavaSE8以降を使う場合は同じ箇所に複数指定できる
    • JavaSE7以前のJavaでも、@org.springframework.test.context.jdbc.SqlGroupを使うことで、複数のSQLを指定できる

8.3.3 テストケース用のトランザクション制御#

• デフォルトではテストデータをセットアップする際に使用するトランザクションと、

• テスト対象のデータアクセス処理で使用するトランザクションは別々になってしまう

• テストが途中で失敗して、レコードが更新されてしまったり、データの状態が変わってしまうため注意が必要

• このような事故を防ぐには、JUnit専用のデータベースを用意しておくと確実

• ローカルなんかも優位だと思う

• あるいは、SpringTestが提供しているテスト用のトランザクション制御の仕組みを利用して防ぐこともできる

• トランザクション境界の移動

  • SpringTestでは、、JUnit実行時のトランザクション境界を、テストケースメソッドの呼び出し前に移動する仕組みを提供している。
  • この仕組を利用すると、@Sqlで指定したSQLファイルの実行とテストを同一のトランザクション内で行うことができる
  • @Transactionalをクラス、メソッドに指定する

• トランザクション境界でのロールバック/コミットの制御

  • 処理が完了したあと、ロールバックするのではなくコミットしたい場合、@Commitを付与すれば実現できる

• 永続コンテキストをフラッシュ

  • JPAやHibernateがEntityへの更新操作を永続コンテキストと呼ばれるインメモリ領域に蓄積しておき、トランザクションのコミット時にSQLを発行する仕組みになっているため、明示的にSQLが発行されるようにフラッシュする必要がある

8.3.4 テーブルの中身の検証#

• JdbcTemplateを使用して検証する
• DIコンテナに入っている同じオブジェクトを使用すること

8.4.1 MockMvcとは#

• アプリケーションサーバー上にデプロイせず、SpringMVCの動作を再現する仕組みを提供するクラス

• 流れ

  1. テストケース・メソッドは、DispatcherServletにリクエストするデータ（リクエストパスやリクエストパラメータなど）をセットアップする
  2. MockMvcは、DispatcherServletに対して擬似的なリクエストを行う。実際に使われるDispatcherServletは、テスト用に拡張されている、org.springframework.test.web.servlet.TestDipacherSevletとなる
  3. DispatcherServletは、リクエスト内容に一致するHandlerのメソッドを呼び出す
  4. テストケースメソッドは、MockMvcが返却する実行結果を受け取り、実行結果の妥当性を検証する

• 動作モードには２つある

  • ユーザー指定のDIコンテナと連携するモード
  • スタンドアロンモード

• SpringMVCのコンフィギュレーションも含めてテストしたい場合、ユーザー指定のDIコンテナと連携するモードを利用すること

• メモ

  • 本書では扱わないが、SpringTestは、MockMvcとHtmlUnitを連携する機能も提供している
  • HtmlUnitと連携することで、テンプレートエンジンが生成したHTMLを検証することができる
  • さらに、SeleniumWebDriverやGebと連携すると、Page Object Patternを活用した可読性および再利用性の高いテストケースを記載することも可能
  • TODO: あとで確認してみる

8.4.2 MockMvcのセットアップ#

• ユーザー指定のDIコンテナと連携するモード

• スタンドアロンモード

  • SpringMVCのコンフィギュレーションはSpringTest側が行い、SpringTestが生成したDIコンテナを使用してSpringMVCの動作を再現

• サーブレットフィルタの追加

  • MockMvcには、サーブレットフィルタを追加することができる

• staticメソッドのインポート

  • テストを書く前に、MockMvcを使用したテストをサポートしてくれるstaticメソッドをインポートします。

1
// よく使用するstaticメソッド
2
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.*;
3
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.*;
4
import static org.springframework.test.web.servlet.result.MockMvcResultHandlers.*;

8.4.3 テストの実行#

• テストを実行する際は、Controllerを呼び出すために必要なリクエストデータをセットアップし、MockMvcにリクエストの実行依頼を行います。

1
  public void testHome() throws Exception {
2
    mockMvc.perform(get("/"))
3
        .andExpect(status().isOk())
4
        .andExpect(forwardedUrl("/WEB-INF/index.jsp"));
5
  }

8.4.4 リクエストデータのセットアップ#

• リクエストデータのセットアップは、
  • org.springframework.test.web.servlet.request.MockHttpServletRequestBuilder
  • org.springframework.test.web.servlet.request.MockMultipartHttpServletRequestBuilder
  • のファクトリメソッドを使用して行います。

1
  @Test
2
  public void testBooks() throws Exception {
3
    mockMvc.perform(get("/books")
4
        .param("name", "Spring")
5
        .accept(MediaType.APPLICATION_JSON)
6
        .header("X-Track-Id", UUID.randomUUID().toString()))
7
        .andExpect(status().isOk());
8
  }

8.4.5 実行結果の検証#

• MockMvcResultMathcersの主なメソッド

  • status
  • header
  • cookie
  • content
  • view
  • forwardedUrl
  • redirectedUrl
  • model
  • flash
  • request

• メモ

  • ResultMatcherでサポートされていない検証を行いたい場合は、以下のいずれかの方法で検証ロジックを実装する
    • 独自のResultMatcherを作成する
    • ResultActionsのandReturnメソッドを呼び出して、MvcResultを取得し、テストケース内で検証ロジックを実装する
  • MEMO: 検証ロジックを複数のテストケースで共有したい場合は、ResultMatcherを作成すること

8.4.6 実行結果の出力#

• 実行結果をログなどに出力する場合は、org.springframework.test.web.servlet.ResultActionsのandDoメソッドを使用する
• andDoメソッドの引数には、実行結果に対して、任意の処理を行うorg.springframewok.test.web.servlet.ResultHandlerを指定する

1
    mockMvc.perform(get("/books"))
2
        .andExpect(status().isOk())
3
        .andDo(log());

• log: 実行結果をデバッグレベルでログ出力する
• pring: 実行結果を任意の出力先に出力する

9.1.1 SpringSecurityの特徴#

• 豊富なオプションの提供
  • SpringSecurityのデフォルト実装の動作をカスタマイズするためのオプションが豊富に提供されている
  • このため、デフォルトの動作がセキュリティ要件に合致しない場合であっても、オプションの値を変更することで要件にあった動作に変更できるケースがある
• 豊富な拡張ポイントの提供
  • SpringSecurityは動作をカスタマイズするための拡張ポイントを豊富に提供します。
  • SpringSecurityのデフォルト実装を使って要件を満たせない場合は、拡張クラスを作成することで要件にあった動作にカスタマイズすることができます。

9.1.2 基本機能#

• セキュリティ対策の基本機能として「認証機能」と「認可機能」の２つを提供しています。

• 認証機能：アプリケーションを利用するユーザーの正当性を確認する機能を提供する

• 認可機能：アプリケーションが提供するリソースや処理に対するアクセスを制御する機能を提供する

9.1.3 強化機能#

• SpringSecurityでは認証と認可という基本機能に加え、

• Webアプリケーションのセキュリティを強化するための機能をいくつか提供している

• セキュリティ対策の強化機能

  • セッション管理機能
  • CSRF対策機能
  • ブラウザのセキュリティ対策機能との連携機能
  • ※他にある！TODO: 他のセキュリティ機能も確認しておく

9.2.1 ライブラリのセットアップ#

• pom.xmlに設定を追加する手順の説明

9.2.2 SpringSecurityのBean定義#

SpringSecurityのコンポーネントをBean定義します

• コンフィギュレーションクラスの作成

1
// SpringSecurityが提供しているコンフィギュレーションクラスがインポートされ、SpringSecurityを利用するために必要となるコンポーネントのBean定義が自動で行われる仕組み
2
@EnableWebSecurity
3
public class AppSecurityConfig extends WebSecurityConfigurerAdapter { // 継承すると、デフォルトで適用されるBean定義を簡単にカスタマイズすることができる
4

5
  @Override
6
  public void configure(WebSecurity web) {
7
    // セキュリティ対策が不要なリソースがある場合、SpringSecurityの処理を適用しないようにする
8
    web.ignoring().antMatchers("/resources/**");
9
  }
10
}

• web.xmlへの設定追加方法説明
  • TODO: SpringBootだと必要？

9.2.3 サーブレットフィルタの設定#

• 最後に、SpringSecurityが提供しているサーブレットフィルタクラス（FilterChainProxy）をサーブレットコンテナに登録する

• TODO: SpringBootだとConfigでフィルター追加する

  • https://qiita.com/R-STYLE/items/61a3b6a678cb0ff00edf
  • https://qiita.com/opengl-8080/items/c105152c9ca48509bd0c

• メモ

  • Sevlet3.0以降のサーブレットコンテナでは、サーブレットコンテナの初期化処理をJavaのコードで行うことができる
  • SpringSecurityでは、サーブレットコンテナの初期化処理をJavaを使って行うためのサポートクラス説いて、
  • AbstractSecurityWebApplicationInitializerという抽象クラスを提供しています
  • 以下の初期化処理を自動で行ってくれる
    • ContextLoaderListenerをサーブレットコンテナに登録する処理
    • SpringSecurityのサーブレットフィルタクラスをサーブレットコンテナに登録する処理
    • 参考：https://qiita.com/opengl-8080/items/c105152c9ca48509bd0c

9.3.1 Spring Securityのモジュール構成#

• 提供しているモジュールを紹介

• コンポーネントの役割などに応じてモジュール分割されており、標準的なWebアプリケーションに対してセキュリティ対策を講じる際に必要となるモジュールは以下の４つになる

  • spring-security-core: 認証と認可機能を実現するためのコアなコンポーネントが格納されている
  • spring-security-web: Webアプリケーションのセキュリティ対策を実現するためのコンポーネントが格納されている
  • spring-security-config: 各モジュールから提供されているコンポーネントのセットアップをサポートするためのコンポーネント（Java ConfigをサポートするクラスやXMLネームスペースを解析するクラスなど）が格納されている
  • spring-security-taglibs: 認証情報や認可機能にアクセスするためのJSPタグライブラリが格納されている

• 本書で使い方を紹介しないが、上記以外にも以下のようなモジュールがある

  • 一般的に利用される認証方法（LDAP、OpenID、CASなど）をサポートするためのモジュール
  • ACL（AccessControlList）を使用したドメインオブジェクトの認可制御を行うモジュール
  • SpringのWebSocket機能に対してセキュリティ対策を追加するためのモジュール
  • SpringSecurityの機能を用いる処理に対するテストを支援するためのモジュール

• メモ

  • SpringSecurityのモジュールではないが、OAuth2.0の仕組みを使用してAPIの認可を実現するためのモジュール（spring-security-oauth2）などが姉妹ライブラリとして提供されている

9.3.2 フレームワークのアーキテクチャ#

• 処理の流れ

  1. クライアントはWebアプリケーションに対してリクエストを送る
  2. SpringSecurityのFilterChainProxyクラスがリクエストを受け取り、HttpFirewallインターフェースのメソッドを呼び出して、HttpServletRequestとHttpServletResponseに対してファイアウォール機能を組み込む
  3. FilterChainProxyクラスはSecurityFilterChainに設定されているセキュリティ対策用のSecurityFilterクラスに処理を移譲する
  4. SecurityFilterChainには複数のSecurityFilterが設定されており、SecurityFilterの処理が正常に終了すると皇族のSecurityFilterが呼び出される
  5. 最後のSecurityFilterの処理が正常に終了した場合、後続処理を呼び出し、Webアプリケーション内のリソースへアクセスする
  6. FilterChainProxyクラスは、Webアプリケーションから返却されたリソースをクライアントに返却する

• FilterChainProxy

  • FilterChainProxyクラスは、フレームワーク処理のエントリーポイントとなるサーブレットフィルタクラス
  • このクラスはフレームワーク処理の全体の流れを制御し、具体的なセキュリティ対策処理はSecurityFilterに移譲するスタイルとなっている

• HttpFirewall

  • HttpFirewallインターフェースは、HttpServletRequestとHttpServletResponseに対して、ファイアウォール機能を組み込むためのインターフェースです。デフォルトでは、DefaultHttpFirewallクラスが使用され、ディレクトリトラバーサル攻撃や、不正なリダイレクト先の指定によるHTTPレスポンス分割攻撃に対するチェックなどが実装されている

• SecurityFilterChain

  • SecurityFilterChainインターフェースは、FilterChainProxyが受け取ったリクエストに対して適用する「SecurityFilterリスト」を管理するためのインターフェース
  • デフォルトではDefaultSecurityFilterChainクラスが使用され、以下のようなBean定義を行うと、指定したパスパターンごとに異なるセキュリティ対策が適用できます。

• Security Filter

  • SecurityFilterクラスは、フレームワーク機能やセキュリティ対策機能を提供するサーブレットフィルタクラスです。
  • SpringSecurityは、複数のSecurityFilterを連鎖させることで、Webアプリケーションのセキュリティ対策を行う仕組みになっています。

• コアなSecurityFilter

  • SecurityContextPersistenceFilter
  • UsernamePasswordAuthenticationFilter
  • LogoutFilter
  • FilterSecurityInterceptor
  • ExceptionTranslationFilter

9.4.1 認証処理の仕組み#

• 認証処理の流れ

  1. クライントは認証処理を行うパスに対して資格情報（ユーザー名とパスワード）を指定してリクエストを送信する
  2. Authentication Filterはリクエストから資格情報を取得し、AuthenticationManagerクラスの認証処理を呼び出す
  3. ProviderManager（デフォルトで使用されるAuthenticationManagerの実装クラス）は、実際の認証処理をAuthenticationProviderインターフェースの実装クラスに移譲する

• メモ

  • Authentication FilterとAuthenticationProviderの実装クラスは複数用意されており、要件に合わせて使用するクラスを選択する仕組みになっている
  • TODO: 選択できるクラスについて確認

• Authentication Filter

  • 認証方式に対する実装を提供するサーブレットフィルタ
  • 本書では、フォーム認証用のサーブレットフィルタクラス（UsernamePasswordAuthenticationFilter）をシヨすうる前提で説明しますが、SpringSecurityはBasic認証、Digest認証、Remember Me 認証用のサーブレットフィルタクラスも提供しています

• AuthenticationManager

  • 認証処理を実行するためのインターフェース
  • SpringSecurityが提供するデフォルトの実装（ProviderManager）では、実際の認証処理はAuthenticationProviderに移譲し、AuthenticationProviderで行われた認証処理結果をハンドリングする仕組みになっています。

• AuthenticationProvider

  • 認証処理の実装をて依拠するためのインターフェース
  • 本書では、データストアに登録しているユーザーの資格情報とユーザーの状態をチェックして認証処理を行う実装クラス（DaoAuthenticationProvider）を使用する前提で説明しますが、SpringSecurityは認証方法別の実装クラスも提供している。
    • ※DBだけでなく他の認証方式にも対応しているという意味だと理解

9.4.2 フォーム認証#

• SpringSecurityは以下のような流れでフォーム認証を行う

  1. クライアントは、フォーム認証を行うパスに対して資格情報（ユーザー名とパスワード）をリクエストパラメータとして送信する
  2. UsernamePasswordAuthenticationFilterクラスは、リクエストパラメータから資格情報を取得して、AuthenticationManagerの認証処理を呼び出す
  3. UsernamePasswordAuthenticationFilterクラスは、AuthenticationManagerから返却された認証結果をハンドリングする。認証処理が成功した場合は、AuthenticationSuccessHandlerのメソッドを、認証処理が失敗した場合は、AuthenticationFailureHandlerのメソッドを呼び出し、画面遷移を行う

• フォーム認証の適用

  • Bean定義

1
// SpringSecurityが提供しているコンフィギュレーションクラスがインポートされ、SpringSecurityを利用するために必要となるコンポーネントのBean定義が自動で行われる仕組み
2
@EnableWebSecurity
3
public class AppSecurityConfig extends WebSecurityConfigurerAdapter { // 継承すると、デフォルトで適用されるBean定義を簡単にカスタマイズすることができる
4

5
  @Override
6
  public void configure(WebSecurity web) {
7
    // セキュリティ対策が不要なリソースがある場合、SpringSecurityの処理を適用しないようにする
8
    web.ignoring().antMatchers("/resources/**");
9
  }
10

11
  // ★追加！！
12
  @Override
13
  public void configure(HttpSecurity http) throws Exception {
14
    http.formLogin();
15
    // formLoginメソッドを呼び出すと、フォーム認証が有効になり、FormLoginConfigurerのインスタンスが返却される。
16
  }
17
}

• デフォルトの動作

  • SpringSecurityのデフォルトの動作では、/loginに対して、GETメソッドでアクセスするとSpringSecurityが用意しているデフォルトのログインフォームが表示され、ログインボタンを謳歌すると/loginに対してPOSTメソッドでアクセスして認証処理を行います。

• ログインフォームの作成

  • SpringSecurityは、フォーム認証用のログインフォームをデフォルトで提供しているが、そのまま利用するケースは殆どないと思う
  • ここでは、自身で作成したログインフォームをSpringSecurityに適用する方法を紹介する
  • まず、ログインフォームを表示するためのJSPを作成
  • ここでは、SpringMVCのViewResolverに指定しているベースパス（src/main/webapp/views/）の直下にJSPを配置し、SpringMVC経由でログインフォームを表示する前提で説明

• ログインフォームをSpringSecurityに適用するために以下のようなBean定義を行う

  1. loginPageメソッドを呼び出し、ログインフォームを表示するためのパスを指定する
     • 匿名のユーザーが認証を必要するリソースにアクセスした場合、ここで指定したパスにリダイレクトしてログインフォームを表示する仕組みになっている。loginPageメソッドに与えられた引数によって、認証パス（loginProcessingUrl）も連動して変わる
  2. permitAll()メソッドを呼び出して、すべてのユーザーに対してログインフォームへのアクセス件を付与する

1
  @Override
2
  public void configure(HttpSecurity http) throws Exception {
3
    //    http.addFilter(this.preAuthenticatedProcessingFilter());
4
    //    http.formLogin();
5
    http.formLogin()
6
        .loginPage("/login") // 認証を必要とするURLに遷移した場合、このURLにリダイレクトしてログインフォームを表示する仕組み
7
        .permitAll(); // すべてのユーザーに対してログインフォームへのアクセス件を付与する
8
    http.authorizeRequests()
9
        .anyRequest()
10
        .authenticated();
11
    // formLoginメソッドを呼び出すと、フォーム認証が有効になり、FormLoginConfigurerのインスタンスが返却される。
12
  }

• デフォルト動作のカスタマイズ
  • フォーム認証処理のカスタマイズポイントとして
    • 認証パス
    • 資格情報を送るリクエストパラメータ名の変更方法を紹介

1
    http.formLogin()
2
        //.loginPage("/login")
3
        .loginProcessingUrl("authenticate")
4
        .usernameParameter("uid")
5
        .passwordParameter("pwd")
6
        .permitAll();

• loginPageもloginProcessingUrlもやっていることは同じらしい
  • http://www.ne.jp/asahi/hishidama/home/tech/java/spring/boot/web/form-auth.html

9.4.3 認証成功時のレスポンス#

• SpringSecurityは、認証成功時のレスポンスを制御するためのコンポーネントとして、AuthenticationSuccessHandlerというインターフェースと実装クラスを提供している

• AuthenticationSuccessHandlerの実装クラス

  • SavedRequestAwareAuthenticationSuccessHanlder: 認証前にアクセスを試みたURLにリダイレクト（デフォルト）
  • SimpleUrlAuthenticastionSuccessHandler: コンストラクタに指定したURLにリダイレクトまたはフォワードする

• デフォルトの動作

  • 認証前にアクセスを拒否したリクエストをHTTPセッションに保存しておいて、認証が成功した際にアクセスを拒否したリクエストを復元してリダイレクトする仕組みになっている

• デフォルト動作のカスタマイズ

  • 認証成功時のレスポンスのカスタマイズポイントとして、認証成功時に遷移するデフォルトのパスの変更方法を紹介

1
    http.formLogin()
2
        .loginPage("/login") // 認証を必要とするURLに遷移した場合、このURLにリダイレクトしてログインフォームを表示する仕組み
3
        .defaultSuccessUrl("/menu") // 認証成功時のデフォルトアクセスはルート。カスタマイズするために記載
4
        .permitAll(); // すべてのユーザーに対してログインフォームへのアクセス件を付与する

9.4.5 データベース認証#

• データベース認証の仕組み

  • SpringSecurityはクライアントからの認証依頼を受け、DaoAuthenticationProviderの認証処理を呼び出す
  • DaoAuthenticationProviderは、UserDetailsServiceのユーザー情報取得処理を呼び出す
  • UserDetailsServiceの実装クラスは、データストアからユーザー情報を取得する
  • UserDetailsServiceの実装クラスは、データストアから取得したユーザー情報からUserDetailsを生成する
  • DaoAuthenticationProviderは、UserDetailsServiceから返却されたUserDetailsとクライアントが指定した認証情報との照合を行い、クライアントが指定したユーザーの正当性をチェックする。クライアントが指定したユーザーが正当なユーザーでない場合は、認証例外をスローする

• メモ

  • SpringSecurityはユーザー情報をリレーショナルデータベースからJDBC経由で取得するための実装クラスを提供しているが、最低限の認証処理しか行わないため、そのまま利用できるケースは少ないと思われる
  • そのため本書では、UserDetailsとUserDetailsServiceの実装クラスを作成する方法を紹介します。

• UserDetailsの作成

  • MEMO:※細かいのでソースを確認 後で追記

• 認証処理の適用

9.4.6 パスワードのハッシュ化#

• いくつか、パスワードを扱う実装クラスが提供されている
• MEMO:※細かいのでソースを確認 後で追記

9.4.7 認証イベントのハンドリング#

• SpringSecurityは、SpringFrameworkが提供しているイベント通知の仕組みを利用して、

• 認証処理の結果を他のコンポーネントへ連携する仕組みを提供しています

• この仕組を利用すると以下のようなセキュリティ要件をSpringSecurityの認証機能に組み込むことができます

  • 認証成功、失敗などの認証履歴をデータベースやログに保存したい
  • パスワードを連続して誤った場合にアカウントをロックしたい

• 認証イベントの通知は以下のような仕組みで行われる

• 認証イベントの通知の流れ

  1. SpringSecurityの認証機能は、認証結果をAuthenticationEventPublisherに渡して認証イベントの通知依頼を行う
  2. AuthenticationEventPublisherインターフェースのデフォルトの実装クラスは、認証結果に対応する認証イベントクラスのインスタンスを生成し、ApplicationEventPublisherに渡してイベントの通知依頼を行う
  3. ApplicationEventPublisherインターフェースの実測クラスは、ApplicationListenerインターフェースの実装クラスにイベントを通知する
  4. ApplicationListenerの実装クラスの１つであるApplicationListenerMethodAdaptorは、@org.springframework.context.event.EventLintenerが付与されているメソッドを呼び出してイベントを通知する

• メモ

  • Spring4.1まではApplicationListenerインターフェースの実装クラスを作成して、イベントを受け取る必要があった
  • Spring4.2からは、POJOに@EventListenerを付与したメソッドを実装するだけでイベントを受け取ることができる
  • Spring4.2以降も、従来と同じ用にApplicationListenerインターフェースの実装クラスを作成してイベントを受け取ることができる

• 認証成功イベント

  • 認証が成功したときにSpringSecurityが通知する主なイベントは以下の３つです。
  • この３つのイベントは途中でエラーが発生しなければ、以下の順番ですべて通知されます
    • AuthenticationSuccessEvent
      • AuthenticationProviderによる認証処理が成功したことを通知する。
      • このイベントをハンドリングすると、クライアントが正しい認証情報を指定したことを検知することができるが、後続の認証処理でエラーになる可能性がある
    • SessionFixationProtectionEvent
      • セッション固定攻撃対策の処理（セッションIDの変更処理）が成功したことを通知する。このイベントをハンドリングすると、変更後のセッションIDを検知することができる
    • InteractiveAuthenticationSuccessEvent
      • 認証処理がすべて成功したことを通知する。このイベントをハンドリングすると、画面遷移を除くすべての認証処理が成功したことを検知することができる

• 認証失敗イベント

  • 認証が失敗したときにSpringSecurityが通知する主なイベントは以下の通り
  • 認証に失敗した場合は、以下のいずれか１つのイベントが通知される
    • AuthenticationFailureBadCredentialsEvent
    • AuthenticationFailureDisabledEvent
    • AuthenticationFailureLockedEvent
    • AuthenticationFailureExpiredEvent
    • AuthenticationFailureCredentialsExpiredEvent
    • AuthenticationFailureServiceExceptionEvent

• イベントリスナの作成

  • 認証イベントの通知を受け取って処理を行いたい場合、@EventListenerを付与したメソッドを実装したクラスを作成し、DIコンテナに登録するだけ

1
/**
2
 * - 認証イベントの通知の流れ
3
 *    1. SpringSecurityの認証機能は、認証結果をAuthenticationEventPublisherに渡して認証イベントの通知依頼を行う
4
 *    2. AuthenticationEventPublisherインターフェースのデフォルトの実装クラスは、認証結果に対応する認証イベントクラスのインスタンスを生成し、ApplicationEventPublisherに渡してイベントの通知依頼を行う
5
 *    3. ApplicationEventPublisherインターフェースの実測クラスは、ApplicationListenerインターフェースの実装クラスにイベントを通知する
6
 *    4. ApplicationListenerの実装クラスの１つであるApplicationListenerMethodAdaptorは、`@org.springframework.context.event.EventLintener`が付与されているメソッドを呼び出してイベントを通知する
7
 *
8
 * - `@EventLitener`を付与したメソッドを実装するだけで認証成功/失敗時の処理を実装できる仕組み
9
 * @author Tomo
10
 *
11
 */
12
@Slf4j
13
@Component
14
public class AppSecurityEventListener {
15

16
  // ==============================
17
  //  SUCCESS EVENT HANDLERS
18
  // ==============================
19

20
  /**
21
   * AuthenticationProviderによる認証処理が成功したことを通知する。
22
   * このイベントをハンドリングすると、クライアントが正しい認証情報を指定したことを検知することができるが、
23
   * 後続の認証処理でエラーになる可能性がある。
24
   * @param event
25
   */
26
  @EventListener
27
  public void handleAuthenticationSuccess(AuthenticationSuccessEvent event) {
28
    //
29
  }
30

31
  /**
32
   * セッション固定攻撃対策の処理（セッションIDの変更処理）が成功したことを通知する。
33
   * このイベントをハンドリングすると、変更後のセッションIDを検知することができる。
34
   * @param event
35
   */
36
  @EventListener
37
  public void handleSessionFixationProtection(SessionFixationProtectionEvent event) {
38
    //
39
  }
40

41
  /**
42
   * 認証処理がすべて成功したことを通知する。
43
   * このイベントをハンドリングすると、画面遷移を除くすべての認証処理が成功したことを検知することができる。
44
   * @param event
45
   */
46
  @EventListener
47
  public void handleInteractiveAuthenticationSuccess(InteractiveAuthenticationSuccessEvent event) {
48
    //
49
  }
50

51
  // ==============================
52
  //  FAILURE EVENT HANDLERS
53
  // ==============================
54

55
  @EventListener
56
  public void handleBadCredentials(AuthenticationFailureBadCredentialsEvent event) {
57
    log.info("BAD Credentials is detected. username : {}", event.getAuthentication().getName());
58
  }
59

60
  @EventListener
61
  public void handleDisabled(AuthenticationFailureDisabledEvent event) {
62
    log.info("Disabled user is detected. username : {}", event.getAuthentication().getName());
63
  }
64

65
  @EventListener
66
  public void handleLocked(AuthenticationFailureLockedEvent event) {
67
    log.info("Locked user is detected. username : {}", event.getAuthentication().getName());
68
  }
69

70
  @EventListener
71
  public void handleExpired(AuthenticationFailureExpiredEvent event) {
72
    log.info("Expired user is detected. username : {}", event.getAuthentication().getName());
73
  }
74

75
  @EventListener
76
  public void handleCredentialsExpired(AuthenticationFailureCredentialsExpiredEvent event) {
77
    log.info("CredentialsExpired is detected. username : {}", event.getAuthentication().getName());
78
  }
79

80
  @EventListener
81
  public void handleServiceException(AuthenticationFailureServiceExceptionEvent event) {
82
    log.info("ServiceException is detected. username : {}", event.getAuthentication().getName());
83
  }
84
}

9.4.8 ログアウト#

• SpringSecurityは以下のような流れでログアウト処理を行う

  1. クライアントは、ログアウト処理を行うためのパスにリクエストを送信する
  2. LogoutFilterは、LogoutHandlerのメソッドを呼び出してログアウト処理を行う
  3. LogoutFilterは、LogoutSuccessHandlerのメソッドを呼び出して画面遷移を行う

• LogoutHandlerの実装クラス

  • SecurityContextLogoutHandler: 認証情報のクリアとセッションの破棄を行う
  • CookieClearingLogoutHandler: 指定したクッキーの削除するためのレスポンスを行う
  • CsrfLogoutHandler: CSRF対策用のトークンの破棄を行う

• こららのLogoutHandlerは、SpringSecurityが提供しているBean定義をサポートするクラスが自動でLogoutFilterに設定する仕組みになっているので、基本的にはアプリケーションの開発者が直接意識する必要はない

• ログアウト処理の適用

  • ログアウト処理を適用するには、以下のようなBean定義を行う必要がある

1
    http.authorizeRequests()
2
        .antMatchers("/", "/find", "/login", "/signup", "/error", "/login-error").permitAll()
3
        .anyRequest().authenticated()
4
        .and()
5
        // Login処理
6
        .formLogin()
7
        .loginPage("/login") // 認証を必要とするURLに遷移した場合、このURLにリダイレクトしてログインフォームを表示する仕組み
8
        .defaultSuccessUrl("/menu") // 認証成功時のデフォルトアクセスはルート。カスタマイズするために記載
9
        .failureUrl("/login") // 認証失敗時ログイン画面に戻す
10
        .usernameParameter("id")
11
        .passwordParameter("password")
12
        .and()
13
        // Logout処理
14
        .logout()
15
        .logoutRequestMatcher(new AntPathRequestMatcher("logout**"))
16
        .logoutSuccessUrl("/login")
17
        .permitAll(); // すべてのユーザーに対してログインフォームへのアクセス件を付与する

• デフォルトの動作のカスタマイズ
  • 遷移先を変える logoutSuccessUrlの引数を変えてあげる

9.4.10 認証情報へのアクセス#

• 認証済みのユーザーの認証情報は、SpringSecurityのデフォルト実装では、セッションに格納される

• セッションに格納された認証情報は、リクエストごとにSecurityContextPersistenceFilterクラスによって

• SecurityContextHolderというクラスに格納され、同一スレッド内であればどこからでもアクセスすることができる用になる

• Javaからのアクセス

  • 一般的な業務アプリケーションでは、「いつ」「誰が」「どのデータに」「どのようなアクセスをしたか」を
  • 記録する監査ログを取得することがある。この要件を実現する際の、「誰が」は、認証情報から取得できる

1
// 認証情報（Authenticationオブジェクト）を取得する
2
Authentication authentication =
3
    SecurityContextHolder.getContext().getAuthentication();
4

5
String userUuid = null;
6
// Authentication#getPrincipal()メソッドを呼び出して、UserDetailsオブジェクトを取得する
7
// 認証済みでない場合は、匿名ユーザーを表す文字列が返却されるので注意
8
if (authentication.getPrincipal() instanceof AccountUserDetails) {
9
    AccountUserDetails userDetails = AccountUserDetails.class.cast(authentication.getPrincipal());
10
    // UserDetailsから処理に必要な情報を取得する
11
    userUuid = userDetails.getAccount().getUserUuid();
12
}

• アノテーションでアクセスした方が良さそう

  • https://qiita.com/Hyuga-Tsukui/items/81990938e43c7dff35cf

• JSPからのアクセス

  • 一般的なWebアプリケーションでは、ログインユーザーのユーザー情報などを画面に表示することがある。

1
<% taglib prefix="sec" uri="http://www.springframework.org/security/tags" %>
2
<%-- ... --%>
3
ようこそ
4
<sec:authentication property="principal.account.lastName" />
5
さん。

• 追記：thymeleafからのアクセス

1
<!DOCTYPE html>
2
<html xmlns:th="http://www.thymeleaf.org"
3
      xmlns:sec="http://www.thymeleaf.org/thymeleaf-extras-springsecurity4"> <!-- これを追加してThymeleafからSpringSecurityを利用 -->
4

5
<!-- 省略 -->
6
<body>
7
  <h1>こんにちは、<span sec:authentication="principal.userId"></span>さん</h1> <!-- principal.メンバ変数名　で参照できる　-->
8
</body>

9.4.11 認証処理とSpringMVCの連携#

• SpringSecurityは、SpringMVCと連携するためのコンポーネントをいくつか提供している
• ここでは、認証処理と連携するためのコンポーネントの使い方を紹介
• SpringSecurityは認証情報（UserDetails）をSpringMVCのコントローラーのメソッドに引き渡すためのコンポーネントとして、AuthenticationPrincipalArgumentResolverというクラスを提供している
• これを使用すると、コントローラーのメソッド引数として、UserDetailsインターフェースまたはその実装クラスのインスタンスを受け取ることができる

1
@Controller
2
public class Controller {
3

4
    @RequestMapping("/")
5
    public index(@AuthenticationPrincipal UserDetailsImpl userDetails) {
6
        System.out.println(userDetails.getUserId) // userId
7
        System.out.println(userDetails.getPassword) //password
8
        System.out.println(userDetails.getHoge) //hoge
9
    }

9.4.12 エラーメッセージ#

• 認証に失敗した場合、SpringSecurityが用意しているエラーメッセージが表示されます

• このエラーメッセージは内容を変更したり、表示しないようにすることができます。

• エラーメッセージの変更

  • 認証失敗時に表示されるエラーメッセージを変更したい場合は、MessageSourceで読み込んでいるプロパティファイルに
  • SpringSecurityが用意しているメッセージの定義を追加してください

1
AbstractUserDetailsAuthenticationProvider.badCredentials = 入力した認証情報に誤りがあります。
2
AbstractUserDetailsAuthenticationProvider.credentialsExpired = 認証情報の利用期限が切れています。
3
AbstractUserDetailsAuthenticationProvider.disabled = 無効なアカウントです。
4
AbstractUserDetailsAuthenticationProvider.expired = アカウントの期限が切れています。
5
AbstractUserDetailsAuthenticationProvider.locked = アカウントがロックされています。

• この他にも多数のメッセージが用意されている

• 種類を確認するには、spring-security-coreモジュールのjarファイルの中のorg/springframework/security/message.propertiesファイルを確認してください

• メッセージ定義定数クラスは自動生成するべきな件

  • https://terasolunaorg.github.io/guideline/1.0.x/ja/ArchitectureInDetail/MessageManagement.html

• メモ

  • MessageSourceの中でプロパティファイルをISO 8859-1(デフォルト)で読み込んでいる場合は、マルチバイト文字は
  • Unicodeコード（\udddd表記）形式に変換する必要がある。
  • なお、プロパティファイルを任意の文字コードで読み込む場合は、MessageSourceのdefaultEncodingプロパティに文字コードを指定してください。

1
  @Bean
2
  public MessageSource messageSource() {
3
    ResourceBundleMessageSource messageSource = new ResourceBundleMessageSource();
4
    messageSource.setBasenames("i18n/messages"); // クラスパス上に格納されているプロパティファイル（拡張子は除く）を指定する
5
    messageSource.setDefaultEncoding("UTF-8"); // ★ここのこと！
6
    return messageSource;
7
  }

• システムエラー時のメッセージ

  • 認証処理の中で予期しないエラー（システムエラーなど）が発生した場合、InternalAuthenticationServiceExceptionという例外が発生する。InteractiveAuthenticationServiceExceptionが保持するメッセージには、
  • 原因例外のメッセージが設定されるため画面にそのまま表示するのは好ましくない
  • システムエラーの例外メッセージを画面に表示しない用にするには、ExceptionMappingAuthenticationFailureHandlerやDelegatingAuthenticationFailureHandlerを使用して、InternalAuthenticationServiceExceptionが発生したときの遷移先をシステムエラー画面にするのが良いでしょう。

• TODO: この辺見て実装する

  • https://qiita.com/rubytomato@github/items/6c6318c948398fa62275

9.5.1 認可処理の仕組み#

• SpringSecrityが提供する認証処理の仕組みを理解しましょう

• 以下のような流れで認可処理を行います

  1. クライアントが任意のリソースにアクセスする
  2. FilterSecurityInterceptorクラスは、AccessDecisionManagerインターフェースのメソッドを呼び出し、リソースへのアクセス権の有無をチェックする
  3. AffirmativeBasedクラス（デフォルトで使用されるAccessDecisionManagerの実装クラス）は、AccessDecisionVoterインターフェースのメソッドを呼び出し、アクセス件の有無を投票してもらう
  4. FilterSecurityInterceptorは、AccessDecisionManagerによってアクセス権が付与された場合に限り、リソースへアクセスする

• ExceptionTranslationFilter

  • 認可処理（AccessDecisionManager）で発生した例外をハンドリングし、
  • クライアントに適切なレスポンスを行うためのサーブレットフィルタ
  • デフォルトの実装では、未認証ユーザーからのアクセスの場合は、認証を促すレスポンス、認証済みユーザーからのアクセスの場合は、認可エラーを通知するレスポンスを返却する

• FilterSecurityInterceptor

  • HTTPリクエストに対して認可処理を適用するためのサーブレットフィルタで、実際の認可処理はAccessDecisionManagerに移譲しています。
  • AccessDecisionManagerインターフェースのメソッドを呼び出す際には、クライアントがアクセスしようとしたWebリソースに指定されているアクセスポリシーを連携します。

• AccessDecisionManager

  • アクセスしようとしたリソースに対してアクセス権があるかチェックを行うためのインターフェース
  • SpringSecurityが提供する実装クラスでは、このあと紹介するAccessDecisionVoterというインターフェースのメソッドを呼び出してアクセス権を付与するか否かを投票するしくみになっており、デフォルトで適用されるクラスはAffirmativeBasedクラスです。AffirmativeBasedクラスは、いずれかのAccessDecisionVoterが付与を投票した場合にアクセス権を与える実装クラス

• AccessDecisionVoter

  • アクセスしようとしたリソースに指定されているアクセスポリシーを参照し、アクセス権を付与するか否かを投票する（付与、拒否、棄権）するためのインターフェース
  • SpringSecurityではいくつかの実装クラスを提供しているが、4.0からデフォルトで適用されるクラスは、WebExpressionVoterに統一されている
  • WebExpressionVoterはSpring Expression Languageを使用して、利用者が持つ、権限情報とリクエスト情報を参照して投票を行う実装クラス

9.5.2 アクセスポリシーの記述方法#

• SpringSecurityは、アクセスポリシーを指定する記述方法として、SpringExpressionLanguage（SpEL）をサポート

• SpELを使わない方法もあるが、本書では、Expressionを使ってアクセスポリシーを指定する方法で解説する

• CommonExpressions

  • ※割愛

9.5.3 Webリソースへの認可（JavaConfig編）#

• JavaConfigを使用して、Webリソースに対してアクセスポリシーを定義する方法について説明

• アクセスポリシーを適用するWebリソースの指定

  • まずは、アクセスポリシーを適用するリソースを指定
  • アクセスポリシーを適用するリソースの指定は、ExpressionInterceptUrlRegistryクラスの以下のメソッドを呼び出して行います。
    • antMatchers
    • regexMatchers
    • requestMatchers
    • anyRequests

1
  @Override
2
  public void configure(HttpSecurity http) throws Exception {
3
    //    http.addFilter(this.preAuthenticatedProcessingFilter());
4
    //    http.formLogin();
5
    http.authorizeRequests()
6
        .antMatchers("/", "/find", "/login", "/signup", "/error", "/login-error").permitAll()
7
        // ★記載順には気をつける必要がある
8
        .antMatchers("/admin/accounts/***").hasRole("ACCOUNT_MANAGER")
9
        .antMatchers("/admin/***").hasRole("ADMIN")
10
        .anyRequest().authenticated()

• アクセスポリシーの指定
  • 次に、アクセスポリシーを指定します。
  • アクセスポリシーの指定は、AuthorizedUrlクラスのメソッドを使用して行います。

1
    http.authorizeRequests()
2
        .antMatchers("/", "/find", "/login", "/signup", "/error", "/login-error").permitAll()
3
        //        .antMatchers("/admin/accounts/***").hasRole("ACCOUNT_MANAGER")
4
        //        .antMatchers("/admin/***").hasRole("ADMIN")
5
        .antMatchers("/admin/***").access("hasIpAddress('127.0.0.1') and hasRole('CONFIGURATION_MANAGER')")
6
        .antMatchers("/admin/***").hasRole("ADMIN")
7
        .anyRequest().authenticated()

9.5.4 Webリソースへの認可（XMLファイル編）#

• 割愛

9.5.5 メソッドへの認可#

• SpringSecurityは、SpringAOPの仕組みを利用して、アプリケーションコンテキスト内で管理しているBeanのメソッド呼び出しに対して認可処理を行う仕組みを提供しています。

  • メソッドに対応する認可処理を使用すると、メソッドの引数や戻り値のオブジェクトの状態を参照できるため、よりきめ細かいアクセスポリシーの定義が行える
  • メソッドへの認可を使用する場合は、メソッド呼び出しに対して認可処理を行うためのコンポーネント（AOP）を有効にしてから、アクセスポリシーをクラスやメソッドのアノテーションに定義します。
    • つまり
      • AOP有効化
      • メソッドにアノテーション定義

• SpringSecurityがサポートしているアノテーションは以下

  • @PreAuthorize,@PostAuthorize,@PreFilter,@PostFilter: SpringSecurityのアノテーション
  • @Secured: SpringSecurityのアノテーション
  • JSR250(javax.annotation.securityパッケージ)のアノテーション（@RolesAllowedなど）

• 本書では、アクセスポリシーの指定にExpressionを使用することができる @PreAuthorizeと@PostAuthorizeを紹介する

• メソッド認可の有効化

  • まず、メソッドに対して認可処理を行うAOPを有効化します

1
@EnableGlobalMethodSecurity(prePostEnabled = true) // メソッドに対して認可処理を行うAOPを有効化 prePostEnabled属性にtrueを指定すると、Expressionを使用してアクセスポリシーを定義することができるアノテーションが有効になる
2
public class AppSecurityConfig extends WebSecurityConfigurerAdapter {
3
}

• メソッド実行前に適用するアクセスポリシーの指定
  • メソッドの実行前に適用するアクセスポリシーを指定する場合は@PreAuthorizeを使用する
  • @PreAuthorizeのvalue属性に指定したExpressionの結果がtrueになるとメソッドの実行が許可される

1
// 管理者以外の人間が他人のアカウント情報にアクセスできないように定義している
2
@PreAuthorize("hasRole('ADMIN') or (#username == principal.username)")
3
public Account findOne(String username) {
4
  return accountRepository.findOne(username);
5
}

• ここでポイントになるのが、Expressionの中からメソッドの引数にアクセスしている部分

• 具体的には、#usernameの部分が引数にアクセスしている部分になる

• Expression内で「# + 引数名」形式のExpressionを指定するとメソッドの引数にアクセスすることができる

• メモ

  • SpringSecurityは、クラスに出力されているデバッグ情報から引数名を解決する仕組みになっているが、
  • アノテーション（@P）を使用して明示的に引数名を指定することもできる
  • 以下の場合は、明示的に引数名を指定してあげる必要がある
    • 引数のデバッグ情報を出力しない
    • Expressionの中から実際の引数名とは別の名前を使ってアクセスする（例：短縮した名前）

1
@PreAuthorize("hasRole('ADMIN') or (#username == principal.username)")
2
public Account findOne(@P("username") String username) {
3
  return accountRepository.findOne(username);
4
}

• JavaSE8から追加されたコンパイルオプション（-parameters）を使用すると、メソッドパラメータにリフレクション用のメタデータが生成されるため、アノテーションを指定しなくても引数名を解決してくれる

• メソッド実行後に適用するアクセスポリシーの指定

  • @PostAuthorizeを使用する

1
@PreAuthorize("hasRole('DEPARTMENT_MANAGER')")
2
@PostAuthorize("(returnObject == null) or (returnObject.departmentCode == principal.account.departmentCode)")
3
public Account findOne(@P("username") String username) {
4
  return accountRepository.findOne(username);
5
}

9.5.6 JSPの画面項目への認可#

SpringSecurityはJSPタグライブラリを使用してJSPの画面項目に対して認可処理を適用することができる

• ※管理者の場合、この項目を表示するなどの制御
  • このURLへ遷移させるなどの制御

9.5.7 認可エラー時のレスポンス#

• SpringSecurityはリソースへのアクセスを拒否した場合、以下のような流れでエラーハンドリング、レスポンスを行う

  1. SpringSecurityは、リソースやメソッドへのアクセスを拒否するために、AccessDeniedExceptionをスローする
  2. ExceptionTranslationFilterクラスは、AccessDeniedExceptionを捕捉し、AccessDeniedHandlerまたは、AuthenticationEntryPointインターフェースのメソッドを呼び出してエラー応答を行う
  3. 認証済みのユーザーからのアクセスの場合は、AccessDeniedHandlerインターフェースのメソッドを呼び出してエラー応答を行う
  4. 未認証ユーザーからのアクセスの場合は、AuthenticationEntryPointインターフェースのメソッドを呼び出してエラー応答を行う

• AccessDeniedHandler

• AuthenticationEntryPoint

• 認可エラー時の遷移先

1
    http.exceptionHandling().accessDeniedPage("/accessDeniedError");

• デフォルト動作のカスタマイズ
  • TODO: 認証エラー時にメッセージを出す処理を作るときに記述しないと行けない気がする

9.6.1 Spring SecurityのCSRF対策#

• Spring Securityはセッション単位にランダムなトークン値(CSRFトークン)を払い出し、払い出されたCSRFトークンをリクエストパラメータ（HTMLフォームのhidden項目）として送信することで、そのリクエストが正規のWebページからなのか、それとも攻撃者が用意したWebページからなのかを判断する機能がある
• SpringSecurityのデフォルト実装では、POST,PUT,DELETE,PATCHのHTTPメソッドを使用したリクエストに対して、CSRFトークンチェックを行います

9.6.2 CSRF対策機能の適用#

• CSRF対策機能はSpring3.2から追加された機能で、SpringSecurity4.0からデフォルトで適用されるようになりました。
• そのため、CSRF対策機能を有効にするための特別な定義はありません。
• なおCSRF機能を適用したくない場合は、明示的に無効にする必要がある

1
  @Override
2
  public void configure(HttpSecurity http) throws Exception {
3
    http.csrf().disable();
4
  }

• HTMLフォーム使用時のトークン値の連携

  • JSPでの設定を紹介しているため割愛
  • Thymeleafだとこんな感じhttps://qiita.com/nenokido2000/items/22a97a26a5858ddb164f

• Ajax使用時の連携

  • Ajaxを使ってリクエストを送信する場合は、SpringSecurityから提供されている<sec:csrfMetaTag>要素を使用して、HTMLの<meta>要素としてCSRFトークンの情報を出力し<meta>要素から取得したトークン値をAjax通信時のリクエストヘッダーに設定して連携します。
  • Thymeleafの場合、以下を参考に、Cookieからcsrfトークンを取り出して、詰めて送る
    • https://qiita.com/nenokido2000/items/22a97a26a5858ddb164f
    • CookieにCSRFトークンを詰める処理は以下で行えるようになっている
    • http.csrf().csrfTokenRepository(new CookieCsrfTokenRepository());

9.6.3 トークンチェックエラー時のレスポンス#

• CSRFトークンチェックでエラーが発生した場合、SpringSecurityはAccessDeniedHandlerインターフェースを使用してエラーのレスポンスを行う

• CSRFトークンチェックでエラーが発生したときに専用のエラーページに遷移させる場合は、SpringSecurityから提供されているDelegatingAuthenticationFailureHandlerクラスを利用して、それぞれの例外にAccessDeniedHandlerインターフェースの実装クラスを指定してください

• CSRFトークンチェックで使用される例外クラス

  • InvalidCsrfTokenException
  • MissingCsrfTokenException
    • TODO: この例外処理を実装する必要がある XMLで記載している例はあるけど、Javaで書いている例がない..

9.6.4 CSRF対策機能とSpringMVCとの連携#

• 自動でFormにcsrfトークンが入りますよという説明

9.7.1 セッション管理機能の適用#

• セッション管理機能を使用するには、以下のようなBean定義を行う

1
  @Override
2
  public void configure(HttpSecurity http) throws Exception {
3
    http.sessionManagement();
4
  }

• sessionManagementメソッドを呼び出し、SessionManagementConfigurerのインスタンスを取得する

• SessionManagementConfigurerには、セッション管理機能のコンポーネントの動作をカスタマイズするためのメソッドが定義されている。なお、WebSecurityConfigurerAdapterを継承して、コンフィギュレーションクラスを作成している場合は、sessionManagementメソッドは親クラスの処理で呼び出されるため、デフォルトでセッション管理機能が適用されている

• RESTAPIなどセッションを使用しない場合は、セッションの作成方式を stateless に変更する必要がある

1
http.sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)

• セッションの作成方式は以下のオプションから選択することができる
  • always
  • ifRequired (デフォルト)
  • never
  • stateless

9.7.2 URL Rewriting抑止機能#

URL Rewritingが行われると、URL内にセッションIDが露出してしまうため、セッションIDを盗まれるリスクが高くなります。

SpringSecurityでは、URL Rewritingを抑止するための仕組みも提供しており、この機能はSpringSecurity4.0以上ではデフォルトで適用されます。

• TODO: Cookieを許可しない設定になっているとどのような挙動になる？クエリに埋め込まれない？

9.7.3 セッション固定攻撃対策機能#

• セッション管理機能を適用すると、デフォルトでセッション固定攻撃機能が有効になる

• セッション固定攻撃対策機能を使用すると、ログイン成功時に新たセッションIDを払い直すため、攻撃者が事前に払い出したセッションIDが使われることはありません。

• セッション固定攻撃への対策オプション

  • changeSessionId: Servlet3.1で追加されたHttpServletRequest#changeSessionIdメソッドを使用してセッションIDを変更する（Servlet3.1以上のコンテナでのデフォルト動作）
  • migrateSession: ログイン前に使用していたセッションを破棄し、新たにセッションを作成する。ログイン前にセッションに格納されていたオブジェクトは新しいセッションに引き継がれる
  • newSession: migrateSessionと同じ方法でセッションIDを変更するが、ログイン前に格納されていたオブジェクトは新しいセッションには引き継がれない
  • none: SpringSecurityはセッションIDを変更しない

• 指定方法

1
http.sessionManagement().sessionFixation().newSession();

9.7.4 多重ログインの制御#

• SpringSecurityは同じユーザー名（ログインID）を使った多重ログインを制御する機能を提供しているが、

• SpringSecurityが提供しているデフォルト実装にはいくつかの制約や注意事項がある

• 本書では、これらの制約と注意事項について紹介するが、具体的な使い方は扱わない、リファレンス参照

• SpringSecurityが提供しているデフォルト実装では、ユーザー毎にセッション情報をアプリケーションサーバーのメモリ内で管理します。

• そのため、複数のアプリケーションサーバーを同時に実行するシステムでは利用することができません。

• また、アプリケーションサーバーを停止または再起動するとメモリ内で管理していたセッション情報はクリアされます。

• 使用するアプリケーションサーバーによっては、停止または再起動時のセッション状態を復元する機能を持っているため、実際のセッション状態とSpringSecurityが管理しているセッション情報に不整合が生じる可能性がある

• TODO: Redisで管理する方法探る

9.7.5 無効なセッションを使ったリクエストの検知#

• SpringSecurityは無効なセッションを使ったリクエストを検知する機能を提供している
• 無効なセッションとして扱われるリクエストの大部分は、セッションタイムアウト後のリクエストです。
• 以下の例では、無効なセッションを検知した際の遷移先として "/error/invalidSession"を指定することで、この機能を有効化している

1
http.sessionManagement().invalidSessionUrl("/error/invalidSession");

9.8.1 セキュリティヘッダー出力機能の適用#

• Spring3.2から追加された機能で、Spring4.0からデフォルトで適用されるようになった

1
// 無効にする方法
2
    http.headers().disable();

9.8.2 デフォルトでサポートしているセキュリティヘッダー#

• SpringSecurityがデフォルトでサポートしているレスポンスヘッダーは以下の５つ

  • Cache-Control（Pragma, Expires）
    • コンテンツのキャッシュ方法を支持するヘッダー
    • 保護されたコンテンツがブラウザにキャッシュされないようにすることで、権限のないユーザーが保護されたコンテンツを閲覧できてしまうリスクを減らすことができる
  • X-Frame-Options
    • フレーム（<frame>または<iframe>要素）内でコンテンツの表示を許可するか否かを支持するためのヘッダー
    • フレーム内でコンテンツが表示されないようにすることで、クリックジャッキングと呼ばれる攻撃手法を使って機密情報を盗み取られるリスクを無くすことができる
  • X-Content-Type-Options
    • コンテンツの種類の決定方法を指示するためのヘッダー
    • 一部のブラウザでは、Content-Typeヘッダーの値を無視して、コンテンツの内容を見て決定します。
    • コンテンツの種類を決定する際にコンテンツの内容を見ないようにすることで、クロスサイトスクリプティングを使った攻撃を受ける可能性をへらすことができます。
  • X-XSS-Protection
    • ブラウザのXSSフィルタ機能を使って有害なスクリプトを検知する方法を支持するためのヘッダー
    • XSSフィルタ機能を有効にして有害なスクリプトを検知するようにすれば、クロスサイトスクリプティングを使った攻撃を受ける可能性をへらすことができる。
  • Strict-Transport-Security
    • HTTPSを使ったアクセスをしたあとに、HTTPを使ってアクセスしようとした際に、HTTPSに置き換えてからアクセスすることを支持するためのヘッダー
    • HTTPSでアクセスした後に、HTTPが使われないようにすることで、中間者攻撃と呼ばれる攻撃手法を使って悪意のあるサイトに誘導されるリスクをへらすことができる

• TODO: 攻撃手法と対策について再度整理する必要あり

9.8.3 セキュリティヘッダーの選択#

• 出力するセキュリティヘッダーを選択したい場合は、以下のようなBean定義を行います。
• ここではSpringSecurityが提供するすべてのセキュリティヘッダーを出力する例になっていますが、実際は必要なものだけ指定する

1
    http.headers()
2
        .defaultsDisabled()
3
        .cacheControl().and()
4
        .frameOptions().and()
5
        .contentTypeOptions().and()
6
        .xssProtection().and()
7
        .httpStrictTransportSecurity();

• 不要なものだけ無効化する方法もある

9.9.1 Spring Security Testのセットアップ#

• 依存ライブラリーの追加

1
  testImplementation 'org.springframework.security:spring-security-test'

• SpringSecurityのサーブレットフィルタの追加

• TODO: テスト環境が作れて無いため一旦スキップする

10.6.4 ページネーション#

• TODO: DOMAにあるかどうか

10.6.6 監査情報の付与#

• TODO: DOMAにあるかどうか

12.1.1 Thymeleafのテンプレート#

ThymeleafはXHTMLやHTML5などで書かれたテンプレートをDOMに変換してから処理を行う仕組みになっている 「処理対象のDOMノード」と「DOMノードに適用する処理」をthネームスペースの属性（th属性）を使用して指定します。

th属性が指定されているDOMノードは「プロセッサ」と呼ばれるコンポーネントによってDOM操作（追加、削除、変更）が行われる。th属性の属性値には、OGNL（Object-Graph Navigation Language）と呼ばれる式言語を指定でき、式の中から、ユーザー定義のオブジェクトやThymeleafが提供する暗黙オブジェクトにアクセスすることができる

• 以下３つのことをDialectと呼ぶ

  • DOM操作を行うプロセッサ
  • th属性の属性値に指定された式を解釈するコンポーネント
  • 暗黙オブジェクトを生成するコンポーネント
    • →デフォルトでは、StandardDialectクラスが使用される

• Dialectは拡張可能な仕組みになっており、本書で紹介するthymeleaf-spring4を使う場合は、StandardDiarectクラスを継承した、SpringStandardDialectクラスが使用される

12.1.2 ThymeleafとSpringの連携#

• 連携する場合、Thymeleafが提供するthymeleaf-spring4モジュールを利用

• SpringMVCがJSP向けに提供しているタグライブラリと同様の機能を、Thymeleafで利用することができる

• 実現できる機能

  • Thymeleafが管理するテンプレートをSpringMVCのViewとして扱うことができる
  • テンプレート内でSpringELを利用することができる
  • テンプレートと、フォームクラスおよび入力値チェック結果のバインドが可能となる
  • Springが管理するメッセージリソースを利用し、国際化対応のメッセージを表示することができる

12.2.1 ライブラリのセットアップ#

• thymeleaf-spring4を入れる

12.2.2 SpringとThymeleafを連携するための設定#

• SringBootだと書かなくても動くっぽいけど明示する意味で

1
@Configuration
2
@Import(ThymeleafConfig.class) // Thymeleafを使用することを明示
3
public class AppConfig implements WebMvcConfigurer {
4
}
5

6
@Configuration
7
public class ThymeleafConfig {
8

9
  @Bean
10
  public ClassLoaderTemplateResolver templateResolver() {
11
    ClassLoaderTemplateResolver resolver = new ClassLoaderTemplateResolver();
12
    resolver.setPrefix("/WEB-INF/templates/");
13
    resolver.setSuffix(".html");
14
    resolver.setTemplateMode("HTML5");
15
    resolver.setCharacterEncoding("UTF-8");
16
    return resolver;
17
  }
18

19
  @Bean
20
  public SpringTemplateEngine templateEngine() {
21
    SpringTemplateEngine templateEngine = new SpringTemplateEngine();
22
    templateEngine.setTemplateResolver(templateResolver());
23
    return templateEngine;
24
  }
25

26
  @Bean
27
  public ViewResolver viewResolver() {
28
    ThymeleafViewResolver viewResolver = new ThymeleafViewResolver();
29
    viewResolver.setTemplateEngine(templateEngine());
30
    viewResolver.setCharacterEncoding("UTF-8");
31
    return viewResolver;
32
  }
33

34
}