谷口 浩之 (〒88 神奈川県川崎市中原区上小田中４丁目１番１号 富士通株式会社内 Kanagawa, 2118588, JP)
富士通株式会社 (〒88 神奈川県川崎市中原区上小田中４丁目１番１号 Kanagawa, 2118588, JP)
TANIGUCHI, Hiroyuki (1-1 Kamikodanaka 4-chome, Nakahara-ku, Kawasaki-sh, Kanagawa 88, 2118588, JP)
| Webアプリ診断アプリケーションが実行する診断処理を,所定の拡張機能部が実行する処理と連携させる装置であって, 診断対象を含むWebアプリケーションの実行順序が記述されたシナリオにもとづいて,当該シナリオのWebアプリケーションに対応するリクエストを判定する判定ルールを管理する判定ルールデータベースと, Webアプリ診断アプリケーションから,診断対象Webアプリケーションへ送信される診断リクエストを取得するリクエスト取得部と, 前記判定ルールにもとづいて,前記診断リクエストが対応するWebアプリケーションを判定し,前記シナリオにもとづいて,当該Webアプリケーションより実行順序が前であるWebアプリケーションが存在するかを判定する診断リクエスト判定部と, 前記診断対象Webアプリケーションより実行順序が前のWebアプリケーションに対応するリクエストが未送信である場合に,当該診断リクエストの送信を保留し,前記シナリオに従って当該前のWebアプリケーションに対応する拡張リクエストを生成する拡張リクエスト生成部と, 前記拡張リクエストに対するレスポンスが受信されている場合に,前記保留された診断リクエストを当該診断対象Webアプリケーションへ転送するリクエスト送信制御部と, 前記診断リクエストに対するレスポンスを受信した場合に,前記Webアプリ診断アプリケーションへ当該レスポンスを診断レスポンスとして転送するレスポンス送信制御部とを備える ことを特徴とするWebアプリ診断アプリケーション連携装置。 |
| 前記判定ルールにもとづいて,前記受信されたレスポンスの内容を判定するレスポンス判定部を備えるとともに, 前記レスポンス送信制御部は,前記レスポンスが前記診断リクエストに対するレスポンスでない場合に,前記拡張機能部へ当該レスポンスを渡し,前記レスポンスが前記診断リクエストに対するレスポンスである場合に,前記Webアプリ診断アプリケーションへ当該レスポンスを診断レスポンスとして転送する ことを特徴とする請求項1に記載のWebアプリ診断アプリケーション連携装置。 |
| 前記拡張リクエスト生成部は,前記レスポンスが所定の動作に対するエラーである場合に,前記シナリオにもとづいて所定のWebアプリケーションに対応する拡張リクエストを生成する ことを特徴とする請求項2に記載のWebアプリ診断アプリケーション連携装置。 |
| 前記診断リクエスト判定部は,前記シナリオから,前記診断対象Webアプリケーションへ遷移する複数のWebアプリケーションが存在する場合に,前記複数Webアプリケーションから前記診断対象Webアプリケーションへの各遷移を識別し,当該識別情報を前記判定ルールデータベースへ記録し, 前記拡張リクエスト生成部は,前記識別された遷移ごとの診断対象Webアプリケーションに対応する診断リクエストを,前記Webアプリ診断アプリケーションのクライアントに送信させるためのリダイレクトリクエストを生成し, 前記リクエスト送信制御部は,前記リダイレクトリクエストを前記Webアプリ診断アプリケーションへ送信する ことを特徴とする請求項1または請求項2に記載のWebアプリ診断アプリケーション連携装置。 |
| 前記判定ルールデータベースは,複数の拡張機能部の各起動条件を記録し, 前記診断リクエスト判定部は,前記診断リクエストを解析し,起動する拡張機能部を決定し,当該決定した拡張機能部の起動を要求する ことを特徴とする請求項1ないし請求項4のいずれか一項に記載のWebアプリ診断アプリケーション連携装置。 |
| コンピュータが実行する,Webアプリ診断アプリケーションが実行する診断処理を所定の拡張機能部が実行する処理と連携させる処理方法であって, Webアプリ診断アプリケーションから,診断対象Webアプリケーションへ送信される診断リクエストを取得する処理過程と, 診断対象を含むWebアプリケーションの実行順序が記述されたシナリオにもとづいて,当該シナリオのWebアプリケーションに対応するリクエストを判定する判定ルールを管理する判定ルールデータベースを参照し,当該判定ルールにもとづいて,前記診断リクエストが対応するWebアプリケーションを判定し,前記シナリオにもとづいて,当該Webアプリケーションより実行順序が前であるWebアプリケーションが存在するかを判定する処理過程と, 前記診断対象Webアプリケーションより実行順序が前のWebアプリケーションに対応するリクエストが未送信である場合に,当該診断リクエストの送信を保留し,前記シナリオに従って当該前のWebアプリケーションに対応する拡張リクエストを生成する処理過程と, 前記拡張リクエストに対するレスポンスが受信されている場合に,前記保留された診断リクエストを当該診断対象Webアプリケーションへ転送する処理過程と, 前記診断リクエストに対するレスポンスを受信した場合に,前記Webアプリ診断アプリケーションへ当該レスポンスを診断レスポンスとして転送する処理過程とを備える ことを特徴とするWebアプリ診断アプリケーション連携処理方法。 |
| Webアプリ診断アプリケーションが実行する診断処理を,所定の拡張機能部が実行する処理と連携させる処理を実行するために,コンピュータを, 診断対象を含むWebアプリケーションの実行順序が記述されたシナリオにもとづいて,当該シナリオのWebアプリケーションに対応するリクエストを判定する判定ルールを管理する判定ルールデータベースと, Webアプリ診断アプリケーションから,診断対象Webアプリケーションへ送信される診断リクエストを取得するリクエスト取得部と, 前記判定ルールにもとづいて,前記診断リクエストが対応するWebアプリケーションを判定し,前記シナリオにもとづいて,当該Webアプリケーションより実行順序が前であるWebアプリケーションが存在するかを判定する診断リクエスト判定部と, 前記診断対象Webアプリケーションより実行順序が前のWebアプリケーションに対応するリクエストが未送信である場合に,当該診断リクエストの送信を保留し,前記シナリオに従って当該前のWebアプリケーションに対応する拡張リクエストを生成する拡張リクエスト生成部と, 前記拡張リクエストに対するレスポンスが受信されている場合に,前記保留された診断リクエストを当該診断対象Webアプリケーションへ転送するリクエスト送信制御部と, 前記診断リクエストに対するレスポンスを受信した場合に,前記Webアプリ診断アプリケーションへ当該レスポンスを診断レスポンスとして転送するレスポンス送信制御部とを備える装置として 機能させるためのWebアプリ診断アプリケーション連携プログラム。 |
| Webアプリ診断アプリケーションが実行する診断処理を,所定の拡張機能部が実行する処理と連携させる処理を実行するために, Webアプリ診断アプリケーションから,診断対象Webアプリケーションへ送信される診断リクエストを取得する処理と, 診断対象を含むWebアプリケーションの実行順序が記述されたシナリオにもとづいて,当該シナリオのWebアプリケーションに対応するリクエストを判定する判定ルールを管理する判定ルールデータベースを参照し,当該判定ルールにもとづいて,前記診断リクエストが対応するWebアプリケーションを判定し,前記シナリオにもとづいて,当該Webアプリケーションより実行順序が前であるWebアプリケーションが存在するかを判定する処理と, 前記診断対象Webアプリケーションより実行順序が前のWebアプリケーションに対応するリクエストが未送信である場合に,当該診断リクエストの送信を保留し,前記シナリオに従って当該前のWebアプリケーションに対応する拡張リクエストを生成する処理と, 前記拡張リクエストに対するレスポンスが受信されている場合に,前記保留された診断リクエストを当該診断対象Webアプリケーションへ転送する処理と, 前記診断リクエストに対するレスポンスを受信した場合に,前記Webアプリ診断アプリケーションへ当該レスポンスを診断レスポンスとして転送する処理とを, コンピュータに実行させるためのプログラムを記録する ことを特徴とするWebアプリ診断アプリケーション連携プログラム記録媒体。 |
本発明は,Webアプリケーションのセキュリ ティ診断アプリケーションまたはシステムと 拡張機能部との連携技術に関する。より詳し くは,Webアプリケーションの脆弱性を発見す ためのWebアプリケーション診断アプリケー ョンまたはシステムが実行する診断処理と, 張機能部が実行する処理とを協働して動作 せるための連携処理に関する。
Webアプリケーションは,電子申請システム や業務データ管理システムなど,Webを使った ーザインターフェースでシステムを構築す 際に,Webサーバに構築されるアプリケーショ である。Webアプリケーションによりシステ を構築する利点は,特別なクライアントソフ トが必要なく,一般的なWebブラウザで利用が 能なことである。そのため,インターネット 利用してサービスを提供するシステムから 業内の業務システムまで,また大規模システ ムから小規模なシステムまで,さらに複雑な ステムから簡易なシステムまで,広く利用さ るようになっている。
しかし,Webアプリケーションの脆弱性によ り,個人情報漏洩などの事件が起こり問題に っている。このような脆弱性を発見するた に,Webアプリケーションのセキュリティの診 システムがある。
図9に,Webアプリケーション診断システム 概念図を示す。
Webアプリケーション診断システム(Webアプ リ診断システム)90は,テスト用のリクエスト ッセージおよびそのレスポンスメッセージ 分析し,診断対象のWebアプリケーション(診断 対象Webアプリ)95の脆弱性を診断するシステム である。
Webアプリ診断システム90は,基本的に,1つ Webアプリケーション診断アプリケーション 構成され,次のような基本機能部91を持って る。
(1)診断対象Webアプリ95(例えば,CGI)の名称 記憶する。
(2)診断対象Webアプリ95を動作させるため パラメータを作成する。
(3)診断用のリクエストメッセージ(主にHTT Pメッセージ)を作成し,Webアプリケーションサ ーバ(Webアプリサーバ)93に構成されている診 対象Webアプリ95に送信する。
(4)診断対象Webアプリ95からのレスポンス ッセージを分析し,診断レポートを出力する
さらに,前記の基本機能部91の各機能に加 て,いくつかの拡張機能を提供する拡張機能 部92(92-1,92-2,…,92-n)も提供されている(例えば, 特許文献1参照)。拡張機能部92は,例えば,所定 のシナリオに従ってWebアプリケーションを順 番に実行する処理,同一のWebアプリケーショ への状態遷移が複数ある場合に状態遷移ご にWebアプリケーションを管理する処理など 行う。
Webアプリ診断システム90として,各社から 々な製品が提供されている。Webアプリケー ョンの普及やセキュリティに対するユーザ 意識向上とともに,診断アプリケーションも 高機能化する傾向がある。
しかし,Webアプリケーションは,複雑なシ テムから簡易なシステムまで広く使われる そのため,高機能な診断システムを導入して ,診断性能が過多になり,初期投資が高くな という問題がある。
また,Webアプリケーションは,容易に拡張 れる可能性があるため,低機能な診断システ を導入しても,診断性能が不足する可能性が ある。さらに,いずれ性能不足となれば再投 が必要となる場合もある。
そのため,機能を追加することよって高機 能化できる拡張性および柔軟性の高いWebアプ リ診断システムが必要とされている。
図10に,Webアプリ診断システムをプログラ 連携方式によって機能拡張する場合の概念 を示す。
Webアプリ診断システム90を高機能化する場
,診断システムについて提供されているプロ
ラム連携手段,例えば,API(Application Program Int
erface)を用いて,新たな拡張機能を開発するこ
によって実現可能である。実際に拡張機能
追加する場合に,拡張機能のモジュールを,
ラグインまたはアドインとしてアプリケー
ョン(基本機能部91)に取り込むことによって
現できる。
しかし,APIを利用してWebアプリ診断システ ム自体を機能拡張することは,APIが公開され いるアプリケーションを対象とする場合に み可能である。逆に言えば,APIが提供されて ないアプリケーションに対しては機能拡張 できないという問題がある。
例えば,WebアプリケーションAが,利用者に 認を求めるWebアプリケーションBを含む画面 を経由したときのみ動作する場合に,Webアプ ケーションAを診断とすると仮定する。この 断のためには,診断手順として画面遷移を意 識したHTTPリクエスト送出を行う必要がある 具体的には,「WebアプリAはWebアプリBの後に 作する」という画面遷移情報を管理する拡 機能が必要である。したがって,診断手順を 更できるAPIが提供されているWebアプリ診断 ステム90を利用している必要がある。
本発明の目的は,特定の診断アプリケーシ ョンに依存することなく,柔軟にWebアプリ診 システムの機能拡張が行えるシステム構築 段を提供することである。特に,Webアプリの 断処理と,診断手順に関する拡張機能とが協 調動作できる連携処理を実現するための連携 処理手段を実現することである。
本発明は,Webアプリケーション診断アプリ ケーションまたはシステムと,拡張機能部と 協調動作するための連携処理を実現するも であって,既存のWebアプリ診断アプリケーシ ンから,診断対象Webアプリに対して送信され るリクエストメッセージ,および診断対象Web プリからWebアプリ診断アプリケーション向 に送信されるレスポンスメッセージを入力 して,所定の拡張機能を動作させることがで る連携機能を提供する。これによって,既存 のWebアプリ診断システムの機能拡張を可能と する。
本発明にかかる装置は,診断対象を含むWeb アプリケーションの実行順序が記述されたシ ナリオにもとづいて,当該シナリオのWebアプ ケーションに対応するリクエストを判定す 判定ルールを管理する判定ルールデータベ スを備える。そして,当該装置のリクエスト 得部は,Webアプリ診断アプリケーションから ,診断対象Webアプリケーションへ送信される 断リクエストを取得する。すると,診断リク スト判定部は,判定ルールにもとづいて,診 リクエストが対応するWebアプリケーション 判定し,シナリオにもとづいて,このWebアプリ ケーションより実行順序が前であるWebアプリ ケーションが存在するかを判定する。診断対 象Webアプリケーションより実行順序が前のWeb アプリケーションに対応するリクエストが未 送信である場合に,拡張リクエスト生成部は, の診断リクエストの送信を保留し,シナリオ に従ってこの前のWebアプリケーションに対応 する拡張リクエストを生成する。
リクエスト送信制御部は,拡張リクエスト に対するレスポンスが受信されている場合に ,前記保留された診断リクエストを当該診断 象Webアプリケーションへ転送する。そして, スポンス送信制御部は,診断リクエストに対 するレスポンスを受信した場合に,Webアプリ 断アプリケーションへ当該レスポンスを診 レスポンスとして転送する。
これによって,本発明は,Webアプリ診断ア リケーションと拡張機能部とを協働して動 させることができ,既存のWebアプリ診断シス ムの機能拡張を実現することができる。
また,本発明に係る装置は,判定ルールに とづいて,受信されたレスポンスの内容を判 するレスポンス判定部を備えるとともに,前 記レスポンス送信制御部では,レスポンスが 断リクエストに対するレスポンスでない場 に,前記拡張機能部へこのレスポンスを渡し, レスポンスが診断リクエストに対するレスポ ンスである場合に,Webアプリ診断アプリケー ョンへ当該レスポンスを診断レスポンスと て転送することができる。
また,本発明に係る装置の前記拡張リクエ スト生成部は,レスポンスが所定の動作に対 るエラーである場合に,シナリオにもとづい 所定のWebアプリケーションに対応する拡張 クエストを生成することができる。
これにより,Webアプリ診断アプリケーショ ンは,拡張機能部によって管理されたシナリ を利用して,診断対象のWebアプリから診断リ エストに対するレスポンスだけを受信する とができる。よって,既存のWebアプリ診断シ ステムにおいて,診断対象Webアプリケーショ の実行手順の管理機などの拡張機能を実現 ることができる。
また,本発明にかかる装置の前記診断リク エスト判定部は,シナリオから,診断対象Webア リケーションへ遷移する複数のWebアプリケ ションが存在する場合に,複数Webアプリケー ションから前記診断対象Webアプリケーション への各遷移を識別し,当該識別情報を前記判 ルールデータベースへ記録する。この場合 ,前記拡張リクエスト生成部は,前記識別され た遷移ごとの診断対象Webアプリケーションに 対応する診断リクエストを,前記Webアプリ診 アプリケーションのクライアントに送信さ るためのリダイレクトリクエストを生成す ことができる。そして,前記リクエスト送信 御部は,前記リダイレクトリクエストを前記 Webアプリ診断アプリケーションへ送信するこ とができる。
これにより,同一のWebアプリであって異な る状態遷移のものを識別して管理できる拡張 機能部がある場合に,Webアプリ診断アプリケ ションは,拡張機能部によって状態遷移ごと 識別されたWebアプリごとに診断リクエスト 送信できるようになるため,診断対象Webアプ リケーションから,拡張機能部によって状態 移が識別された別々の診断リクエストに対 るレスポンスを受信することができる。よ て,既存のWebアプリ診断システムにおいて,診 断対象Webアプリケーションの状態遷移の管理 などの拡張機能を実現することができる。
また,本発明は,前記装置が実行する処理 コンピュータが実行する処理方法,または,前 記装置を構成する各要素をコンピュータに実 現させるためのプログラムおよびこのプログ ラムの記録媒体として実施することが可能で ある。
本発明によれば,Webアプリ診断アプリケー ションと拡張機能部との連携動作を実現する ことができる。この連携動作によって,機能 張用のAPIが提供されていない既存のWebアプ 診断システムに対しても,外付けの装置によ 機能拡張が可能となるため,高い拡張性と柔 軟性を確保することができる。
1 Webアプリケーション診断連携装置(連携装
置)
10 Webアプリケーション診断連携部(連携部)
11 判定ルールデータベース(判定ルールDB)
12 診断リクエスト判定部
13 拡張リクエスト生成部
14 拡張レスポンス判定部
15 診断レスポンス生成部
2 Webアプリケーション診断サーバ(診断サー
バ)
20 Webアプリ診断アプリケーション(診断ア
リ)
3 Webアプリケーションサーバ(Webアプリサー
バ)
30 診断対象Webアプリケーション(対象アプ
)
4 拡張機能実行装置
40 拡張機能部
41 処理実行部
42 データ管理部
43 シナリオテーブル
5 HTTPメッセージ送受信装置
50 HTTPメッセージ送受信部(メッセージ送受
部)
51,53 受信部
52,54 送信部
6 シナリオ制御サーバ
7 ユーザPC
70 Webブラウザ
図1に,本発明の実施の形態における概念 を示す。
本発明を実施する診断システムは,本発明 にかかるWebアプリ診断連携装置(連携装置)1,We bアプリ診断サーバ2,Webアプリサーバ3,および 張機能実行装置4で構成される。連携装置1 ,Webアプリ診断サーバ2とWebアプリサーバ3と 間に連結される。
Webアプリ診断サーバ2は,既存のWebアプリ 断アプリケーション(診断アプリ)20を備える 診断アプリ20は,Webアプリサーバ3に在る診断 対象のWebアプリ(対象アプリ)30にHTTPリクエス を送信し,そのHTTPレスポンスを受信・解析 て,対象アプリ30のレポートを出力する基本 能を備える。
拡張機能実行装置4は,診断アプリ20の拡張 機能を実現する連携装置1とデータ通信が可 であり,HTTPの診断リクエスト・レスポンスに 対する管理を行い,メッセージの送受信を所 のシナリオにもとづいて制御する機能を実 するものとする。
連携装置1は,診断アプリ20からWebアプリサ ーバ3上の対象アプリ30に対して送信されるHTT Pリクエストや,対象アプリ30から診断アプリ ーション20に対して送信されるHTTPレスポン を取得し,診断アプリケーション20を,新機能 ある拡張機能実行装置4と協調動作させる連 携処理を行う。
図2に,本発明にかかる連携装置1の機能構 図を示す。
連携装置1は,OS(オペレーションシステム) 一部として構成されるHTTPリクエスト・レス ポンスを送受信するHTTPメッセージ送受信装 (メッセージ送受信装置)5と,複数の拡張機能 行装置4それぞれと連携して,診断アプリケ ション20の機能を拡張させるための装置であ る。
連携装置1は,判定ルールデータベース(DB)1 1,診断リクエスト判定部12,拡張リクエスト生 部13,拡張レスポンス判定部14,および診断レ ポンス生成部15で構成されている。
判定ルールデータベース(DB)11は,診断リク エスト判定部12と拡張レスポンス判定部14に ける判定ルールを保存し,参照,書き換えなど を管理する。
判定ルールは,拡張機能実行装置4で実現 れる拡張機能の実行に必要なデータ,条件な をもとに定義された情報である。
診断リクエスト判定部12は,診断アプリ20 らのHTTPリクエスト(診断リクエスト)を,メッ ージ送受信装置5を介して取得し,この診断 クエストを保留・分析し,拡張機能実行装置4 のデータや判定ルールDB11の判定ルールにも づいて,拡張機能実行装置4を起動すること, 断リクエストをそのまま対象アプリ30に送信 させることなどを判断する。
拡張リクエスト生成部13は,診断リクエス 判定部12や拡張機能実行装置4からのデータ 受け,対象アプリ30に対するHTTPリクエスト( 張リクエスト)を生成する。
拡張レスポンス判定部14は,対象アプリ30 らのHTTPレスポンス(拡張レスポンス)を,メッ ージ送受信装置5を介して取得し,このレス ンスを分析し,拡張機能実行装置4のデータや 判定ルールDB11の判定ルールにもとづいて,拡 機能実行装置4を起動すること,拡張レスポ スをそのまま診断アプリ20へ送信させること などを判断する。
診断レスポンス生成部15は,拡張レスポン 判定部14や拡張機能実行装置4からのデータ 受け,診断リクエストの結果となるHTTPレス ンス(診断レスポンス)を生成する。
拡張機能実行装置4は,所定のシナリオに って,診断対象となるWebアプリを逐次実行さ るメッセージの送受信を処理する処理実行 41,処理結果のデータを管理するデータ管理 42を備える。シナリオはシナリオテーブル43 に記憶される。
HTTPメッセージ送受信装置(メッセージ送 信装置)5は,OSの一部として構成され,Webアプ 診断サーバ2とWebアプリサーバ3との間のHTTP クエスト・レスポンスを送受信する。メッ ージ送受信装置5は,受信部51,53,送信部52,54を える。
受信部51は,Webアプリ診断サーバ2から診断 リクエストを受信し,診断リクエスト判定部12 へ渡す。送信部52は,拡張リクエスト生成部13 生成された拡張リクエストまたは診断リク スト判定部12で保留された診断リクエスト Webアプリサーバ3へ送信する。
受信部53は,Webアプリサーバ3から送信され た診断レスポンスまたは拡張レスポンスを受 信し,拡張レスポンス判定部14へ渡す。送信部 54は,診断レスポンスをWebアプリ診断サーバ2 送信する。
連携装置1の処理動作を,以下の第1~第3の 施例として説明する。第1~第3の実施例では, 断システムは,決められた画面遷移が必須で あるWebアプリを診断対象とする。このような 診断が不可能な既存の診断アプリ20に,シナリ オ化した診断手順を実行できる診断シナリオ 制御機能を備える拡張機能実行装置4の機能 拡張機能として追加した診断を行うものと る。
図3に本発明の第1の実施例における診断 ステムの機能構成図,および図4に第1の実施 における動作フロー図を示す。また,図5に第 2の実施例における診断システムの機能構成 ,図6に第2の実施例における動作フロー図,図7 に第3の実施例における診断システムの機能 成図,図8に第3の実施例における動作フロー をそれぞれ示す。
図3,図5および図7に示す診断システムは,We bアプリ診断サーバ(診断サーバ)2,Webアプリサ バ3,シナリオ制御サーバ6からなる。さらに, 図7の構成例では,ユーザPC7が含まれる。これ の機器は,それぞれネットワークで接続され ている。
シナリオ制御サーバ6は,診断サーバ2とWeb プリサーバ3との間に設置される。
シナリオ制御サーバ6は,連携装置1をソフ ウェアとして実施する連携部10,拡張機能実 装置4をソフトウェアとして実施する拡張機 能部40がそれぞれ動作するサーバである。シ リオ制御サーバ6は,OSの機能として,HTTPメッ ージを送受信するメッセージ送受信部50を える。
実施例において,連携部10と拡張機能部40 は,シナリオ制御サーバ6上で動作しているこ とを前提にしているが,専用装置(アプライア ス)などの動作基盤で実現されてもよい。
診断サーバ2は,既存の診断アプリ20が動作 するサーバである。診断アプリ20は,対象アプ リ30に対するリクエストを作成・送信し,その レスポンスを解析して診断結果をレポート形 式で出力する機能をもつことが必要条件とな る。診断アプリ20は,さらに,対象アプリ30に対 するリクエストを分析し,対象アプリ30がある ことを記憶する機能をもつことができる。
Webアプリサーバ3は,対象アプリ30となる,CG IやJava(登録商標)サーブレットなどのWebアプ ケーションが動作するサーバである。ここ は,CGIを,Webアプリケーション一般をさす用語 として扱う。
図7に示すユーザPC7は,Webブラウザ70が動作 する一般的なパーソナルコンピュータ機器で ある。パーソナルコンピュータ機器以外に,PD AやVoIP/IP電話専用機器などの端末,ネットワー クカード単体などであってもよい。
〔第1の実施例〕
第1の実施例として,決められた動作手順が
須であるWebアプリの診断が不可能な既存の
断アプリケーションと,決められたシナリオ
作が可能なシナリオ制御機能とを協調動作
せるための連携,特に,HTTPリクエストに応じ
連携動作の例について説明する。
第1の実施例の前提条件として,診断サー 2の診断アプリ20には,Webアプリサーバ3の対象 アプリ30が登録され,診断メッセージの処理が 可能な状態とする。
診断アプリ20は,Webアプリ「CGI-B」に対す 診断リクエスト(a)を作成・送信し,そのレス ンス(f)を解析して,診断結果をレポート出力 する。ただし,Webアプリサーバ3側で,「CGI-B」 「CGI-A」の後に動作するように設定されて ることは認識できない。
拡張機能部40のシナリオテーブル43には, ナリオAとして「CGI-A,CGI-Bの順番で実行する ことを記憶している。ただし,外部,例えば診 断アプリ20からのリクエストに応じて,動作さ せるシナリオを選択することはできない。
拡張機能部40は,起動されるとシナリオテ ブル43に保持しているシナリオを実行する 例えば,CGI-Aのリクエスト(b)を作成し,送信す 。また,CGI-Aのレスポンス(c)を受信した後,CGI -Bのリクエスト(d)を作成し,送信する。
連携部10は,診断リクエスト(a)を契機に,拡 張機能部40の最適なシナリオを動作させる。 して,拡張機能部40が出すリクエスト(d)の作 時に,診断アプリ20からのリクエスト(a)の情 を反映させ,リクエスト(d)をWebアプリサーバ 3へ送信する。
さらに,連携部10は,診断アプリ20のリクエ ト(a)に対応したレスポンス(e)を診断レスポ ス(f)とし,診断アプリ20へ返信する。
図4を用いて,第1の実施例における連携処 の流れをより詳細に説明する。
ステップS1: 診断アプリ20からのリクエス ト(a)をHTTPメッセージ送受信部50の受信部51が 信すると,連携部10の診断リクエスト判定部1 2が起動される。
ステップS2: 診断リクエスト判定部12では ,リクエスト(a)がCGI-Bに対する診断リクエスト であるとリクエスト(a)内のURL情報から識別し ,拡張機能部40のデータ管理部42を通じてシナ オテーブル43内の該当するシナリオAを読み す。
ステップS2″: シナリオテーブル43内に該 当するシナリオがない場合は,リクエスト(a) そのままリクエスト(b)として送信部52を通じ てWebアプリサーバ3へ送信する。
ステップS3: 診断リクエスト判定部12は, クエスト(a)の情報を拡張リクエスト生成部13 へ送信する。
ステップS4: 診断リクエスト判定部12は, リクエスト(a)(ここではCGI-Bのリクエスト)に するレスポンスが着たら,診断アプリ20への スポンスとして返信する」というルールを 定ルールDB11へ保存しておく。
ステップS5: 診断リクエスト判定部12は, み出したシナリオAを起動することを判断し, 拡張機能部40の処理実行部41に対してシナリ Aを実行させる。読み出したシナリオが複数 る場合には,順次これを起動する。
ステップS6: 拡張機能部40は,CGI-Aに対する メッセージを生成・送信する。このメッセー ジ送信時に,連携部10の拡張リクエスト生成部 13が呼ばれる。
ステップS7: 拡張リクエスト生成部13では ,入力された送信情報が,リクエスト(a)と同じW ebアプリ(CGI-B)に対するものかを判定する。入 力された送信情報がWebアプリ(CGI-B)に対する のではない場合(ここではCGI-A)には,そのまま リクエスト(b)として,送信部52を通じてWebアプ リサーバ3へ送信する。
ステップS8: Webアプリサーバ3からのレス ンス(c)を受信部53が受信すると,連携部10の 張レスポンス判定部14が起動される。
ステップS9: 拡張レスポンス判定部14は, 定ルールDB11を参照し,レスポンス(c)が診断ア プリ20への返信対象でないことを判断する。
ステップS10: 拡張レスポンス判定部14は,C GI-Aのレスポンス(c)を拡張機能部40の処理実行 部41へ渡す。
ステップS11: 拡張機能部40は,シナリオAに したがって,CGI-Bに対するメッセージを生成し ,送信する。このメッセージの送信時には,連 部10の拡張リクエスト生成部13が呼ばれる。
ステップS12: 拡張リクエスト生成部13で ,入力された送信情報が,リクエスト(a)と同じ Webアプリ(CGI-B)に対するものかを判定する。 力された送信情報がWebアプリ(CGI-B)に対する のである場合(ここではCGI-B)には,保存して いたリクエスト(a)と置き換え,リクエスト(d) して送信部52を通じてWebアプリサーバ3へ送 する。
ステップS13: Webアプリサーバ3からのレス ポンス(e)を受信部53が受信すると,連携部10の 張レスポンス判定部14が起動される。
ステップS14: 拡張レスポンス判定部14は, 定ルールDB11を参照し,レスポンス(e)が診断 プリ20への返信対象であること,診断レスポ スの生成が必要なことを判断する。
ステップS15: 拡張レスポンス判定部14は, 断レスポンス生成が必要な場合は,CGI-Bのレ ポンス(e)を診断レスポンス生成部15へ渡す 一方,診断レスポンス生成が必要でない場合 ,レスポンス(e)を診断レスポンス(f)として, 信部54を通じて診断アプリ20へ送信すること ある(ステップS15″)。なお,拡張機能部40に スポンス(e)の受信結果を通知することもあ (ステップS15′)。
ステップS16: 診断レスポンス生成部15は, スポンス(e)を診断レスポンス(f)として,送信 部54を通じて診断アプリ20へ送信する。
〔第2の実施例〕
第2の実施例として,決められた動作手順が
須であるWebアプリの診断が不可能な診断ア
リ20と,決められたシナリオ動作が可能な拡
機能部40とを協調動作させるための連携動作
,特に,HTTPレスポンスに応じた連携動作の例に
ついて説明する。
第2の実施例では,診断アプリ20には,対象 プリ30が登録され,診断メッセージの処理が 能であり,拡張機能部40のシナリオテーブル43 には,対象アプリ30に関するシナリオBとして, CGI-A,CGI-Bの順番で実行する」ことが設定さ ているとする。ここで,CGI-Bは,データベース レコード削除を伴うWebアプリであり,CGI-Aは, データベースへのレコード登録を行うWebアプ リであるとする。
図5において,診断アプリ20は,CGI-Bに対する 診断リクエスト(a)を作成し,送信する。さら ,そのレスポンス(h)を解析して診断結果をレ ート形式で出力する。診断アプリ20は,CGI-B 事前準備としてCGI-Aを実行することを,自動 に制御することはできない。
拡張機能部40は,起動されると,シナリオテ ーブル43に保持しているシナリオBを実行する 。拡張機能部40は,CGI-Aのリクエストを作成し, 送信する。さらに,CGI-Aのレスポンスを受信し た後,CGI-Bのリクエストを作成し,送信する。 だし,外部,例えば,診断アプリ20からのリクエ ストに応じて,動作させるシナリオを選択す ことはできない。
連携部10は,CGI-Bのリクエスト(b)のレスポ ス(c)を契機に,拡張機能部40の最適なシナリ を動作させ,拡張機能部40が出すリクエスト(f )の作成時に,診断アプリ20からのリクエスト(a )の情報を反映させて,リクエスト(f)をWebアプ サーバ3へ送信する。そして,診断アプリ20の リクエスト(a)に対応したレスポンス(g)を,診 レスポンス(h)として診断アプリ20へ返信する 。
図6を用いて,第2の実施例における連携処 の流れをより詳細に説明する。
ステップS0: 判定ルールDB11には,CGI-A,CGI-B データベース操作を伴うWebアプリであるこ ,WebアプリCGI-Bに対するリクエストのレスポ スに「データベース未登録エラー」がある 合に,シナリオテーブル43のシナリオBを起動 することが,事前に登録されているものとす 。
ステップS1: 診断アプリ20からの診断リク エスト(a)をメッセージ送受信部50の受信部51 受信すると,連携部10の診断リクエスト判定 12が起動される。
ステップS2: 診断リクエスト判定部12は, クエスト(a)がCGI-Bに対する診断リクエストで あるとリクエスト(a)内のURL情報から識別し, 定ルールDB11からCGI-Bがデータベース操作を うWebアプリであることを判断する。
また,シナリオテーブル43内に該当するシ リオがない場合は,リクエスト(a)をそのまま リクエスト(b)として送信部52を通じてWebアプ サーバ3へ送信する(ステップS2″)。
ステップS3: 診断リクエスト判定部12は, クエスト(a)の情報を拡張リクエスト生成部13 へ送信しておく。
ステップS4: 診断リクエスト判定部12は, リクエスト(a)(ここではCGI-B)に対するレスポ スが着たら,診断アプリ20へのレスポンスと て返信する」というルールを判定ルールDB11 へ保存しておく。
ステップS5: 拡張リクエスト生成部13では ,入力された送信情報をもとに,拡張リクエス (b)を生成し,送信部52を通じてWebアプリサー 3へ送信する。
ステップS6: Webアプリサーバ3からのレス ンス(c)を受信部53が受信すると,連携部10の 張レスポンス判定部14が起動される。
ステップS7: 拡張レスポンス判定部は,判 ルールDB11を参照し,レスポンスに対する判 条件の有無を抽出する。ここでは,CGI-Bに対 るリクエストのレスポンスに「データベー 未登録エラー」があることを検出し,判定ル ルにあるように,拡張機能部40の処理実行部4 1に対してシナリオBを実行させる判断をする
ステップS8: 拡張レスポンス判定部14は, ナリオBの実行要求を拡張機能部40の処理実 部41へ渡す。
ステップS9: 拡張機能部40は,CGI-Aに対する メッセージ(DB登録)を生成・送信する。この ッセージ送信時は,連携部10の拡張リクエス 生成部13が呼ばれる。
ステップS10: 拡張リクエスト生成部13で ,入力された送信情報が,リクエスト(a)と同じ Webアプリ(CGI-B)に対するものかを判定する。 力された送信情報がWebアプリ(CGI-B)に対する のでない場合(ここではCGI-A)には,リクエス (a)をそのままリクエスト(d)とし,リクエスト( d)を送信部52を通じてWebアプリサーバ3へ送信 る。
ステップS11: Webアプリサーバ3からのレス ポンス(e)を受信部53が受信すると,連携部10の 張レスポンス判定部14が起動される。
ステップS12: 拡張レスポンス判定部14は, 定ルールDB11を参照し,レスポンスに対する 定条件の有無を抽出する。ここでは,条件無 のため,拡張機能部40の処理実行部41に対し シナリオBを継続実行させることを判断する
ステップS13: 拡張レスポンス判定部14は,C GI-Aのレスポンス(e)を拡張機能部40の処理実行 部41へ渡す。
ステップS14: 拡張機能部40は,シナリオBに したがって,CGI-Bに対するメッセージを生成し ,送信する。このメッセージの送信時には,連 部10の拡張リクエスト生成部13が呼ばれる。
ステップS15: 拡張リクエスト生成部13は, 力された送信情報が,リクエスト(a)と同じWeb アプリ(CGI-B)に対するものかを判定する。入 された送信情報がWebアプリ(CGI-B)に対するも である場合(ここではCGI-B)には,保存してお たリクエスト(a)と置き換えてリクエスト(f) し,リクエスト(f)を送信部52を通じてWebアプ サーバ3へ送信する。
ステップS16: Webアプリサーバ3からのレス ポンス(g)を受信部53が受信すると,連携部10の 張レスポンス判定部14が起動される。
ステップS17: 拡張レスポンス判定部14は, 定ルールDB11を参照し,レスポンス(g)が診断 プリ20への返信対象であること,診断レスポ スの生成が必要なことを判断する。
ステップS18: 拡張レスポンス判定部14は, 断レスポンスの生成が必要な場合には,CGI-B レスポンス(g)を診断レスポンス生成部15へ す。一方,診断レスポンスの生成が必要でな 場合には,レスポンス(g)を診断レスポンス(h) とし,診断レスポンス(h)を送信部54を通じて診 断アプリ20へ送信する(ステップS18″)。
なお,拡張機能部40にレスポンス(g)の受信 果を通知することもある(ステップS18′)。
ステップS19: 診断レスポンス生成部15は, スポンス(g)を診断レスポンス(h)として,送信 部54を通じて診断アプリ20へ送信する。
〔第3の実施例〕
第3の実施例として,Webアプリケーションの
出と記録について協調動作させるための連
動作を説明する。
図7において,診断アプリ20は,CGI-Cに対する リクエストを分析し,Webアプリ(CGI-C)があるこ を記憶する。ただし,同一Webアプリは重複登 録しないものとする。
拡張機能部40は,CGI-Aの後で動くCGI-Cと,CGI-B の後で動くCGI-Cとをそれぞれ別個のWebアプリ して認識し,記憶することができる。
連携部10は,診断アプリ20からのリクエス (b)を受信し,拡張機能部40を起動する。そし ,Webアプリサーバ3からのレスポンス(d)の送信 中継時に,CGI-Bの後で動くCGI-CのCGI名(Webアプリ 名)を「CGI-BC」に変換する。さらに,ユーザPC7 Webブラウザ70からCGI-BCへのリクエストを再 送信させるためのリダイレクトメッセージ 作成し,Webブラウザ70へ返信する。
図8を用いて,第3の実施例における連携処 の流れをより詳細に説明する。
ステップS0: 判定ルールDB11には,「診断シ ナリオ記録時に,拡張機能部40にメッセージを 転送する,リクエストを一時保存する」こと 事前に登録されているものとする。
ステップS1: 診断アプリ20からのリクエス ト(b)をメッセージ送受信部50の受信部51が受 すると,連携部10の診断リクエスト判定部12が 起動される。
ステップS2: 診断リクエスト判定部12は, 断シナリオの記録時であると拡張機能部40の データ管理部42の情報から識別する。
ステップS3: 診断リクエスト判定部12は, 定ルールDB11を参照し,診断シナリオ記録時は 拡張機能部40の処理実行部41へリクエスト(a) 転送することと,リクエスト(a)を一時保存す こととを判断する。
ステップS4: 診断リクエスト判定部12は, クエスト(b)を,拡張機能部40の処理実行部41へ 転送する。
ステップS5: 拡張機能部40は,CGI-Cが含まれ ていることを検出し,記録中のシナリオEにCGI- Cを登録し,リクエスト(a)をWebアプリサーバ3へ 転送する。送信時は,連携部10の拡張リクエス ト生成部13が呼ばれる。
ステップS6: 拡張リクエスト生成部13では ,入力された送信情報をもとに,拡張リクエス (b)を生成して,送信部52を通じてWebアプリサ バ3へ送信する。
ステップS7: Webアプリサーバ3からのレス ンス(d)を受信部53が受信すると,連携部10の 張レスポンス判定部14が起動される。
ステップS8: 拡張レスポンス判定部14は, 定ルールDB11を参照し,レスポンスに対する判 定条件の有無を抽出する。ここでは,診断シ リオ記録時は拡張機能部40の処理実行部41へ スポンスを転送することを判断する。
ステップS9: 拡張レスポンス判定部14は, スポンス(d)を拡張機能部40の処理実行部41へ す。
ステップS10: 拡張機能部40は,シナリオEに 関する情報を登録後,Webアプリ診断サーバ2へ スポンス(d)を送信しようとする。この送信 は,連携部10の診断レスポンス生成部15が呼 れる。
ステップS11: 診断レスポンス生成部15は, 張機能部40のデータ管理部42を通じ,CGI-Cがシ ナリオDで登録済みであることを認識すると,C GI-Cの名前をCGI-BCに変更し,レスポンス(d)を一 保存する。
ステップS12: 診断レスポンス生成部15は, 診断時にCGI-BCへの診断メッセージを受信し 場合に,シナリオEを起動し,CGI名をCGI-BCからC GI-Cへ変更する」ことを判定ルールDB11へ追記 る。
ステップS13: 診断レスポンス生成部15は, 断リクエスト判定部12が一時保存していたCG I-Cに対するリクエスト(b)の情報を入手し,CGI をCGI-BCに変更した以外は同じ内容のリクエ トを,Webブラウザ70に送信させるためのリダ レクト(e)を生成する。
ステップS14: 診断レスポンス生成部15は, ダイレクト(e)を送信部54を通じて,診断アプ 20へ送信する。なお,診断アプリ20は,リダイ クト(e)をリダイレクト(f)としてWebブラウザ7 0へ転送する。
ステップS15: 診断アプリ20は,リダイレク (e)に応じたWebアプリ(CGI-BC)への診断リクエ ト(g)をユーザPC7から受信し,CGI-BCを記憶する ともに,診断リクエスト(h)をシナリオ制御サ ーバ6へ転送する。診断アプリ20からのリクエ スト(h)を受信部51が受信すると,連携部10の診 リクエスト判定部12が起動される。
ステップS16: 診断リクエスト判定部12は, 断シナリオの記録時であると,拡張機能部40 データ管理部の情報から識別する。
ステップS17: 診断リクエスト判定部12は, 定ルールDB11を参照し,リクエスト(h)に含ま るCGI-BCが,CGI名を変更して登録済みであるこ を判断する。
ステップS18: 診断リクエスト判定部12は, クエスト(h)を破棄し,CGI-BCのレスポンスを返 信するために,診断レスポンス生成部15を起動 する。
ステップS19: 診断レスポンス生成部15は, 時保存していたレスポンス(d)の情報を元に, CGI-CをCGI-BCに変更したレスポンス(i)を,送信部 54を通じて診断アプリ20へ送信する。診断ア リ20は,レスポンス(i)を診断レスポンス(j)と て,ユーザPC7のWebブラウザ70へ送信する。
従来のWebアプリ診断アプリケーションで ,シナリオを無視した診断リクエストに対し てはエラーが返信されることが多かった。し かし,第1の実施例および第2の実施例に示すよ うに,本発明によれば,拡張機能部40と連携す ことによって,診断アプリ20がシナリオを無 した診断リクエストを発行しても,有効な診 レスポンスを返信することができる。よっ ,既存のWebアプリ診断アプリケーションの診 断能力を向上させることができる。
また,従来のWebアプリ診断アプリケーショ ンでは,異なる状態遷移がある同一のWebアプ を重複して登録することができなかった。 かし,第3の実施例に示すように,本発明によ ば,重複によって診断対象とならなかったWeb プリへの診断リクエストに対して,CGI名を変 換して別個のWebアプリとして登録することが できるため,基本機能のみの診断アプリ20に対 しても有効な診断リクエスト・レスポンスを 送受信させることができる。よって,既存のWe bアプリ診断アプリケーションの診断能力を 上させることができる。
Next Patent: TRANSMISSION DEVICE, TRANSMISSION METHOD, AND TRANSMISSION DEVICE CONTROL PROGRAM