Documentation

You are viewing the documentation for Play 1. The documentation for Play 2 is here.

Play 1.0.2 — リリースノート

Play 1.0.2 は play 1.0 ブランチのメンテナンスリリースです。主な新機能は、モジュールリポジトリのサポートと、組込みの CSRF 攻撃対策です。大量の小さなバグも修正されています。

Play 1.0.2 はメンテナンスリリースであり、バージョン 1.0 シリーズとの完全な互換性があります。何か問題にぶつかったら Google Group にて質問してください。

1.0.2 ロードマップページ にて、修正されたバグについて読むことができます。もっとも重要な変更は、このページにてハイライトされています。

Module repository

モジュールリポジトリのゴールは、Play フレームワークの寄贈されたモジュールを集約して、簡単にインストールできるようにすることです。以下は、モジュールに関連する新しいコマンドです:

ほとんどすべてのモジュールが削除されていることに気付くかと思います。すぐに利用できるのは、一連の ‘中心的な’ モジュール: testrunner, docviewer, crud そして secure だけです。

その他のモジュールはオプションです。このため、例えば GWT サポートをインストールしたい場合は、単に play install gwt とタイプして、このモジュールの最新バージョンを取得します。

なぜモジュールを移動したのでしょうか? それは、フレームワークの核となる部分に集中する必要があり、プロジェクト管理をシンプルにする必要があるからです。また、多くの人がいくつかの寄贈されたモジュールを欲しがっており、これは次のやり方で容易に行うことができます: それぞれのモジュールは、専用の管理者を持つスタンドアロンのプロジェクトとするのです。このため、モジュールに特化したバグを報告する際は、そのプロジェクトのホームページと専用のバグトラッカを使用してください。

即座に得られる利点として、これ以降、モジュールのライフサイクルはフレームワークのライフサイクルに縛られなくなります。モジュールは、フレームワークそのものよりも高い頻度でリリースすることができます。そして最後に、フレームワークにはオプションモジュールを一切含めないので、Play の配布サイズは半分になります。

モジュールリポジトリに関する詳細は 専用のページ を読んでください。

組込みのクロスサイトリクエストフォージェリ対策

CSRF は、ウェブアプリケーションにおいて真の問題になる場合があります:

この攻撃手法は、ユーザが認証されていると信じている web アプリケーションにアクセスするページに悪意あるコードかリンクを含めることで実行されます。この web アプリケーションのセッションがタイムアウトされていない場合、攻撃者は認証されていない命令を実行できる場合があります。

この攻撃を防ぐために最初にすることは、GET と POST メソッドを適切に使用することです。これは、アプリケーションの状態を変更に使用されるのは POST メソッドだけであるべきということを意味します。

POST リクエストをセキュアで重要なアクションとして適切に保証する唯一の方法は、認証トークンを発行することです。現在の Play 1.0.2 にはこれを扱う組み込みのヘルパがあります:

例えば、以下のようにすると:

public static destroyMyAccount() {
    checkAuthenticity();
    …
}

適切な認証トークンを含むフォームから呼ばれた場合にのみ動作します:

#{form @ destroyMyAccount()}
    #{authenticityToken /}
    <input type="submit" value="destroy my account">
#{/form}

もちろん、コントローラ階層におけるすべてのアクションを保護したい場合は、これを事前フィルタとして追加することができます。より詳しくは セキュリティガイド を読んでください。

デフォルトで HEAD メソッドをサポート

Play は、GET メソッド用のルートが存在する場合、自動的に HEAD リクエストに応答します。これは、HTTP RFC によって、いかなるリソースも HEAD リクエストに同様に応答することが求められているからです。

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

HEAD メソッドは、サーバがレスポンスにおいてメッセージボディを返してはならない事を除けば GET と同一である。HEAD リクエストへのレスポンスにおける HTTP ヘッダに含まれる外部情報は、GET リクエストへのレスポンスで送られる情報と同一であるべきである。このメソッドは、エンティティボディ自身を転送する事なしにリクエストによって意味されるエンティティに付いての外部情報を得るために使用される。このメソッドは、ハイパーテキストリンクの正当性、アクセス可能性、最近の修正のテストのために、しばしば使用される。

このため、いかなる HEAD リクエストもアクションメソッドを起動しますが、レスポンスの内容はクライアントに送信されません。もちろん、HEAD リクエストに応答するカスタムルートを routes ファイルに追加することで特化することも可能です。例えば、以下のようにします:

GET     /orders/{id}         Orders.show
HEAD    /orders/{id}         Orders.showHead

新しいサンプルアプリケーション、‘zencontact’

Wicket ベースの連絡先管理アプリケーション の移植版である新しいサンプルです。興味がある人のために、Scala モジュールパッケージには、このアプリケーションの Scala 版が含まれています。

アプリケーションサーバへのより良いデプロイ

複数のアプリケーションサーバで、play が生成する WAR アーカイブのデプロイをテストしました。現在の 互換性マトリクス を確認することができます。

JBoss 4.2.x JBoss 5.x JBoss 6M2 Glasshfish v3 IBM Websphere 6.1 IBM Websphere 7 Geronimo 2.x Tomcat 6.x Jetty 7.x Resin 4.0.5

テンプレートにおける新しいリバース機能

アクションの 絶対 URL を生成する @@ 構文をタグのパラメータとして利用することができます。例えば、以下のようにします:

#{form @@save()}
…
#{/}

これは、URL を絶対形式で表現する必要のある email のようなものを生成するためにテンプレートエンジンを使用する場合に便利です。

複雑なオブジェクトのバインディングもサポートしました。このため、例えば次のようなアクションがあったとして:

public static void search(SearchParams params) {
    …
}

SearchParams が以下のような場合:

public class SearchParams {
    public String keywords;
    public String mode;
}

テンプレートに次のように書くことができます:

@{search(params)}

これは、次のような、クエリ文字列に複数の値を含む URL を生成します:

/search?params.keywords=xxxx&params.mode=AND

アプリケーション JavaDoc を生成する新しいコマンド

以下を使って、プロジェクトの JavaDoc を容易に生成することができます:

play javadoc 

このコマンドはプロジェクトと、プロジェクトが使うモジュールの javadoc API ドキュメントを生成します。

今回のリリースでも Eclipse プラグインはさらに良くなります

Eclipse プラグインには、いくつかの新機能があります:

このプラグインをインストールするには、 $PLAY_HOME/support/eclipse から $ECLIPSE_HOME/dropins に JAR ファイルをコピーしてください。

次のリリース: Play 1.0.3 リリースノート