テキストで得られるパスを利用した画像表示

1 <table>

2 <tbody><t r><td>

3 <img src="http://mediasite.msyk.net/data/" data−im="photos@path@＃src" / >

4 < /td>< /t r>< /tbody>

5 < /table>

この方法以外に，プロキシを通じてメディタデータを取得することもできる．プロキシはINTER-Mediator の動作の1つであり，URLのパラメータの与え方によってはメディアのプロキシとして動作する．この仕組 みが必要な理由は，認証や認可を経てメディアデータを取得できるようにするためである．認可と認証に関 わることは，5.9節で解説する．メディアプロキシとしての動作をさせるには，定義ファイルの2つ目の引数

にmedia-root-dirキーの値を記述する．値は運用しているサーバー上の絶対パスを指定する．そして，IMG

タグ要素のsrc属性などが，「定義ファイルへのURL?media=パス」の形式になっていれば，media-root-dir キーで与えたディレクトリから，パラメータに指定したmediaキーの値を相対パスとして得られたファイ ルの内容を，MIMEタイプ等を付与したHTTPで返す．

5.8 マルチクライアントでの更新処理の伝達

Webアプリケーションは，サーバーへのリクエストとレスポンスだけで成り立っている．Webの初期の 頃より「ページを更新するにはブラウザの更新ボタンを押す必要がある」という制約が常識化しており，通 信処理を最小限にするためにも，必要に応じて手作業で更新するということは許容範囲となっていた．この 考え方は現在でも残っている．しかしながら，共有しているデータが更新されたとき，その更新結果が他の クライアントにも多少の遅延があっても支障のない範囲内で更新されることは，決して不要な仕組みでは なく，むしろそれが必要な場合もある．初期のWebアプリケーションでは複雑なことや回線が細いことな どを理由にそうした実装はあまりされなかったが，Ajaxの進展により基本的な仕組みは備わった．

クライアント間で更新されるデータの共有を行う手法は，それぞれのクライアントが保持するドキュメン トオブジェクトの同期を行うことである．インターネット以前の時代より，グループウエアの研究[32]に よってアルゴリズムが考案され，Operational Transformation[95]（操作変換）として一般化されている．ク ライアントサイドで稼働するJavaScriptで開発されているフレームワーク上で実現されており[50]，オブ ザーバブルなモデルをベースにして，モデル間での同期を行うことで，共有データの更新が通知される仕 組みが提唱されている．モデルを経由した更新を実装することで，モデルの特定のフィールドと，いくつか の要素がバインドされることになる．その結果，同一クライアント内でも，同一のフィールドからのデータ 表示を更新するといったことも実現する．

INTER-Mediatorでの実装にあたっては，Operational Transformationのアルゴリズムの実装やあるいは既 存ライブラリの利用を検討したが，複雑な構造を持つドキュメントではなく，データベースはシンプルなリ

レーションである．また，競合の問題は，楽観的なロックによる手法をすでに組み込んでいる．結果的に，

更新や新規レコード作成，レコード削除を通知するという実装で小規模な業務システムのような利用は可 能ではないと考えて実装を行った．ただし，モデル部分の同期という考え方は持ち込んだ．コンテキストの 定義に対応して，実際にクエリーにより得られた結果を保持するコンテキストモデルを内部で管理し，更 新をモデル経由で行う実装を行った．しかしながら，実運用上の問題点が今後は出てくる可能性もある．そ のときには，Operational Transformationのアルゴリズムが参考になる．

データベースのクエリーをしたときに，テーブルと各レコードの主キー値情報を，サーバー側のデータ ベースに記録する．同時に，クライアントごとに一意な識別番号を生成して付与し，テーブルおよびレコー ド情報とともに保持する．別のクライアントが同一のクエリーを実施した場合も同様に，テーブル，各レ コードの主キー値，クライアントの識別子を記録する．ページを閉じるときには，サーバーに記録されたこ れらの情報をクリアする．

そして，あるクライアントであるフィールドを更新した場合，そのレコードをクエリーにより取得したク ライアントに変更があったとことを通知する．ただし，自分自身には通知はせず，クライアント内部での通 知の伝達はそのクライアント内で実施する．コンテキストモデルは，更新，新規レコード，レコード削除に 対する応答を行い，その結果を最終的には要素の更新にまで波及させる．

通知の伝達には，Pusher[82]というサービスを利用した．WebRTC[9]を利用した通知サービスであり，開 発者向けには無償で使える点があることと，ライブラリの利用が極めて容易である点から採用した．一定 規模以上は有償になるが，桁外れの価格でもないため，当初の実装ではこの仕組みを利用することにした．

以上のような方針のもとで実装を行った結果，Pusherを利用するためのID番号をいくつか設定するだけで，

クライアント間での変更結果の同期が実現している．追加で必要なことは，データベースに，管理用のテー ブルを追加するだけで，機能を利用するための追加の手続き的なプログラムは必要ない．INTER-Mediator が目指す開発モデルに合致した機能の組み込みが実現できた．

5.9 認証と認可の実装

INTER-Mediatorは認証や認可を伴うアプリケーションの開発を，宣言的な記述のみで行える．アカウン

トは，データベースに用意したテーブルを利用するか，あるいはデータベースエンジンに登録したユーザー を利用できる．コンテキストやあるいは定義ファイル全体に対して認証を必要とするような設定を行うと，

そのコンテキストに関わるすべての処理において，正しいパスワードを元にしたハッシュ値を含めた応答が 必要となる．

5.9.1 認証と認可に必要とされる機能

Webアプリケーションで必要とされる認証や認可の機能に関して，INTER-Mediatorでの実装状況を表5.2 にまとめた．

5.9. 認証と認可の実装 63

表5.2:認証と認可に組み込まれた機能

分類 機能 対応状況 補足

認証 ログインパネル（ブラウザ） Webサーバーで実現 HTTP認証下でのフレームワークの稼働は可能 ログインパネル（HTML） フレームワークが用意 標準のログインパネル以外にカスタマイズも可能 ログアウト ページネーション上に表示 APIをJavaScriptで呼び出すことでも可能

ユーザー記録データベース 既定のフィールド名で用意 サーバー側でデータベース処理を実行するときに利用 認証処理・エラー処理 サーバー側で判定 クライアント側では繰り返し認証を求めるなどの処理

を実装

ログイン状態の継続 定義ファイルに指定 JavaScriptの変数あるいはクッキーで保持 データベースのユーザーでロ

グイン

定義ファイルに指定 データベース側に設定した認可の設定を利用できる

ユーザーがパスワードを変更 可能 標準のログインパネルに用意 メディタデータの取得 定義ファイルに指定 認証されたアクセスのみに設定可能

ユーザ ユーザー管理システム サンプルに用意 ユーザーの登録やグループ作成，割り当てなどが可能 ー管理 新規登録 サンプルに用意 サンプルの「ユーザー管理システム」に機能を用意

パスワード変更 サンプルに用意 サンプルの「ユーザー管理システム」に機能を用意 メールアドレスの利用 ファイルに指定 ユーザーID以外に登録時のメールアドレスでのログ

イン

サインアップ サンプルで対応 メールアドレスに応答することでパスワードを発行 パスワードリセット サンプルで対応 パスワードリセットをユーザーへのメールと連携して

実施

認可 グループ管理 データベースを利用 グループおよび所属情報のテーブルを定義して運用で きる

グループのロール ファイルに指定 CRUD個別あるいは全部に対してアクセス権限の設定 ができる

適用範囲 定義ファイルに指定 ページ単位，コンテキスト単位，レコード単位 メディタデータの認可 定義ファイルに指定 メディアアクセス専用トークンを発行

セキュ パスワード漏洩対策 ハッシュ値の利用 データベースにはソルトを付与したハッシュ値で保存 リティ セッション対策 チャレンジ-レスポンス データベースのアクセスごとにチャレンジを受け取り，

次の処理でチャンレンジをもとにパスワードの暗号化 を行う．チャレンジは通常は1のみの利用

データベースのユーザーのパ スワード送信

非対称鍵で暗号化 サーバー側に用意した公開鍵をクライアントに送り，パ スワードを暗号化して送付

更新不可のフィールド 定義ファイルに指定 主キーや外部キーなど書き換えしたくないフィールド の指定

読み出し不可のフィールド 定義ファイルに指定

5.9.2 コンテキストで認証を必要にする

Webアプリケーションで認証を行い認可を適用させるには，定義ファイルに設定を記述する．コンテキスト に記述することでコンテキストごとに異なる設定が可能だが，定義ファイル内のすべてのコンテキストに共 通の設定を適用することもできる．コンテキストごとの設定例をリスト5.3に示した．設定はauthentication キーに記述する．定義ファイル全体に適用させる場合には，同様にauthenticationキーの記述を，定義ファ イルに記述するIM_Entry関数の2つ目の引数の要素に記述する．