JP5347429B2 - ユニフォームリソースロケータ書換方法及び装置 - Google Patents

Description

本発明は、アプリケーションサーバ装置（アプリケーションサーバ）から取得した情報に含まれるユニフォームリソースロケータ（ＵＲＬ）情報を書き換える方法及び装置に関する。

クライアント端末からのリクエストに対するＷｅｂアプリケーションサーバ装置（Ｗｅｂアプリケーションサーバ）のレスポンス画面には、他のＷｅｂアプリケーションサーバへのサービス要求が必要となる連携スクリプトが含まれる場合がある。例えば、店舗検索サービスにおいて、Ｗｅｂブラウザが第１のアプリケーションサーバから検索結果画面を受信し、その画面に含まれる連携スクリプトが実行され、地図情報サービスを提供する第２のアプリケーションサーバへのサービス要求が行われるような場合である。

また、図１７に示すように、クライアント端末１１におけるアプリケーションサーバ２１のフォーム入力処理において、アプリケーションサーバ２２のデータを使用したい場合もある。この場合、フォーム入力画面に含まれる連携スクリプト２３が実行され、アプリケーションサーバ２２のデータがフォームに自動的に入力される。

このような場合、２つのアプリケーションサーバのＵＲＬドメインが異なると、Ｗｅｂブラウザのsame-origin policyにより、別のアプリケーションサーバへのサービス要求が制限されてしまう。same-origin policyとは、ユーザが閲覧しようとしているＷｅｂサイトと同じサイトから送信される情報は信用できる、という考え方である。この考え方によってアクセス制限を行うことで、サイトＡを見ようとしたらサイトＢのスクリプトが実行された、ということが原則的に起こらないように制御することができる。

図１７の例では、アプリケーションサーバ２１及び２２のページのＵＲＬは、それぞれ“http://app1.com/app1.html”及び“http://app2.com/app2.html”である。この場合、アプリケーションサーバのドメインが異なるため、Ｗｅｂブラウザからアプリケーションサーバ２２にリクエストを発行することができない。このように、same-origin policyはアプリケーションサーバ間の連携処理に必要以上の制限を与えるため、この制限を回避したい場合がある。

この問題を解決するために、図１８に示すように、クライアント端末１１とアプリケーションサーバ２１及び２２の間に中継サーバ装置（中継サーバ）３１を設けて、中継サーバ３１を経由したリクエストをクライアント端末１１に指定させる方法が考えられる。

この方法では、ユーザがアプリケーションサーバ２１にアクセスする場合、本来のＵＲＬの代わりに、例えば、“http://company.com?path=app1.com/app1.html”というＵＲＬをアドレスバーに入力する。また、アプリケーションサーバ２２にアクセスする場合、本来のＵＲＬの代わりに、例えば、“http://company.com?path=app2.com/app2.html”というＵＲＬをアドレスバーに入力する。

この方法を用いると、Ｗｅｂブラウザからはあたかも中継サーバ３１のみにアクセスしているように見えるので、same-origin policyを満足することができる。
中継サーバがアプリケーションサーバから受信したHyperText Markup Language （ＨＴＭＬ）ファイルに含まれるＵＲＬを中継サーバのＵＲＬに書き換える方法も知られている（例えば、特許文献１を参照）。
特開２００６−０１８７９５号公報

しかしながら、上述した従来のアプリケーションサーバ連携処理には、次のような問題がある。
図１８に示した方法では、クライアント端末１１のユーザは、本来のアプリケーションサーバ２１及び２２ではなく、中継サーバ３１を経由してアプリケーションサーバ２１及び２２にアクセスするためのＵＲＬを指定する必要がある。したがって、ユーザはリクエストの度に中継サーバを意識しながらＵＲＬを指定する必要があり、実用的ではない。

本発明の課題は、ユーザに中継サーバを意識させることなく、Ｗｅｂブラウザのsame-origin policyによる制限を回避するようなアプリケーションサーバ連携処理を実現することである。

サーバ装置によるユニフォームリソースロケータ書換方法は、リクエスト受信ステップ、記録ステップ、リクエスト送信ステップ、レスポンス受信ステップ、書換ステップ、及びレスポンス送信ステップを備える。

リクエスト受信ステップは、クライアント端末から第１のアプリケーションサーバ装置に対するリクエストを受信する。記録ステップは、そのリクエストにより指定される、第１のアプリケーションサーバ装置のユニフォームリソースロケータ情報内の第１のドメイン情報を記録する。リクエスト送信ステップは、第１のアプリケーションサーバ装置にリクエストを送信する。

レスポンス受信ステップは、第１のアプリケーションサーバ装置からリクエストに対するレスポンスを受信する。書換ステップは、そのレスポンスに含まれる、第２のアプリケーションサーバ装置のユニフォームリソースロケータ情報内の第２のドメイン情報を第１のドメイン情報に変更することで、第２のアプリケーションサーバ装置のユニフォームリソースロケータ情報をダミーのユニフォームリソースロケータ情報に書き換える。レスポンス送信ステップは、ダミーのユニフォームリソースロケータ情報を含むレスポンスをクライアント端末に送信する。

このようなユニフォームリソースロケータ書換方法によれば、第１のアプリケーションサーバ装置からのレスポンスに含まれる第２のアプリケーションサーバ装置のドメイン情報が第１のアプリケーションサーバ装置のドメイン情報に変更される。したがって、レスポンスを受信したクライアント端末は、書き換えられたユニフォームリソースロケータ情報に基づきＷｅｂブラウザのsame-origin policyを満足しつつ、第２のアプリケーションサーバ装置に対するリクエストを発行することが可能になる。

ユニフォームリソースロケータ書換方法は、さらに下記のリクエスト受信ステップ、復元ステップ、及び復元後リクエスト送信ステップを備えることもできる。
リクエスト受信ステップは、クライアント端末からダミーのユニフォームリソースロケータ情報を指定するリクエストを受信する。復元ステップは、ダミーのユニフォームリソースロケータ情報から第２のアプリケーションサーバ装置のユニフォームリソースロケータ情報を復元する。復元後リクエスト送信ステップは、復元されたユニフォームリソースロケータ情報を指定するリクエストを第２のアプリケーションサーバ装置に送信する。

ユーザは中継サーバを意識した特別なＵＲＬを指定する必要がなく、クライアント端末からはダミーのＵＲＬしか見えないため、Ｗｅｂブラウザのsame-origin policyによる制限を回避することができる。

以下、図面を参照しながら、最良の実施形態を詳細に説明する。
図１は、実施形態のアプリケーションサーバ間連携処理の例を示している。この例では、クライアント端末１０１とアプリケーションサーバ１１１及び１１２の間に設けられた既存のプロキシサーバ装置（プロキシサーバ）１０２を用いて、ＵＲＬの書き換えを行う。既存のプロキシサーバを用いることで実用性が向上する。

クライアント端末１０１上のＷｅｂブラウザからアプリケーションサーバ１１１に対するリクエストが送信されると、プロキシサーバ１０２は、そのリクエストをアプリケーションサーバ１１１に転送する。そして、リクエストに対するレスポンスがアプリケーションサーバ１１１からプロキシサーバ１０２に送信される。プロキシサーバ１０２は、レスポンスに含まれるＨＴＭＬファイルや連携スクリプト１１３内のＵＲＬを書き換えて、クライアント端末１０１に転送する。

連携スクリプト１１３には、例えば、アプリケーションサーバ１１２のページを取得する以下のような処理が記述されている。

var req = new XMLHttpRequest();
req.open("GET", "http://app2.com/app2.html", false);
req.send(null);

この場合、プロキシサーバ１０２は、連携スクリプト１１３のreq.open("GET", "http://app2.com/app2.html", false);をreq.open("GET", "http://app1.com?path=app2.com/app2.html", false);に書き換えて、クライアント端末１０１に転送する。

その後、Ｗｅｂブラウザから連携スクリプト１１３に記述された、GET http://app1.com?path=app2.com/app2.htmlというリクエストが送信される。このとき、プロキシサーバ１０２は、GET http://app1.com?path=app2.com/app2.htmlからhttp://app2.com/app2.htmlを復元し、復元されたＵＲＬを指定するGET http://app2.com/app2.htmlをアプリケーションサーバ１１２に転送する。

このようなＵＲＬ書換方法によれば、プロキシサーバ１０２からのリクエストは連携先アプリケーションサーバ１１２に対して送信されているのにもかかわらず、Ｗｅｂブラウザからはあたかも連携要求元アプリケーションサーバ１１１へリクエストを送信しているように見える。これにより、Ｗｅｂブラウザは必要に応じてsame-origin policyによる制限を回避し、連携スクリプト１１３から連携先アプリケーションサーバ１１２のデータを利用できるようになる。

図２は、図１のプロキシサーバ１０２の構成例を示している。このプロキシサーバ１０２は、リクエスト受付部２２１、ＵＲＬ復元部２２２、安全サイト判定部２２３、安全ＵＲＬデータベース（ＤＢ）２２４、安全ＵＲＬ登録部２２５、Ｗｅｂクライアント部２２６、ＵＲＬ履歴ＤＢ２２７、レスポンス返却部２２８、ＵＲＬ記録部２２９、及びＵＲＬ書換部２３０を備える。

図３は、初回アクセス時のプロキシサーバ１０２による連携処理の例を示している。初回アクセス時の手順は以下の通りである。
（１）クライアント端末１０１のユーザは、図４に示すように、Ｗｅｂブラウザ２１１にプロキシサーバ１０２を使用する旨を設定し、図５に示すように、アプリケーションサーバ１１１のＷｅｂページ２３１に対するリクエストを送信する。これにより、Ｗｅｂブラウザ２１１は、GET http://app1.com/a.htmlをプロキシサーバ１０２に送信する。プロキシサーバ１０２のリクエスト受付部２２１は、リクエストを受信し、ＵＲＬ復元部２２２に転送する。

また、リクエスト受付部２２１は、受信したリクエストをメモリ等の記憶部に記録しておく。リクエストを記録する代わりに、リクエストにより指定される、アプリケーションサーバ１１１のＵＲＬを記録してもよく、そのＵＲＬ中のドメイン情報を記録してもよい。記録された情報は、以降の処理でＵＲＬ書換部２３０により参照される。

（２）ＵＲＬ復元部２２２は、リクエストにより指定されたＵＲＬをチェックし、リクエストをＷｅｂクライアント部２２６に転送する。

（３）Ｗｅｂクライアント部２２６は、リクエストをアプリケーションサーバ１１１に送信し、リソースを含むレスポンスを受信してＵＲＬ書換部２３０に転送する。この例では、Ｗｅｂページ２３１のＨＴＭＬファイルと連携スクリプト１１３が、リソースとしてレスポンスに含まれる。

（４）ＵＲＬ書換部２３０は、レスポンスに含まれるＵＲＬを抽出し、そのドメイン情報をリソースが属するアプリケーションサーバ１１１のドメイン情報に変更することで、抽出したＵＲＬをダミーのＵＲＬに書き換える。
このとき、連携要求元アプリケーションサーバ１１１以外のサーバへのリクエスト送信処理を記述したソースコード中のＵＲＬと、ＨＴＭＬファイル内のｉｆｒａｍｅのｓｒｃ属性に記述されている他のドメインのＵＲＬが書き換え対象として抽出される。そして、そのＵＲＬのドメイン情報が、上記（１）で記録されたアプリケーションサーバ１１１のドメイン情報に変更され、変更されたドメイン情報に続いて、元のドメイン情報以降のアドレスがクエリとして付加される。
上述した例では、連携スクリプト１１３に記述された、アプリケーションサーバ１１２のＷｅｂページ２３２のＵＲＬとしてhttp://app2.com/app2.htmlが抽出され、http://app1.com?path=app2.com/app2.htmlに書き換えられる。“?path=app2.com/app2.html”はクエリに対応する。
ＵＲＬ書換部２３０は、レスポンスから抽出されたＵＲＬと、ダミーのＵＲＬを含むレスポンスとをＵＲＬ記録部２２９に転送する。

（５）ＵＲＬ記録部２２９は、アプリケーションサーバ１１１のドメイン情報であるapp1.comと、レスポンスから抽出されたＵＲＬのドメイン情報の組を、ＵＲＬ履歴ＤＢ２２７に記録する。そして、ダミーのＵＲＬを含むレスポンスをレスポンス返却部２２８に転送する。上述した例では、app1.comとapp2.comの組がＵＲＬ履歴ＤＢ２２７に記録される。
（６）レスポンス返却部２２８は、レスポンスをＷｅｂブラウザ２１１に送信する。
（７）Ｗｅｂブラウザ２１１は、レスポンスに含まれる書き換え後の連携スクリプトを実行する。

図６は、連携スクリプト実行時のプロキシサーバ１０２による連携処理の例を示している。連携スクリプト実行時の手順は以下の通りである。
（１）Ｗｅｂブラウザ２１１は、書き換え後の連携スクリプトに記述された、アプリケーションサーバ１１２のＷｅｂページ２３２に対するリクエストの送信処理を行う。

（２）Ｗｅｂブラウザ２１１は、Ｗｅｂページ２３２に対するリクエストとしてGET http://app1.com?path=app2.com/app2.htmlをプロキシサーバ１０２に送信する。プロキシサーバ１０２のリクエスト受付部２２１は、リクエストを受信し、ＵＲＬ復元部２２２に転送する。

（３）ＵＲＬ復元部２２２は、リクエストにより指定されたＵＲＬをチェックし、ダミーのＵＲＬからＷｅｂページ２３２のＵＲＬを復元する。そして、リクエストと復元されたＵＲＬとを安全サイト判定部２２３に転送する。

（４）安全サイト判定部２２３は、復元されたＵＲＬに対してリクエストを送信してもよいかどうかを判定する。まず、リクエストにより指定されたＵＲＬのドメイン情報と復元されたＵＲＬのドメイン情報の組が、ＵＲＬ履歴ＤＢ２２７に記録されているか否かをチェックする。
それらのドメイン情報の組が記録されていれば、さらに、安全ＵＲＬＤＢ２２４を参照して、復元されたＵＲＬが安全であるか否かを判定する。プロキシサーバ１０２のオペレータ２０１は、Ｗｅｂページ２３１のアプリケーション作成者等により信頼できると判断された１つ以上のサイトのＵＲＬを、あらかじめ安全ＵＲＬ登録部２２５を介して安全ＵＲＬＤＢ２２４に登録しておく。安全サイト判定部２２３は、復元されたＵＲＬが安全ＵＲＬＤＢ２２４に登録されているいずれかのＵＲＬと一致すれば、そのＵＲＬを安全と判定し、復元されたＵＲＬを指定するリクエストをＷｅｂクライアント部２２６に転送する。

（５）Ｗｅｂクライアント部２２６は、リクエストをアプリケーションサーバ１１２に送信し、レスポンスを受信してＵＲＬ書換部２３０に転送する。この例では、Ｗｅｂページ２３２のＨＴＭＬファイルがレスポンスに含まれる。
（６）ＵＲＬ書換部２３０は、レスポンスに含まれるＵＲＬを抽出し、初回アクセス時と同様に、抽出したＵＲＬをダミーのＵＲＬに書き換える。そして、レスポンスから抽出されたＵＲＬと、ダミーのＵＲＬを含むレスポンスとをＵＲＬ記録部２２９に転送する。

（７）ＵＲＬ記録部２２９は、アプリケーションサーバ１１１のドメイン情報であるapp1.comと、レスポンスから抽出されたＵＲＬのドメイン情報の対応関係を、ＵＲＬ履歴ＤＢ２２７に記録する。そして、ダミーのＵＲＬを含むレスポンスをレスポンス返却部２２８に転送する。
（８）レスポンス返却部２２８は、レスポンスをＷｅｂブラウザ２１１に送信する。
（９）Ｗｅｂブラウザ２１１は、レスポンスに含まれるＨＴＭＬファイルのデータを用いて、連携スクリプト１１３に記述されたデータ処理を行う。

図７は、図２のプロキシサーバ１０２による連携処理のフローチャートである。まず、リクエスト受付部２２１は、リクエストを受信し、そのリクエストの情報を記録する（ステップ７０１）。次に、ＵＲＬ復元部２２２は、リクエストからＵＲＬを抽出して（ステップ７０２）、そのＵＲＬに所定の文字列が含まれているか否かをチェックする（ステップ７０３）。上述した例では、http://app1.com?path=app2.com/app2.htmlに含まれる“?path=”が所定の文字列に対応する。

ＵＲＬに所定の文字列が含まれていなければ、ＵＲＬ復元部２２２は、リクエストをＷｅｂクライアント部２２６に転送する。そして、Ｗｅｂクライアント部２２６は、リクエストをアプリケーションサーバ１１１に送信し（ステップ７０９）、レスポンスを受信する（ステップ７１０）。

次に、ＵＲＬ書換部２３０は、レスポンスからＵＲＬを抽出し（ステップ７１１）、ステップ７０１で記録された情報を用いてダミーのＵＲＬに書き換える（ステップ７１２）。ＵＲＬ記録部２２９は、アプリケーションサーバ１１１のドメイン情報と、レスポンスから抽出されたＵＲＬのドメイン情報の組を、ＵＲＬ履歴ＤＢ２２７に記録する。そして、レスポンス返却部２２８は、レスポンスをＷｅｂブラウザ２１１に送信する。

ステップ７０３においてＵＲＬに所定の文字列が含まれていれば、ＵＲＬ復元部２２２
は、そのＵＲＬはダミーのＵＲＬであると判断する。そして、ダミーのＵＲＬからＷｅｂページ２３２のＵＲＬを復元し、リクエストと復元されたＵＲＬとを安全サイト判定部２２３に転送する（ステップ７０４）。

次に、安全サイト判定部２２３は、ＵＲＬ履歴ＤＢ２２７を参照して（ステップ７０５）、リクエストにより指定されたＵＲＬのドメイン情報と復元されたＵＲＬのドメイン情報の組が登録されているか否かをチェックする（ステップ７０６）。

それらのドメイン情報の組が登録されていれば、次に、安全ＵＲＬＤＢ２２４を参照して（ステップ７０７）、復元されたＵＲＬが安全であるか否かを判定する（ステップ７０８）。そして、復元されたＵＲＬが安全であれば、復元されたＵＲＬを指定するリクエストをＷｅｂクライアント部２２６に転送する。その後、ステップ７０９以降の処理が行われる。

ステップ７０６においてドメイン情報の組が登録されていない場合、又はステップ７０８において復元されたＵＲＬが安全でない場合は、安全サイト判定部２２３はそのまま処理を終了する。したがって、復元されたＵＲＬを指定するリクエストは送信されない。

このような連携処理によれば、復元されたＵＲＬがＵＲＬ履歴に残っていなければリクエストは送信されないので、偽造リクエストによる不正アクセスが防止される。また、アプリケーション作成者等により信頼できると判断された、特定のＵＲＬに対してのみsame-origin policyによる制限が回避されるので、信頼できないサイトへのアクセスが防止される。

なお、安全ＵＲＬＤＢ２２４には、信頼できるサイトのＵＲＬの代わりに、同一のアプリケーション作成者により作成されたＵＲＬのリストを登録しておいてもよい。この場合、安全サイト判定部２２３は、復元されたＵＲＬとＷｅｂページ２３１のＵＲＬが同一のリストに記録されていれば、復元されたＵＲＬを安全と判定する。

図２の構成では、書き換え後のダミーのＵＲＬに元のドメイン情報が含まれているが、元のドメイン情報を含まないＵＲＬに書き換えることも可能である。図８は、このようなプロキシサーバ１０２の構成例を示している。このプロキシサーバ１０２は、図２の構成にＵＲＬ変換ＤＢ８０１を追加した構成を有する。ＵＲＬ変換ＤＢ８０１には、図９に示すように、識別子（ＩＤ）、書き換え前のドメイン情報、及び書き換え後のドメイン情報の組が登録される。

図８のプロキシサーバ１０２による連携処理は、基本的に図７と同様である。ただし、ＵＲＬ書換処理及びＵＲＬ復元処理は次のように変更される。
図１０は、図８のプロキシサーバ１０２によるＵＲＬ書換処理のフローチャートである。ＵＲＬ書換部２３０は、Ｗｅｂクライアント部２２６からレスポンスを受け取ると（ステップ１００１）、レスポンスからＵＲＬを抽出する（ステップ１００２）。このとき、例えば、サーバへのリクエスト送信処理を記述したソースコード中のＵＲＬと、ＨＴＭＬファイル内のｉｆｒａｍｅのｓｒｃ属性に記述されているＵＲＬが抽出される。

次に、抽出されたＵＲＬのドメイン情報が、記録されている連携要求元アプリケーションサーバ１１１のドメイン情報と一致するか否かをチェックし（ステップ１００３）、それらのドメイン情報が一致すれば、レスポンスをＵＲＬ記録部２２９に転送する。

一方、２つのドメイン情報が一致しなければ、ユニークなＩＤを発行し（ステップ１００４）、抽出されたＵＲＬをダミーのＵＲＬに書き換える（ステップ１００５）。この場合、抽出されたＵＲＬのドメイン情報がアプリケーションサーバ１１１のドメイン情報に変更され、変更されたＵＲＬに続いてクエリが付加される。例えば、このクエリのキーには＿ｉｄ＿が設定され、そのキーの値には発行されたＩＤが設定される。

上述した例では、抽出されたＵＲＬであるhttp://app2.com/app2.htmlがhttp://app1.com/app2.html?_id_=id0001に書き換えられる。“?_id_=id0001”はクエリに対応し、“id0001”は発行されたＩＤに対応する。

次に、ＵＲＬ書換部２３０は、書き換え前及び書き換え後のドメイン情報を発行されたＩＤに対応付けてＵＲＬ変換ＤＢ８０１に登録し（ステップ１００６）、抽出されたＵＲＬと、ダミーのＵＲＬを含むレスポンスとをＵＲＬ記録部２２９に転送する。

図１１は、図８のプロキシサーバ１０２によるＵＲＬ復元処理のフローチャートである。ＵＲＬ復元部２２２は、リクエスト受付部２２１からリクエストを受け取ると（ステップ１１０１）、リクエストにより指定されるＵＲＬのクエリに＿ｉｄ＿が含まれているか否かをチェックする（ステップ１１０２）。＿ｉｄ＿が含まれていなければ、リクエストを安全サイト判定部２２３に転送する。

一方、ＵＲＬのクエリに＿ｉｄ＿が含まれていれば、ＵＲＬ復元部２２２は、そのＵＲＬはダミーのＵＲＬであると判断する。そして、ＵＲＬ変換ＤＢ８０１を参照して、＿ｉｄ＿の値に対応する書き換え前及び書き換え後のドメイン情報を取得する（ステップ１１０３）。

次に、ダミーのＵＲＬ中の書き換え後のドメイン情報を書き換え前のドメイン情報に変更し、クエリを削除して、書き換え前のＵＲＬを復元する（ステップ１１０４）。上述した例では、ダミーのＵＲＬであるhttp://app1.com/app2.html?_id_=id0001からhttp://app2.com/app2.htmlが復元される。そして、リクエストと復元されたＵＲＬとを安全サイト判定部２２３に転送する。

ところで、アプリケーションサーバ１１１とアプリケーションサーバ１１２の連携処理が行われた後、さらにアプリケーションサーバ１１２と他のアプリケーションサーバの連携処理が行われる場合も考えられる。図１２は、このような場合のプロキシサーバ１０２の構成例を示している。このプロキシサーバ１０２は、図８の構成にＩＤ管理ＤＢ１２０１を追加した構成を有する。

アプリケーションサーバ１１２からのレスポンスには、Ｗｅｂページ２３２のＨＴＭＬファイルとともに連携スクリプト１２１３が含まれ、連携スクリプト１２１３には、アプリケーションサーバ１２１１のＷｅｂページ１２１２のＵＲＬが含まれている。したがって、プロキシサーバ１０２が連携スクリプト１２１３を書き換えてＷｅｂブラウザ２１１に送信し、Ｗｅｂブラウザ２１１が書き換え後の連携スクリプトを実行すると、Ｗｅｂページ１２１２に対するリクエストがプロキシサーバ１０２に送信される。

ＩＤ管理ＤＢ１２０１には、図１３に示すように、ＩＤ、ベースドメイン情報、インターネットプロトコル（ＩＰ）アドレス、及び発行日時の組が登録される。ベースドメイン情報は、連携要求元アプリケーションサーバのドメイン情報を表し、ＩＰアドレスは、リクエスト元クライアント端末のＩＰアドレスを表し、発行日時は、ＩＤの発行日時を表す。

図１２のプロキシサーバ１０２による連携処理は、基本的に図７と同様である。ただし、ＵＲＬ書換処理及びＵＲＬ復元処理は次のように変更される。
図１４は、図１２のプロキシサーバ１０２によるＵＲＬ書換処理のフローチャートである。ＵＲＬ書換部２３０は、Ｗｅｂクライアント部２２６からレスポンスを受け取ると（ステップ１４０１）、レスポンスからＵＲＬを抽出する（ステップ１４０２）。

次に、抽出されたＵＲＬのドメイン情報が、記録されている連携要求元アプリケーションサーバ１１１のドメイン情報と一致するか否かをチェックし（ステップ１４０３）、それらのドメイン情報が一致すれば、レスポンスをＵＲＬ記録部２２９に転送する。

一方、２つのドメイン情報が一致しなければ、ＩＤ管理ＤＢ１２０１を参照して、レスポンスに対応するユニークなＩＤを発行済みか否かをチェックする（ステップ１４０４）。そして、ＩＤを発行済みであれば、抽出されたＵＲＬを既存のＩＤを含むダミーのＵＲＬに書き換える（ステップ１４０７）。

この場合、抽出されたＵＲＬのドメイン情報が既存のＩＤに対応するベースドメイン情報に変更され、その変更されたドメイン情報に続いて２つのクエリが付加される。最初のクエリには元のドメイン情報以降のアドレスが設定され、２番目のクエリには既存のＩＤが設定される。

例えば、連携スクリプト１２１３にreq.open("GET", "http://app3.com/app3.html", false);と記述されていた場合、ＵＲＬとしてhttp://app3.com/app3.htmlが抽出される。そして、ＩＤ＝id0001が発行済みであれば、抽出されたＵＲＬがhttp://app1.com?path=app3.com/app3.html&_id_=id0001に書き換えられる。

次に、ＵＲＬ書換部２３０は、書き換え前及び書き換え後のドメイン情報を既存のＩＤに対応付けてＵＲＬ変換ＤＢ８０１に登録する（ステップ１４０８）。図９のＵＲＬ変換ＤＢには既にid0001に対応するエントリが格納されているが、新たに（ＩＤ，書換前，書換後）＝（id0001，app3.com，app1.com）のエントリが追加される。そして、ＵＲＬ書換部２３０は、抽出されたＵＲＬと、ダミーのＵＲＬを含むレスポンスとをＵＲＬ記録部２２９に転送する。

ステップ１４０４においてＩＤを発行済みでなければ、ユニークなＩＤを発行する（ステップ１４０５）。そして、発行されたＩＤと、連携要求元アプリケーションサーバ１１１のドメイン情報と、リクエスト元のクライアント端末１０１のＩＰアドレスと、現在日時とをＩＤ管理ＤＢ１２０１に登録する（ステップ１４０６）。

次に、抽出されたＵＲＬを発行されたＩＤを含むダミーのＵＲＬに書き換える（ステップ１４０７）。この場合、抽出されたＵＲＬのドメイン情報が連携要求元アプリケーションサーバのドメイン情報に変更され、その変更されたドメイン情報に続いて２つのクエリが付加される。最初のクエリには元のドメイン情報以降のアドレスが設定され、２番目のクエリには発行されたＩＤが設定される。

そして、書き換え前及び書き換え後のドメイン情報を発行されたＩＤに対応付けてＵＲＬ変換ＤＢ８０１に登録し（ステップ１４０８）、抽出されたＵＲＬと、ダミーのＵＲＬを含むレスポンスとをＵＲＬ記録部２２９に転送する。

図１５は、ステップ１４０４におけるＩＤ判定処理のフローチャートである。ＵＲＬ書換部２３０は、まず、レスポンスに対応するリクエスト元のクライアント端末のＩＰアドレスがＩＤ管理ＤＢ１２０１に登録されているか否かをチェックする（ステップ１５０１）。

そのＩＰアドレスが登録されていれば、次に、そのＩＰアドレスのエントリの発行日時が現在日時から一定範囲内か否かをチェックする（ステップ１５０２）。この一定範囲としては、例えば、現在日時から５分前までの範囲が用いられる。

発行日時が一定範囲内であれば、次に、そのエントリのベースドメイン情報が、記録されている連携要求元アプリケーションサーバのドメイン情報と一致するか否かをチェックする（ステップ１５０３）。

ベースドメイン情報が連携要求元アプリケーションサーバのドメイン情報と一致すれば、レスポンスに対応するＩＤは発行済みと判定し、そのエントリのＩＤを発行済みＩＤとして使用する（ステップ１５０４）。

ステップ１５０１においてＩＰアドレスが登録されていない場合、ステップ１５０２において発行日時が一定範囲内でない場合、又はステップ１５０３において２つのドメイン情報が一致しない場合は、ＩＤは未発行と判定する（ステップ１５０５）。

図１２のプロキシサーバ１０２によるＵＲＬ復元処理は、基本的に図１１と同様である。ただし、図１１のステップ１１０３において、ダミーのＵＲＬに含まれるＩＤと同一のＩＤがＵＲＬ変換ＤＢ８０１に複数存在する場合がある。そこで、ＵＲＬ復元部２２２は、ダミーのＵＲＬ中のＩＤに対応する書き換え前及び書き換え後のドメイン情報の組をすべて取得し、ダミーのＵＲＬ中のクエリに記述された書き換え前のドメイン情報と照合する。

クエリに記述された書き換え前のドメイン情報と一致する組があれば、ダミーのＵＲＬ中の書き換え後のドメイン情報を、一致した書き換え前のドメイン情報に変更する。そして、クエリを削除して、書き換え前のＵＲＬを復元する。上述した例では、ダミーのＵＲＬであるhttp://app1.com?path=app3.com/app3.html&_id_=id0001からhttp://app3.com/app3.htmlが復元される。

なお、図２、図８、及び図１２の構成では、安全ＵＲＬＤＢ２２４を参照して復元されたＵＲＬが安全であるか否かを判定しているが、システム設計に応じて安全サイト判定処理を省略しても構わない。

また、ＵＲＬの書き換え方法は上述した例に限られるわけではなく、連携要求元アプリケーションサーバのドメイン情報を特定可能で、かつ、元のＵＲＬを復元可能な方法であれば、他の方法でも構わない。

図２、図８、及び図１２のクライアント端末１０１、中継サーバ１０２、及びアプリケーションサーバ１１１、１１２、及び１２１１は、例えば、図１６に示すような情報処理装置（コンピュータ）を用いて構成される。図１６の情報処理装置は、ＣＰＵ１６０１、メモリ１６０２、入力装置１６０３、出力装置１６０４、外部記憶装置１６０５、媒体駆動装置１６０６、およびネットワーク接続装置１６０７を備え、それらはバス１６０８により互いに接続されている。

メモリ１６０２は、例えば、Read Only Memory（ＲＯＭ）、Random Access Memory（ＲＡＭ）等を含み、処理に用いられるプログラムおよびデータを格納する。ＣＰＵ１６０１は、メモリ１６０２を利用してプログラムを実行することにより、クライアント端末１０１、中継サーバ１０２、又はアプリケーションサーバ１１１、１１２、及び１２１１の処理を行う。

入力装置１６０３は、例えば、キーボード、ポインティングデバイス等であり、オペレータ又はユーザからの指示や情報の入力に用いられる。出力装置１６０４は、例えば、ディスプレイ、プリンタ、スピーカ等であり、オペレータ又はユーザへの問い合わせや処理結果の出力に用いられる。

外部記憶装置１６０５は、例えば、磁気ディスク装置、光ディスク装置、光磁気ディスク装置、テープ装置等である。情報処理装置は、この外部記憶装置１６０５に、プログラムおよびデータを格納しておき、必要に応じて、それらをメモリ１６０２にロードして使用する。外部記憶装置１６０５は、安全ＵＲＬＤＢ２２４、ＵＲＬ履歴ＤＢ２２７、ＵＲＬ変換ＤＢ８０１、及びＩＤ管理ＤＢ１２０１としても使用される。

媒体駆動装置１６０６は、可搬記録媒体１６０９を駆動し、その記録内容にアクセスする。可搬記録媒体１６０９は、メモリカード、フレキシブルディスク、光ディスク、光磁気ディスク等の任意のコンピュータ読み取り可能な記録媒体である。オペレータ又はユーザは、この可搬記録媒体１６０９にプログラムおよびデータを格納しておき、必要に応じて、それらをメモリ１６０２にロードして使用する。

ネットワーク接続装置１６０７は、インターネット等の通信ネットワークに接続され、通信に伴うデータ変換を行う。また、情報処理装置は、必要に応じて、プログラムおよびデータを外部の装置からネットワーク接続装置１６０７を介して受け取り、それらをメモリ１６０２にロードして使用する。

以上、図１から図１６までを参照しながら説明した実施形態に関し、さらに以下の付記を開示する。
（付記１）
サーバ装置によるユニフォームリソースロケータ書換方法であって、
クライアント端末から第１のアプリケーションサーバ装置に対するリクエストを受信するリクエスト受信ステップと、
前記リクエストにより指定される、前記第１のアプリケーションサーバ装置のユニフォームリソースロケータ情報内の第１のドメイン情報を記録する記録ステップと、
前記第１のアプリケーションサーバ装置に前記リクエストを送信するリクエスト送信ステップと、
前記第１のアプリケーションサーバ装置から前記リクエストに対するレスポンスを受信するレスポンス受信ステップと、
前記レスポンスに含まれる、第２のアプリケーションサーバ装置のユニフォームリソースロケータ情報内の第２のドメイン情報を前記第１のドメイン情報に変更することで、該第２のアプリケーションサーバ装置のユニフォームリソースロケータ情報をダミーのユニフォームリソースロケータ情報に書き換える書換ステップと、
前記ダミーのユニフォームリソースロケータ情報を含むレスポンスを前記クライアント端末に送信するレスポンス送信ステップと
を備えることを特徴とするユニフォームリソースロケータ書換方法。
（付記２）
前記クライアント端末から前記ダミーのユニフォームリソースロケータ情報を指定するリクエストを受信するリクエスト受信ステップと、該ダミーのユニフォームリソースロケータ情報から前記第２のアプリケーションサーバ装置のユニフォームリソースロケータ情報を復元する復元ステップと、復元されたユニフォームリソースロケータ情報を指定するリクエストを該第２のアプリケーションサーバ装置に送信する復元後リクエスト送信ステップとをさらに備えることを特徴とする付記１記載のユニフォームリソースロケータ書換方法。
（付記３）
前記書換ステップは、前記第１のドメイン情報に続いて、前記第２のアプリケーションサーバ装置のユニフォームリソースロケータ情報内の第２のドメイン情報以降のアドレス情報をクエリとして付加することで、前記ダミーのユニフォームリソースロケータ情報を生成し、前記復元ステップは、前記クライアント端末から受信したリクエストにより指定されるユニフォームリソースロケータ情報に、該クエリを示す所定の文字列が含まれているか否かをチェックすることで、該ダミーのユニフォームリソースロケータ情報を識別することを特徴とする付記２記載のユニフォームリソースロケータ書換方法。
（付記４）
前記書換ステップは、前記第２のドメイン情報を前記第１のドメイン情報に変更した後のユニフォームリソースロケータ情報に続いて、該第２のドメイン情報の識別子を付加することで、前記ダミーのユニフォームリソースロケータ情報を生成し、該識別子と該第２のドメイン情報を対応付けて記録し、前記復元ステップは、前記クライアント端末から受信したリクエストにより指定されるユニフォームリソースロケータ情報に、該識別子が含まれているか否かをチェックすることで、該ダミーのユニフォームリソースロケータ情報を識別し、該識別子に対応付けて記録された該第２のドメイン情報を用いて前記第２のアプリケーションサーバ装置のユニフォームリソースロケータ情報を復元することを特徴とする付記２記載のユニフォームリソースロケータ書換方法。
（付記５）
前記書換ステップは、前記第１のドメイン情報に続いて、前記第２のアプリケーションサーバ装置のユニフォームリソースロケータ情報内の第２のドメイン情報以降のアドレス情報と該第２のドメイン情報の識別子とをクエリとして付加することで、前記ダミーのユニフォームリソースロケータ情報を生成し、該識別子と該第２のドメイン情報を対応付けて記録し、前記復元ステップは、前記クライアント端末から受信したリクエストにより指定されるユニフォームリソースロケータ情報に、該識別子が含まれているか否かをチェックすることで、該ダミーのユニフォームリソースロケータ情報を識別し、該識別子に対応付けて記録された該第２のドメイン情報を用いて前記第２のアプリケーションサーバ装置のユニフォームリソースロケータ情報を復元することを特徴とする付記２記載のユニフォームリソースロケータ書換方法。
（付記６）
前記復元されたユニフォームリソースロケータ情報があらかじめ登録されたユニフォームリソースロケータ情報に一致すれば、該復元されたユニフォームリソースロケータ情報が示すサイトを安全なサイトと判定する判定ステップをさらに備え、前記復元後リクエスト送信ステップは、該安全なサイトと判定された場合に、前記復元されたユニフォームリソースロケータ情報を指定するリクエストを前記第２のアプリケーションサーバ装置に送信することを特徴とする付記２乃至５のいずれかに記載のユニフォームリソースロケータ書換方法。
（付記７）
クライアント端末から第１のアプリケーションサーバ装置に対するリクエストを受信するリクエスト受信手段と、
前記リクエストにより指定される、前記第１のアプリケーションサーバ装置のユニフォームリソースロケータ情報内の第１のドメイン情報を格納する格納手段と、
前記第１のアプリケーションサーバ装置に前記リクエストを送信するリクエスト送信手段と、
前記第１のアプリケーションサーバ装置から前記リクエストに対するレスポンスを受信するレスポンス受信手段と、
前記レスポンスに含まれる、第２のアプリケーションサーバ装置のユニフォームリソースロケータ情報内の第２のドメイン情報を前記第１のドメイン情報に変更することで、該第２のアプリケーションサーバ装置のユニフォームリソースロケータ情報をダミーのユニフォームリソースロケータ情報に書き換える書換手段と、
前記ダミーのユニフォームリソースロケータ情報を含むレスポンスを前記クライアント
端末に送信するレスポンス送信手段と
を備えることを特徴とするユニフォームリソースロケータ書換装置。

実施形態のアプリケーションサーバ間連携処理を示す図である。 第１のプロキシサーバの構成図である。 初回アクセス時の連携処理を示す図である。 プロキシ設定画面を示す図である。 リクエスト送信画面を示す図である。 連携スクリプト実行時の連携処理を示す図である。 連携処理のフローチャートである。 第２のプロキシサーバの構成図である。 ＵＲＬ変換ＤＢを示す図である。 第１のＵＲＬ書換処理のフローチャートである。 ＵＲＬ復元処理のフローチャートである。 第３のプロキシサーバの構成図である。 ＩＤ管理ＤＢを示す図である。 第２のＵＲＬ書換処理のフローチャートである。 ＩＤ判定処理のフローチャートである。 情報処理装置の構成図である。 従来のアプリケーションサーバ間連携処理を示す図である。 中継サーバを経由するアプリケーションサーバ間連携処理を示す図である。

符号の説明

１１、１０１ クライアント端末
２１、２２、１１１、１１２、１２１１ アプリケーションサーバ
２３、１１３、１２１３ 連携スクリプト
３１ 中継サーバ
１０２ プロキシサーバ
２０１ オペレータ
２１１ Ｗｅｂブラウザ
２２１ リクエスト受付部
２２２ ＵＲＬ復元部
２２３ 安全サイト判定部
２２４ 安全ＵＲＬＤＢ
２２５ 安全ＵＲＬ登録部
２２６ Ｗｅｂクライアント部
２２７ ＵＲＬ履歴ＤＢ
２２８ レスポンス返却部
２２９ ＵＲＬ記録部
２３０ ＵＲＬ書換部
２３１、２３２、１２１２ Ｗｅｂページ
８０１ ＵＲＬ変換ＤＢ
１２０１ ＩＤ管理ＤＢ
１６０１ ＣＰＵ
１６０２ メモリ
１６０３ 入力装置
１６０４ 出力装置
１６０５ 外部記憶装置
１６０６ 媒体駆動装置
１６０７ ネットワーク接続装置
１６０８ バス
１６０９ 可搬記録媒体

Claims (8)

1. サーバ装置によるユニフォームリソースロケータ書換方法であって、
   クライアント端末から第１のアプリケーションサーバ装置に対するリクエストを受信するリクエスト受信ステップと、
   前記リクエストにより指定される、前記第１のアプリケーションサーバ装置のユニフォームリソースロケータ情報内の第１のドメイン情報を記録する記録ステップと、
   前記第１のアプリケーションサーバ装置に前記リクエストを送信するリクエスト送信ステップと、
   前記第１のアプリケーションサーバ装置から前記リクエストに対するレスポンスを受信するレスポンス受信ステップと、
   前記レスポンスに含まれる、第２のアプリケーションサーバ装置のユニフォームリソースロケータ情報内の第２のドメイン情報を前記第１のドメイン情報に変更することで、該第２のアプリケーションサーバ装置のユニフォームリソースロケータ情報をダミーのユニフォームリソースロケータ情報に書き換える書換ステップと、
   前記ダミーのユニフォームリソースロケータ情報を含むレスポンスを前記クライアント端末に送信するレスポンス送信ステップと
   を備えることを特徴とするユニフォームリソースロケータ書換方法。
2. 前記書換ステップは、前記第２のドメイン情報を前記第１のドメイン情報に変更した後のユニフォームリソースロケータ情報に続いて、該第２のドメイン情報の識別子を付加することで、前記ダミーのユニフォームリソースロケータ情報を生成することを特徴とする請求項１記載のユニフォームリソースロケータ書換方法。
3. 前記書換ステップは、前記第１のドメイン情報に続いて、前記第２のアプリケーションサーバ装置のユニフォームリソースロケータ情報内の第２のドメイン情報以降のアドレス情報をクエリとして付加することで、前記ダミーのユニフォームリソースロケータ情報を生成することを特徴とする請求項１記載のユニフォームリソースロケータ書換方法。
4. 前記クライアント端末から前記ダミーのユニフォームリソースロケータ情報を指定するリクエストを受信するリクエスト受信ステップと、該ダミーのユニフォームリソースロケータ情報から前記第２のアプリケーションサーバ装置のユニフォームリソースロケータ情報を復元する復元ステップと、復元されたユニフォームリソースロケータ情報を指定するリクエストを該第２のアプリケーションサーバ装置に送信する復元後リクエスト送信ステップとをさらに備えることを特徴とする請求項１乃至３のいずれか１項に記載のユニフォームリソースロケータ書換方法。
5. 前記復元されたユニフォームリソースロケータ情報があらかじめ登録されたユニフォームリソースロケータ情報に一致すれば、該復元されたユニフォームリソースロケータ情報が示すサイトを安全なサイトと判定する判定ステップをさらに備え、前記復元後リクエスト送信ステップは、該安全なサイトと判定された場合に、前記復元されたユニフォームリソースロケータ情報を指定するリクエストを前記第２のアプリケーションサーバ装置に送信することを特徴とする請求項４記載のユニフォームリソースロケータ書換方法。
6. クライアント端末から第１のアプリケーションサーバ装置に対するリクエストを受信するリクエスト受信手段と、
   前記リクエストにより指定される、前記第１のアプリケーションサーバ装置のユニフォームリソースロケータ情報内の第１のドメイン情報を格納する格納手段と、
   前記第１のアプリケーションサーバ装置に前記リクエストを送信するリクエスト送信手段と、
   前記第１のアプリケーションサーバ装置から前記リクエストに対するレスポンスを受信するレスポンス受信手段と、
   前記レスポンスに含まれる、第２のアプリケーションサーバ装置のユニフォームリソースロケータ情報内の第２のドメイン情報を前記第１のドメイン情報に変更することで、該第２のアプリケーションサーバ装置のユニフォームリソースロケータ情報をダミーのユニフォームリソースロケータ情報に書き換える書換手段と、
   前記ダミーのユニフォームリソースロケータ情報を含むレスポンスを前記クライアント端末に送信するレスポンス送信手段と
   を備えることを特徴とするユニフォームリソースロケータ書換装置。
7. 前記書換手段は、前記第２のドメイン情報を前記第１のドメイン情報に変更した後のユニフォームリソースロケータ情報に続いて、該第２のドメイン情報の識別子を付加することで、前記ダミーのユニフォームリソースロケータ情報を生成することを特徴とする請求項６記載のユニフォームリソースロケータ書換装置。
8. 前記書換手段は、前記第１のドメイン情報に続いて、前記第２のアプリケーションサーバ装置のユニフォームリソースロケータ情報内の第２のドメイン情報以降のアドレス情報をクエリとして付加することで、前記ダミーのユニフォームリソースロケータ情報を生成することを特徴とする請求項６記載のユニフォームリソースロケータ書換装置。