この記事は、intra-mart Advent Calendar 2013 第21日の記事です。
今回は、AutoRegisteringResourceMapper を紹介させていただきます。
このマッパーを利用すれば、 認可リソースをいちいちルーティングテーブルに設定するという面倒臭さから開放されるのです!
ちょっと誇張し過ぎかも知れません、、、だが、しかし、めげずに説明させていただきますので、お付き合いください。
ルーティングとは?
intra-mart Accel Platformでは、ルーティング機構が搭載されました。
ルータは、クライアントからアクセスされた「 パス 」を元に、ルーティングテーブルの設定にしたがって「 プログラム 」を実行します。
以下のルーティングテーブルを例にしますと、
|
1 2 3 |
<file-mapping path="/app/baz" page="business/baz"> <authz uri="service://app/baz" action="execute" /> </file-mapping> |
このマッピングは、「/app/baz」という パス でアクセスされた場合、スクリプト開発モデルの「business/baz」という プログラム を実行することを意味し、実行するためには、 認可リソース 「service://app/baz」の「execute」アクションが許可されている必要がある、ということを意味します。
このルーティングの仕組みにより、プログラムの実体がどのような形式で提供されているかに左右されることなく、よりWebらしい綺麗なURLでアクセスすることが可能となりました。
認可リソースマッパーとは?
ルーティングテーブルは、「 パス 」と「 認可リソース 」のマッピングを定義していますが、そのマッピングを1対1で静的に記述するだけではなく、プログラマブルにマッピングを行うことも可能です。
これは、ルーティングテーブルの認可設定で使用するマッパーを登録することで実現します。
具体的には、、、
- jp.co.intra_mart.system.router.authz.user.AuthzResourceMapperインタフェースを実装し、
- ルーティングテーブル用 認可リソースマッパー定義設定 に実装したクラスを登録し、
- ルーティングテーブルで登録したマッパーを利用するように設定します。
「AutoRegisteringResourceMapper」の紹介
今回は、認可リソースマッパーの一種で、開発用として提供されている 「AutoRegisteringResourceMapper」 を紹介します。
AutoRegisteringResourceMapperとは、与えられたURLパスから自動的にリソースグループを生成し、リソース登録を行うマッパーです。
これにより、「 パス 」と「 認可リソース 」のマッピングを設定することなく、開発を行うことが可能となります。
先ほどのルーティングテーブルの例ですと、
|
1 2 3 |
<file-mapping path="/app/baz" page="business/baz"> <authz uri="service://app/baz" action="execute" /> </file-mapping> |
を
|
1 |
<file-mapping path="/app/baz" page="business/baz"/> |
と書き換えることが可能となり、認可リソースのマッピング設定を省略することが可能となります。
つまり、このマッパーを利用すれば、 認可リソースをいちいちルーティングテーブルに設定するという面倒臭さから開放されるのです!(※ なお、AutoRegisteringResourceMapper の利用が、実際に開発するシステムに適しているかどうかは別途検討が必要です)
動かしてみよう
では、実際に動かしながら試してみましょう。
まずは「スクリプト開発モデル プログラミングガイド」の 「基本( intra-mart Accel Platform での初めてのプログラミング) 」を ご覧ください。
「 ステップ6:ルーティング設定ファイルの作成 」で示された
|
1 |
<authz-default mapper="welcome-all" /> |
を
|
1 |
<authz-default mapper="dev-auto-register" /> |
に書き換えてください。
iAPを再起動後、画面にアクセスします。
/helloworld/input にアクセスし、テキストボックスに名前を入力後、[Hello]ボタンをクリックしてください。
これで、自動的に認可リソースが登録されました。
認可設定画面で確認してみましょう。
認可リソースが登録されているのが確認できました。
これにより、例えば、開発時に AutoRegisteringResourceMapperを利用して認可リソースを自動登録させた後、
システム本稼働の際には、自動登録された認可関連データを本番環境へ移行することにより、運用が開始できるかと思います。
なお、URL設計が重要なのは今までと変わりません。頑張ってください!頑張ってください!
わかりやすい実用的なURLを設計する技術を身につけるのに役立つサイトまとめがありましたので、リンクしておきます。
http://matome.naver.jp/odai/2131433482685961901
AutoRegisteringResourceMapper の仕様
正式なドキュメントは今後公開予定ですが、取り急ぎ仕様を以下に記載します。
AutoRegisteringResourceMapper は、与えられたURLパスから自動的にリソースグループを生成し、リソース登録を行うマッパーです。
リソースグループは該当のURLに対して初めてアクセスされた際に生成・登録されます。
生成されるリソースグループは以下のようなルールに従って生成されます。(URLパスの例: aaa/bbb/ccc)
- URLパスをスラッシュ(/)毎にリソースグループとして登録する(例の場合aaa、bbb、cccの三段階)
- パスの階層名をリソースグループとして使用する(aaaやbbb))
-
グループに対して名称を登録するロケールは日(ja)、英(en)、中(zh_CN)の3種固定
- ロケールを追加している場合、該当ロケールに紐づく名称は別途登録が必要です。
- 認可設定画面や、後述のパラメータ「name.{locale_id}」などを活用して登録してください。
- ルートからのパス階層をハイフンでつないだ文字列をグループのIDとして使用する。(例のbbbの場合aaa-bbb)
- 最後に指定のURLパスを"service://{URL PATH}"の形式に埋め込んで、リソースURIとして登録する
-
リソース登録の際、authzタグのパラメータを名称として使用する(引き受けるパラメータのキーは以下のとおり)
-
key: name.{locale_id}
- value: {locale_id}をロケールとして利用します
-
key: name.{locale_id}
また、このマッパーはルーティングの認可パラメータに"auto-permit"という値を指定することによってリソース登録の際に以下のサブジェクトに対する許可ポリシーを自動で設定することが可能です。
- 認証 - ゲストユーザ
- 認証 - 認証済みユーザ
auto-permitパラメータの詳細は以下のとおりです。
- key: auto-permit
-
value: true / false
- trueの場合、自動で許可ポリシーを登録します。
- falseの場合、自動で許可ポリシーを登録しません。
- デフォルト(指定なし)の場合は、falseが指定されます。
|
1 2 3 4 5 |
<file-mapping path="/sandbox/index" page="sandbox/index"> <authz mapper="dev-auto-register"> <param key="auto-permit" value="true"/> </authz> </file-mapping> |
auto-permitパラメータを使うことで、
- サーバ起動
- 初回アクセス(= 403ページ )
- 認可設定
- 再アクセス
という動きが、
- サーバ起動
- 初回アクセス(リソース登録 & ポリシー設定)
-
認可設定 -
再アクセス
に変わり、最初から画面へアクセスすることが可能となり、開発時の利便性が高まります。
以上、今回は「AutoRegisteringResourceMapper」を紹介させていただきました。
このマッパーを利用することにより、認可リソースの追加やルーティングテーブルへのリソース設定を行うことなしに、開発を行うことが可能になるため、認可リソースをいちいちルーティングテーブルに設定するという面倒さから開放される ことを知っていただけたかと思います。
ぜひご活用ください。
