.. only:: html

 .. contents:: 目次
    :depth: 2
    :local:

5.4.2での主な変更点は以下の通りです。

• Spring Frameworkを4.3.23へ更新
• Spring Securityを4.2.12へ更新
• Spring IO PlatformをBrussels-SR17へ更新
• MyBatisを3.4.6へ更新
• 共通ライブラリの仕様を一部変更
• ブランクプロジェクトの変更

5.4.2から、Spring IO PlatformをBrussels-SR17へ更新しました。

Note

Spring IO Platform Brussels-SR17では、Tomcatに関連するライブラリはバージョン8.5.39が使用されますが、共通ライブラリではTomcat8.5.39で発生したバグを回避するため独自にバージョン管理を行いバージョン8.5.40を使用します。

5.4.2から、Spring Framework 4.3.23.RELEASEへ更新しました。

5.4.2から、Spring Security 4.2.12.RELEASEへ更新しました。

5.4.2から、MyBatis 3.4.6へ更新しました。この更新にあわせて、MyBatis Springを1.3.2へ更新しました。

5.4.2から、共通ライブラリの一部仕様の変更と機能の追加を行いました。

• [#11] SimpleI18nCodeList is not reloadble
• [#736] Fix inappropriate dependency on terasoluna-gfw-jodatime
• [#761] Suggest to add constraint annotation that validate a byte size range
• [#877] @ExistInCodeList support Number for NumberRangeCodeList
• [#896] Update SpringIOPlatform to Brusseles-SR17
• [#904] Apply MyBatis 3.4.6 and MyBatis-Spring 1.3.2
• [#907] Upgrade to Tomcat 8.5.40

5.4.2から、バグ修正に伴い共通ライブラリの一部仕様を変更しました。

• [#809] JdbcCodeList improperly updates the code list map already registered in request

5.4.2から、ブランクプロジェクトの一部設定ファイルを変更しました。

• [single#312] [multi#348] Improve mvc:exclude-mapping Definition of interceptors in spring-mvc.xml for security
• [single#396] [multi#445] Update JDBC driver

移行手順は、以下の通りです。

Note

凡例

Required : 手順の適用は必須

Required by case : 手順の適用は条件付きで必須

Optional : 手順の適用を推奨 (必要に応じて手順の適用を実施)

- : 手順の適用は必要なし

[全般]

.. tabularcolumns:: |p{0.10\linewidth}|p{0.30\linewidth}|p{0.20\linewidth}|p{0.20\linewidth}|p{0.20\linewidth}|

[共通ライブラリ]

.. tabularcolumns:: |p{0.10\linewidth}|p{0.30\linewidth}|p{0.20\linewidth}|p{0.20\linewidth}|p{0.20\linewidth}|

[Blank project]

.. tabularcolumns:: |p{0.10\linewidth}|p{0.30\linewidth}|p{0.20\linewidth}|p{0.20\linewidth}|p{0.20\linewidth}|

[Spring Framework]

.. tabularcolumns:: |p{0.10\linewidth}|p{0.30\linewidth}|p{0.20\linewidth}|p{0.20\linewidth}|p{0.20\linewidth}|

[Spring Security]

.. tabularcolumns:: |p{0.10\linewidth}|p{0.30\linewidth}|p{0.20\linewidth}|p{0.20\linewidth}|p{0.20\linewidth}|

[Hibernate ORM]

.. tabularcolumns:: |p{0.10\linewidth}|p{0.30\linewidth}|p{0.20\linewidth}|p{0.20\linewidth}|p{0.20\linewidth}|

[Dozer]

.. tabularcolumns:: |p{0.10\linewidth}|p{0.30\linewidth}|p{0.20\linewidth}|p{0.20\linewidth}|p{0.20\linewidth}|

[Lombok]

.. tabularcolumns:: |p{0.10\linewidth}|p{0.30\linewidth}|p{0.20\linewidth}|p{0.20\linewidth}|p{0.20\linewidth}|

TERASOLUNA Server Framework for Java (5.x)の共通ライブラリと依存ライブラリを更新してください。 以下に、この手順により更新される代表的な依存ライブラリを示します。

.. tabularcolumns:: |p{0.35\linewidth}|p{0.25\linewidth}|p{0.25\linewidth}|p{0.15\linewidth}|

[手順が必要なケース]

この手順の適用は必須です。

この更新手順は、mvn archetype を使用して作成したプロジェクト向けです。

親プロジェクトのpomファイルの version を 5.4.2.RELEASE に修正してください。

• ($YOUR_MULTIPLE_PROJECT_ROOT/pom.xml)

<!-- omitted -->
<parent>
    <groupId>org.terasoluna.gfw</groupId>
    <artifactId>terasoluna-gfw-parent</artifactId>
    <version>5.4.2.RELEASE</version>                    <!-- ### 修正箇所 ### -->
</parent>
<!-- omitted -->

この更新手順は、mvn archetype を使用して作成したプロジェクト、又は release site からダウンロードしたプロジェクト向けです。

プロジェクトのpomファイルの version を 5.4.2.RELEASE にしてください。

• ($YOUR_SINGLE_PROJECT/pom.xml)

<!-- omitted -->
<parent>
    <groupId>org.terasoluna.gfw</groupId>
    <artifactId>terasoluna-gfw-parent</artifactId>
    <version>5.4.2.RELEASE</version>                    <!-- ### 修正箇所 ### -->
</parent>
<!-- omitted -->

この更新手順は、release site からダウンロードしたEclipse WTPプロジェクト向けです。

更新手順は、Eclipse WTP Project使用時のライブラリ更新 を参照してください。

ReloadableCodeList （ JdbcCodeList 等）の asMap メソッドにより Map として取得されるコードリストがイミュータブルに変更されました。

従来の ReloadableCodeList では、コードリストを取得した後に refresh メソッドでコードリストがリロードされると、 既に asMap メソッドで取得された Map の中身も更新される（イミュータブルでない）という問題がありました。 このため例えば、Controllerで Map キーの存在チェックを行った後、実際にキーを指定して値を取得しようとすると null が得られるようなケースが発生し得ました。

この変更に伴い、 CodeListInterceptor がリクエストスコープにコードリストを登録するタイミングが、Controllerの処理実行前（ preHandle メソッド）から処理実行後（ postHandle メソッド）に変更されました。 なお、 postHandle メソッドはControllerの処理で例外がスローされた場合は実行されない点にご注意ください。（Controllerの処理でTry-Catchされた場合は除きます。）

今回の改善により、従来の実装では期待通りにコードリストを取得できなくなる場合があります。

[手順が必要なケース１]

CodeListInterceptor がリクエストスコープに登録したコードリストをControllerで取得している場合。

[修正方法]

Controllerの処理実行時はリクエストスコープからコードリストを取得することができなくなります。 ControllerにコードリストBeanをインジェクションし、 asMap メソッドによりコードリストを取得してください。

【修正前】※コード例は一例です。

@RequestMapping
public String handle(HttpServletRequest request) {

    Map<String, String> codeListMap = request.getAttribute("CL_SAMPLE");

    // ommited logics
}

【修正後】

@Inject
@Named("CL_SAMPLE")
CodeList codeList;

@RequestMapping
public String handle() {

    Map<String, String> codeListMap = codeList.asMap();

    // ommited logics
}

[手順が必要なケース２]

Controllerの処理で例外がスローされた場合に遷移する画面でコードリストを利用している場合。（Controllerの処理でTry-Catchされた場合は除きます。）

[修正方法]

Controllerの処理で例外がスローされた場合はリクエストスコープからコードリストを取得することができなくなります。 JSPでコードリストBeanを参照し、 asMap メソッドによりコードリストを取得してください。

【修正前】

<form:select items="${statuses}" path="orderStatus" />

【修正後】

<spring:eval var="statuses" expression="@CL_ORDERSTATUS.asMap()"/>
<form:select items="${statuses}" path="orderStatus" />

TraceLoggingInterceptorでwarnHandlingNanosを設定する実装例が修正されました。

以前の実装例ではTraceLoggingInterceptorのwarnHandlingNanosプロパティに数式#{10 * 1000 * 1000 * 1000}を指定し、Controllerの処理時間が10000000000ナノ秒（10秒）を超えるとWARNログが出力することを期待していました。 実際には10000000000はintの最大値2147483647を超えるためオーバーフローによって1410065412が指定され、Controllerの処理時間が1410065412ナノ秒（約1.4秒）を超えるとWARNログが出力されてしまう形となります。

[手順が必要なケース]

以下のケースと一致する場合は、次の修正を行ってください。

• TraceLoggingInterceptorのwarnHandlingNanosプロパティに、int型の数式かint型の数式を値として持つプロパティを指定している場合。

[修正方法]

warnHandlingNanosの設定を以下のいずれかのように変更してください。

【修正前】

<mvc:interceptors>
    <!-- omitted -->
    <mvc:interceptor>
        <mvc:mapping path="/**" />
        <mvc:exclude-mapping path="/resources/**" />
        <bean
            class="org.terasoluna.gfw.web.logging.TraceLoggingInterceptor">
            <property name="warnHandlingNanos" value="#{10 * 1000 * 1000 * 1000}" />
        </bean>
    </mvc:interceptor>
    <!-- omitted -->
</mvc:interceptors>

【修正後】

• long型の数式を指定する

<mvc:interceptors>
    <!-- omitted -->
    <mvc:interceptor>
        <mvc:mapping path="/**" />
        <mvc:exclude-mapping path="/resources/**" />
        <bean
            class="org.terasoluna.gfw.web.logging.TraceLoggingInterceptor">
            <property name="warnHandlingNanos" value="#{10L * 1000L * 1000L * 1000L}" />
        </bean>
    </mvc:interceptor>
    <!-- omitted -->
</mvc:interceptors>

• 固定値で指定する

<mvc:interceptors>
    <!-- omitted -->
    <mvc:interceptor>
        <mvc:mapping path="/**" />
        <mvc:exclude-mapping path="/resources/**" />
        <bean
            class="org.terasoluna.gfw.web.logging.TraceLoggingInterceptor">
            <property name="warnHandlingNanos" value="10000000000" />
        </bean>
    </mvc:interceptor>
    <!-- omitted -->
</mvc:interceptors>

5.4.1の共通ライブラリでは、バグにより不要なcommons-loggingへの依存関係を持っていました。

このバグは、Spring IO PlatformからSpring FrameworkおよびSpring Securityを独自にバージョンアップしていたことが原因で発生していましたが、 5.4.2では、独自のバージョンアップを行わないため発生しなくなりました。

[手順が必要なケース]

この手順は任意ですが、以下のケースに一致する場合は、次の修正を適用することを推奨します。

• commons-loggingの除外設定を行っている。

[修正方法]

以下の実装例を参考に、不要となったcommons-loggingの除外設定を削除してください。

• pom.xmlの定義例

<dependencyManagement>
  <dependencies>
    <!-- ### 削除箇所 開始 ### -->
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-core</artifactId>
      <exclusions>
        <exclusion>
          <groupId>commons-logging</groupId>
          <artifactId>commons-logging</artifactId>
        </exclusion>
      </exclusions>
    </dependency>
    <!-- ### 削除箇所 終了 ### -->

    <!-- omitted -->

  </dependencies>
</dependencyManagement>

[備考]

commons-loggingの除外設定を行っておらず、当該APIを誤って使用していた場合は、バージョンアップによりコンパイルエラーとなります。 この場合、commons-loggingからSLF4JのAPIに置き換えることをご検討ください。

terasoluna-gfw-common に新規コードリスト SimpleReloadableI18nCodeList を追加いたしました。

SimpleReloadableI18nCodeList は国際化に対応した SimpleI18nCodeList をリロード可能としたものになります。 JdbcCodeList を内包する SimpleI18nCodeList を利用している場合は SimpleReloadableI18nCodeList に変更することで、 アプリケーションを再起動することなくコードリストのリロードが可能となります。

[手順が必要なケース]

この手順の適用は任意です。JdbcCodeList を内包する SimpleI18nCodeList を利用している場合は、必要に応じて次の修正を行ってください。

[修正方法]

Bean定義ファイルのクラス名 SimpleI18nCodeList を SimpleReloadableI18nCodeList に変更します。

【修正前】

<bean id="CL_I18N_PRICE"
    class="org.terasoluna.gfw.common.codelist.i18n.SimpleI18nCodeList">
    <property name="rowsByCodeList">
        <util:map>
            <entry key="en" value-ref="(en用JdbcCodeListのID)" />
            <entry key="ja" value-ref="(ja用JdbcCodeListのID)" />
        </util:map>
    </property>
</bean>

【修正後】

<bean id="CL_I18N_PRICE"
    class="org.terasoluna.gfw.common.codelist.i18n.SimpleReloadableI18nCodeList">
    <property name="rowsByCodeList">
        <util:map>
            <entry key="en" value-ref="(en用JdbcCodeListのID)" />
            <entry key="ja" value-ref="(ja用JdbcCodeListのID)" />
        </util:map>
    </property>
</bean>

コードリストの更新方法については、開発ガイドラインのコードリストをリロードする場合を参照してください。

入力された値がコードリストに定義されていることを検証する @ExistInCodeList で、Number 型（ Integer 型や Long 型など）のフィールドを検証できるよう改善されました。

従来の @ExistInCodeList では検証可能な型が Character 型および CharSequence 型のみであったため、 数値の入力を受け付けるFormオブジェクトのフィールドであっても String 型とせざるを得ない場合がありましたが、 今回の改善により適切な型のフィールドを定義することが可能となります。

[手順が必要なケース]

この手順の適用は任意です。以下のケースに当てはまる場合、必要に応じて修正を行ってください。

• 従来の @ExistInCodeList で検証するために、数値の入力を受け付けるFormオブジェクトのフィールドを String 型等にしている場合。

[修正方法]

Formオブジェクトの String 型フィールドを適切な型に変更し、必要に応じて String 型から適切な型への変換ロジックを削除します。

【修正前】

• Formオブジェクト

public class SampleForm {

    @ExistInCodeList(codeListId = "CL_MONTH")
    private String month;

    // ommited getter and setter
}

• Controller

@RequestMapping
public String handle(@Valid SampleForm form, BindingResult result) {

    Integer month = Integer.valueOf(form.getMonth());

    // ommited logics
}

【修正後】

• Formオブジェクト

public class SampleForm {

    @ExistInCodeList(codeListId = "CL_MONTH")
    private Integer month;

    // ommited getter and setter
}

• Controller

@RequestMapping
public String handle(@Valid SampleForm form, BindingResult result) {

    Integer month = form.getMonth();

    // ommited logics
}

開発ガイドラインのコードリストを独自カスタマイズする方法の実装例が修正されました。

以前の実装例では @Component を用いてコードリストをコンポーネント登録していましたが、コードリストのBean定義を xxx-codelist.xml に集約するため、定義方法が修正されました。

[手順が必要なケース]

この手順の適用は任意です。独自カスタマイズしたコードリストを実装している場合は、必要に応じて次の修正を行ってください。

[修正方法]

独自カスタマイズしたコードリストから @Component を削除し、xxx-codelist.xml でBean定義を行うように変更してください。 また、 @Inject を利用してインジェクションを行っている場合は、フィールドの Setter を定義し、Bean定義の property タグを利用するように変更してください。

【修正前】

• 独自カスタマイズしたコードリストの実装例

@Component("CL_YEAR")
public class DepYearCodeList extends AbstractCodeList {

    @Inject
    JodaTimeDateFactory dateFactory;

    // omitted

}

【修正後】

• 独自カスタマイズしたコードリストの実装例

public class DepYearCodeList extends AbstractCodeList {

    private JodaTimeDateFactory dateFactory;

    public void setDateFactory(JodaTimeDateFactory dateFactory) {
        this.dateFactory = dateFactory;
    }

    // omitted

}

• xxx-codelist.xml の定義例

<bean id="CL_YEAR" class="com.example.sample.domain.codelist.DepYearCodeList">
    <property name="dateFactory" ref="dateFactory" />
</bean>

terasoluna-gfw-validator に新規制約アノテーション @ByteSize を追加いたしました。

@ByteMin と @ByteMax を併用してバイト長の範囲チェックを行っている場合は、@ByteSize を利用することでパフォーマンスの向上が期待できます。

[手順が必要なケース]

この手順の適用は任意ですが、次のケースに当てはまる場合は、修正を行うことを推奨します。

• @ByteMin と @ByteMax を併用してバイト長の範囲チェックを行っている場合。

[修正方法]

@ByteMin と @ByteMax を @ByteSize に変更します。

【修正前】

public class SampleForm {

    @ByteMin(10)
    @ByteMax(20)
    private String target;

    // ommited getter and setter
}

【修正後】

public class SampleForm {

    @ByteSize(min = 10, max = 20)
    private String target;

    // ommited getter and setter
}

なお、この変更に併せて、@ByteMin と @ByteMax で value 属性（最小/最大バイト数）に不正な値を設定した場合には 実行時に IllegalArgumentException がスローされるよう変更されました。

この場合、元々作りこまれていたプログラムバグが顕在化した形になりますので、必ず設定値の見直しを行ってください。

ブランクプロジェクトの<mvc:interceptor>の定義から、.htmlで終わるパスを対象外とする設定が削除されました。

これはWebアプリ内の静的リソースであるHTMLファイルに対してインターセプターを適用しないための設定でしたが、静的リソースには機能していないことが判明したためです。

この変更により、リクエストパスに.htmlを付与した場合も正常にインターセプターが適用されるようになりました。

[手順が必要なケース]

この手順の適用は必須です。

[修正方法]

spring-mvc.xmlに定義されている全ての<mvc:interceptor>から、<mvc:exclude-mapping path="/**/*.html" />を削除してください。

• spring-mvc.xmlの定義例

    <!-- omitted -->

    <mvc:interceptor>
        <mvc:mapping path="/**" />
        <mvc:exclude-mapping path="/resources/**" />
        <mvc:exclude-mapping path="/**/*.html" /> <!-- ### 削除箇所 ### -->
        <!-- omitted -->
    </mvc:interceptor>

    <!-- omitted -->

</mvc:interceptors>

開発ガイドラインのJMSの実装例にて、Bean定義を記載するファイルの整理が行われました。

[手順が必要なケース]

この手順の適用は任意ですが、以下のケースに当てはまる場合は、次の修正を行うことを推奨します。

• JMSについて、開発ガイドラインに準拠した実装を行っている。

[修正方法]

各定義を記載するBean定義ファイルが以下のように変更されました。

.. tabularcolumns:: |p{0.30\linewidth}|p{0.30\linewidth}

また、 ConnectionFactory をアプリケーションサーバで定義を行う場合についても、定義箇所は上記表のとおり [projectName]-infra.xml から [projectName]-env.xml に変更が行われました。

[備考]

開発環境と本番環境で異なるMQ製品を使用し、Bean定義の設定が環境ごとに異なる場合は、開発ガイドライン通りに定義を行えない場合があります。 jms:listener-container等の一部のBean定義は、プロパティプレースホルダで設定を置き換えすることができないため、 [projectName]-env.xml に定義を行いMavenのプロファイルを用いて設定を切り替える必要があります。

ブランクプロジェクトのpomファイルで、 PostgreSQL JDBC Driver のバージョン定義を更新しました。

PostgreSQLのJDBCドライバーは上位互換性が保障されているため、最新バージョンを使用することを推奨します。

[手順が必要なケース]

この手順の適用は任意ですが、次のケースに当てはまる場合は、修正を行うことを推奨します。

• PostgreSQL 8.2以降のバージョンを使用している。

[修正方法]

pomファイルのプロパティを修正してください。

• pom.xml

<properties>
    <!-- omitted -->
    <postgresql.version>42.2.5.jre7</postgresql.version> <!-- ### 修正箇所 ### -->
    <!-- omitted -->
</properties>

postgresql.versionプロパティに指定する値は、動作環境のJavaバージョンにより異なります。

• Java SE 8：42.2.5
• Java SE 7：42.2.5.jre7

5.4.1の開発ガイドラインの カスタムViewの実装 には、 iTextを利用するために、pom.xmlに定義していた依存関係の設定例に、iTextが依存するいくつかのライブラリを除外する設定がありました。

この設定は、TERASOLUNA Global Frameworkが利用するitext 4.2.1では正しい設定でしたが、 TERASOLUNA Server Framework for Java 5.4.xまでで利用するitext 2.1.7では誤った設定であったため、5.4.2で修正されました。

5.4.1までの誤った設定では、不要なライブラリorg.bouncycastle:bcprov-jdk14:1.38がアプリケーションに含まれていました。

[手順が必要なケース]

iTextを利用し、開発ガイドラインの記載例の通りにpom.xmlに依存関係の設定を行っている場合

[修正方法]

pom.xmlを以下のように修正してください。

【修正前】

<dependencies>
    <!-- omitted -->
    <dependency>
        <groupId>com.lowagie</groupId>
        <artifactId>itext</artifactId>
        <exclusions>
            <exclusion>
                <artifactId>xml-apis</artifactId>
                <groupId>xml-apis</groupId>
            </exclusion>
            <exclusion>
                <artifactId>bctsp-jdk14</artifactId>
                <groupId>org.bouncycastle</groupId>
            </exclusion>
            <exclusion>
                <artifactId>jfreechart</artifactId>
                <groupId>jfree</groupId>
            </exclusion>
            <exclusion>
                <artifactId>dom4j</artifactId>
                <groupId>dom4j</groupId>
            </exclusion>
            <exclusion>
                <groupId>org.swinglabs</groupId>
                <artifactId>pdf-renderer</artifactId>
            </exclusion>
            <exclusion>
                  <groupId>org.bouncycastle</groupId>
                  <artifactId>bcprov-jdk14</artifactId>
              </exclusion>
          </exclusions>
      </dependency>
      <dependency>
          <groupId>org.bouncycastle</groupId>
          <artifactId>bcprov-jdk14</artifactId>
          <version>1.38</version>
      </dependency>
</dependencies>

【修正後】

<dependencies>
    <!-- omitted -->
    <dependency>
        <groupId>com.lowagie</groupId>
        <artifactId>itext</artifactId>
    </dependency>
</dependencies>

開発ガイドラインのMybatis3を使用したEntityの検索処理に、ページネーション検索の結果をソートする 実装例が追加されました。

この実装例では Pageable オブジェクトの sort プロパティを利用して、SQLで検索結果のソートを行います。

[手順が必要なケース]

この手順の適用は任意ですが、以下のケースに当てはまる場合は、次の修正を行うことを推奨します。

• Mybatis3を使用したページネーション検索で、SQLでのソートを独自に実装している。

[修正方法]

開発ガイドラインの実装例を確認し、実装を修正してください。

MyBatis3で Pageable オブジェクトを利用した検索結果のソートを行う場合、ソート条件は置換変数を使用して埋め込む必要があるため、SQL Injectionが発生する可能性があります。 独自の実装を行っている場合は特に、SQL Injectionを考慮し適切に対策が行われているかの確認を行ってください。

詳細はSQL Injection対策を参照してください。

Spring Security OAuth 2.0.17 より、リダイレクトURIのホワイトリストチェックの仕様が変更されました。

クライアントが認可リクエスト時に申告するリダイレクトURIについて、2.0.16以前では認可サーバに登録されたリダイレクトURIのパス配下であることを確認していましたが、2.0.17ではパスと完全一致することを確認するようになりました。 そのため、認可サーバにはリダイレクトするすべてのパスを登録する必要があります。

[手順が必要なケース]

リダイレクトURIのホワイトリストに登録されているパスがリダイレクトするパスと完全一致していない場合。

[修正方法]

リダイレクトURIのホワイトリストに、リダイレクトするすべてのパスを登録するように修正してください。

開発ガイドラインの クライアントの認証 に準拠した実装の場合は、認証パラメータを管理するDBのテーブルにリダイレクトURIのレコードを追加してください。

Spring Securityのセキュリティヘッダを書き込むHeaderWriterFilterにおいて、 Spring Security 4.2.4では、フィルタ実行時（リクエスト受付時）にセキュリティヘッダの書き込みを行っていましたが、 Spring Security 4.2.5以降ではレスポンスのコミット時にセキュリティヘッダの書き込みを行うよう変更されました。 これにより、Controller等の処理より後にセキュリティヘッダが書き込まれるようになりました。

この変更により、「Spring Securityによって必ずCache-Controlヘッダが書き込まれることにより、Controller等で書き込んだ同ヘッダが有効にならない事象」が解決されました。

ただし、この変更は不完全であり、Cache-Controlヘッダとそれ以外のセキュリティヘッダにより動作が異なります。

• Cache-Controlヘッダ

  レスポンスのコミット時にCache-Controlヘッダがない場合、Spring SecurityによってCache-Controlヘッダが書き込まれます。

  Controller等で同ヘッダが書き込まれた場合は、Spring Securityによる書き込みは行われません。

• Cache-Controlヘッダ以外

  レスポンスのコミット時にSpring Securityによって必ず該当のセキュリティヘッダが書き込まれます。

  Controller等で同ヘッダが書き込まれた場合は、従来と同様に重複するがその順序が異なります。

詳細は、開発ガイドラインの セキュリティヘッダの選択の Warning「個別に付与したセキュリティヘッダがSpring Securityにより上書き（追加）される問題」をご参照ください。

また、この変更はDelegatingRequestMatcherHeaderWriterの動作に大きく影響します。

具体的には、DelegatingRequestMatcherHeaderWriterが委譲するRequestMatcherによるリクエストパスの判定は、セキュリティヘッダの書き込み時に行われます。 このタイミングが変更されたことにより、リクエストがフォワードやインクルードされた場合、リクエストパスが変更され意図した通りにリクエストパスの判定が行われなくなりました。

以下に、それぞれの詳細と修正方法を解説します。

以下の２点の影響があります。

• ユースケースごとに異なるキャッシュ制御が可能になった

  Controller等でCache-Controlヘッダが書き込まれた場合は、Spring Securityによる書き込みが行われなくなりました。

  これにより、ユースケースごとに異なるキャッシュ制御が可能になりました。

• SystemExceptionResolverのpreventResponseCachingプロパティと併用した場合の挙動が変更された

  SystemExceptionResolverのpreventResponseCachingプロパティとSpring SecurityのCache-Controlヘッダを併用した場合、SystemExceptionResolverが有効になるようになりました。

  これにより、例外時のみ異なるキャッシュ制御が行われるようになります。

このうち、後者のSystemExceptionResolverについては移行上の問題となるケースがあるので、対策することを推奨します。

[手順が必要なケース]

以下の全てに当てはまる場合は対応が必要です。

• Spring SecurityのCache-Controlヘッダを有効にしている
• SystemExceptionResolverのpreventResponseCachingプロパティを有効（true）にしている

[修正方法]

• SystemExceptionResolverのpreventResponseCachingプロパティを無効（false）にします。 開発ガイドラインの HTTPレスポンスのキャッシュ制御有無をご参照ください。

Spring Securityが書き込むセキュリティヘッダと同ヘッダがControllerやViewで書き込まれた場合は、従来と同様に重複しますがその順序が異なります。 これにより、ブラウザで異なる解釈をされ挙動が変更される可能性があります。

また、このレスポンスを受け取るクライアントアプリケーションやテストコードでも、順序の変更に対応する必要がある場合があります。

[手順が必要なケース]

以下の全てに当てはまる場合は対応が必要です。

• Spring Securityのセキュリティヘッダを有効にしている
• 同ヘッダをControllerやViewで書き込んでいる

[修正方法]

クライアントアプリケーションやテストコードのうち、セキュリティヘッダを参照している箇所を見直します。

[備考]

通常、同一のヘッダを重複登録しないよう設計すべきですが、 重複登録されるヘッダの順序変更による影響を許容できない場合は、後述の「Spring Security 4.2.4の実装に戻す方法」による対応もご検討ください。

具体的には、DelegatingRequestMatcherHeaderWriterが委譲するRequestMatcherによるリクエストパスの判定は、セキュリティヘッダの書き込み時に行われます。 このタイミングが変更されたことにより、リクエストがフォワードやインクルードされた場合、リクエストパスが変更され意図した通りにリクエストパスの判定が行われなくなりました。

特にTilesを使用するアプリケーションでは、Tilesによりリクエストがフォワードされるため、DelegatingRequestMatcherHeaderWriterが正常に動作しなくなる場合があります。 詳細は、開発ガイドラインの リクエストパターン毎のセキュリティヘッダの出力の Warning「指定したパスが意図した通りに認識されない問題」をご参照ください。

[手順が必要なケース]

DelegatingRequestMatcherHeaderWriterを利用してリクエストのパターン毎にセキュリティヘッダの出力を制御しており、以下のいずれかに当てはまる場合は対応が必要です。

• Controllerでリクエストのフォワード（返却値にforward:を付与）を行っている
• JSPでリクエストのフォワード（jsp:forwardタグ等を利用）やインクルード（jsp:includeタグ等を利用）を行っている
• Tilesを使用し、Tilesによりリクエストがフォワードされている
• 上記以外に任意のフォワードやインクルードを行っている

上記のうち、Tilesは扱うJSPの容量により、フォワードされる場合とされない場合があることを確認しています。

[修正方法]

以下のいずれかの修正を行います。

• HeaderWriterFilterとDelegatingRequestMatcherHeaderWriterを独自に実装し、フィルタ実行時にリクエストパスを判定する。
• DelegatingRequestMatcherHeaderWriterが委譲するRequestMatcherを拡張し、フォワードやインクルード元のリクエストパスを判定する。

詳細は、 spring-security#6338を参照ください。

なお、上記の方法はTERASOLUNA Server Framework for Javaとして動作を保証するものではありません。 開発プロジェクトにおいて十分な動作検証を行ってください。

推奨いたしませんが、上記の変更および対策が許容されない場合、 移行前のバージョンに準拠したHeaderWriterFilterを独自に実装することで、移行前のバージョンの動作を再現することが可能です。

実装方法は、 5.3.2の開発ガイドラインのセキュリティヘッダの選択の Warning「アプリケーションサーバによってはCache-Controlヘッダが正しく設定されない問題」をご参照ください。

Spring Security 4.2.4のHeaderWriterFilterについては、 HeaderWriterFilter.javaを参照ください。

期待する動作となるかどうか、開発プロジェクトにおいて十分な動作検証を行ってください。

Spring Security 4.2.6 からランダムなソルトを使用するorg.springframework.security.crypto.password.MessageDigestPasswordEncoderが追加され、従来提供されていたorg.springframework.security.authentication.encoding.MessageDigestPasswordEncoderは非推奨となりました。

これに伴い、5.4.2版開発ガイドラインでは「非推奨パッケージのPasswordEncoderの利用」を「非推奨アルゴリズムのPasswordEncoderの利用」と改め、ShaPasswordEncoderの代わりにorg.springframework.security.crypto.password.MessageDigestPasswordEncoderを使用するよう変更しました。

固定のソルトを使用し続けることはセキュリティ上のリスクが伴うことから、org.springframework.security.crypto.password.PasswordEncoder実装クラスに移行することを推奨します。 使用するハッシュ化アルゴリズムに制約が存在しない場合は開発ガイドラインで紹介するBCryptPasswordEncoderに移行することを推奨します。 ハッシュ化アルゴリズムの制約が存在し、SHA-1やSHA-256、MD5等を使用しなくてはいけない場合はMessageDigestPasswordEncoderを使用してください。

[手順が必要なケース]

非推奨アルゴリズムのorg.springframework.security.authentication.encoding.PasswordEncoder（ShaPasswordEncoder等）を利用している場合。

[修正方法]

従来の非推奨アルゴリズムのPasswordEncoderの代わりに、MessageDigestPasswordEncoder（org.springframework.security.crypto.password.PasswordEncoderの実装クラス）を使用します。

org.springframework.security.crypto.password.PasswordEncoderの実装クラスはソルトがランダムに決まる仕様であるため、ソルトを指定することはできません。 生成されたソルトは以下のフォーマットでハッシュ値の前に付与されます。

{salt}hashValue

5.4.1版開発ガイドラインのShaPasswordEncoderの利用の実装から移行する場合は、以下のように書き換えます。

MessageDigestPasswordEncoderをapplicationContext.xmlにBean定義してください。

【修正前】

<bean id ="passwordEncoder"
    class="org.springframework.security.authentication.encoding.ShaPasswordEncoder">
    <constructor-arg value="512" />
    <property name="iterations" value="1000" />
</bean>

【修正後】

<bean id="passwordEncoder"
    class="org.springframework.security.crypto.password.MessageDigestPasswordEncoder">
    <constructor-arg name="algorithm" value="SHA-512" />
    <property name="iterations" value="1000" />
<bean>

spring-security.xmlの定義を以下のように修正します。

【修正前】

<bean id="authenticationProvider"
    class="org.springframework.security.authentication.dao.DaoAuthenticationProvider">
    <!-- omitted -->
    <property name="saltSource" ref="saltSource" />
    <property name="userDetailsService" ref="userDetailsService" />
    <property name="passwordEncoder" ref="passwordEncoder" />
</bean>

<bean id="saltSource"
    class="org.springframework.security.authentication.dao.ReflectionSaltSource">
    <property name="userPropertyToUse" value="username" />
</bean>

【修正後】

<bean id="authenticationProvider"
    class="org.springframework.security.authentication.dao.DaoAuthenticationProvider">
    <!-- omitted -->
    <property name="userDetailsService" ref="userDetailsService" />
    <property name="passwordEncoder" ref="passwordEncoder" />
</bean>

既に固定のソルトでハッシュ化されたパスワードに対応するため、UserDetailsに以下の処理を追加します。

パスワードにソルトが付与されていない（文字列の先頭が{でない）場合は、ソルトをパスワードの先頭に付与します。

• UserDetailsの実装クラスへの処理の追加例

public class AccountUserDetails implements UserDetails {

    private final Account account;
    private final Collection<GrantedAuthority> authorities;

    public AccountUserDetails(Account account,
            Collection<GrantedAuthority> authorities) {
        this.account = account;
        this.authorities = authorities;
    }

    public String getPassword() {
        // 追加箇所 開始
        if(!account.getPassword().startsWith("{")){
            return "{" + getUsername() + "}" + account.getPassword();
        }
        // 追加箇所 終了
        return account.getPassword();
    }

    public String getUsername() {
        return account.getUsername();
    }

    // ommited

}

MessageDigestPasswordEncoderはハッシュ化したパスワードにソルトを付与するため、ハッシュ値が移行前より長くなります。 データベースでは適宜カラムサイズを変更する必要があります。

詳細については、開発ガイドラインのMessageDigestPasswordEncoderの利用を参照してください。

開発ガイドラインの OpenEntityManagerInViewInterceptorの設定 にて 新たにWarning「意図せぬLazyInitializationExceptionの発生を防止するために」が追加されました。

Lazy Loadを行う関連Entity（Entityの関連付けアノテーションのfetch属性に指定された値が javax.persistence.FetchType#LAZYのもの）について、 EntityをEntityManagerの生存期間外まで引き継いでしまうと、意図せぬところで org.hibernate.LazyInitializationExceptionが発生する恐れがあります。

特に、セッションやフラッシュスコープ等、リクエストを跨いで保存する場合に注意する必要があります。

[手順が必要なケース]

この手順の適用は任意ですが、以下の全てに当てはまる場合は、次の修正を行うことを推奨します。

• 関連EntityのLazy Loadを行なっている。
• 当該Entityをセッションやフラッシュスコープに格納している。

[修正方法]

【修正前】

public String handle(RedirectAttributes attributes) {

    Entity entity = service.findEntity();

    // 主Entityから取り出した関連Entityをそのままフラッシュスコープに格納している
    attributes.addFlashAttribute("relatedEntity", entity.getRelatedEntity());
}

【修正後】

@Inject
Mapper beanMapper;

public String handle(RedirectAttributes attributes) {

    Entity entity = service.findEntity();

    // 主Entityから取り出した関連EntityをDozerでディープコピーしてフラッシュスコープに格納している
    ReleatedEntity relatedEntity = beanMapper.map(entity.getRelatedEntity(), RelatedEntity.class);
    attributes.addFlashAttribute("relatedEntity", relatedEntity);
}

5.4.1以前の開発ガイドラインでは Collectionマッピング のTodoにおいて、 Collection<T>を使用したマッピングは失敗する旨が記載されていました。

実際には、Dozer 5.5.1でCollection<T>を使用したマッピングに対応されたため、TERASOLUNA Server Framework for Javaの5.0.0以降を利用している場合、マッピングが可能です。

[手順が必要なケース]

この手順の適用は任意ですが、以下のケースに当てはまる場合は、次の修正を行うことを推奨します。

• Collection<T>をDozerを利用せず手動でコピーしている場合

[修正方法]

Dozerを利用してマッピングを行うように修正します。

修正後は、Dozer標準のマッピングでCollection<T>のマッピングができることを、テスト等実施してご確認ください。

Lombok 1.16.22では、@Dataと@NoArgsConstructorの付与順序によってはコンパイルエラーが発生する事象が確認されています。 具体的には、@Dataにより生成されたデフォルトコンストラクタを@NoArgsConstructorが再度生成することによりコンパイルエラーになる事象で、Lombok 1.18.0で修正されています。

この事象は、@NoArgsConstructorを@Dataより上に付与することで回避が可能です。

詳細は、 Lombok-1.16.22-constructor already defined in class を参照してください。

[手順が必要なケース]

@Dataを@NoArgsConstructorより上に付与している場合

[修正方法]

@NoArgsConstructorを@Dataより上に付与します。

【修正前】

@Data
@NoArgsConstructor
public class User {
    // ommited
}

【修正後】

@NoArgsConstructor
@Data
public class User {
    // ommited
}

この更新手順は、release site からダウンロードしたEclipse WTPプロジェクト向けです。

Note

凡例

[テーブルヘッダ]

Non : O/R Mapperに非依存のブランクプロジェクト

MB3 : MyBatis3用のブランクプロジェクト

JPA : JPA用のブランクプロジェクト

[備考欄]

* : オペレーション対象

Eclipse WTP Project of 5.4.2.RELEASE をダウンロードしてください。

Eclipseが起動している場合、Eclipseを終了します。

$YOUR_ECLIPSE_WTP_PROJECT/src/main/webapp/WEB-INF/lib のjarファイルを更新(削除して追加)してください。

.. tabularcolumns:: |p{0.25\linewidth}|p{0.30\linewidth}|p{0.30\linewidth}|p{0.05\linewidth}|p{0.05\linewidth}|p{0.05\linewidth}|

$YOUR_ECLIPSE_WTP_PROJECT/testlib のjarファイルを更新(削除して追加)してください。

.. tabularcolumns:: |p{0.25\linewidth}|p{0.30\linewidth}|p{0.30\linewidth}|p{0.05\linewidth}|p{0.05\linewidth}|p{0.05\linewidth}|

$YOUR_ECLIPSE_WTP_PROJECT/libsrc のソース格納用jarファイルを更新(削除して追加)してください。

.. tabularcolumns:: |p{0.25\linewidth}|p{0.30\linewidth}|p{0.30\linewidth}|p{0.05\linewidth}|p{0.05\linewidth}|p{0.05\linewidth}|

置換文字列を使用して、参照ライブラリを更新してください。

• $YOUR_ECLIPSE_WTP_PROJECT/.classpath
• $YOUR_ECLIPSE_WTP_PROJECT/build.xml

.. tabularcolumns:: |p{0.25\linewidth}|p{0.30\linewidth}|p{0.30\linewidth}|p{0.05\linewidth}|p{0.05\linewidth}|p{0.05\linewidth}|