JP5146088B2 - ウェブ情報中継方法及び装置 - Google Patents
ウェブ情報中継方法及び装置 Download PDFInfo
- Publication number
- JP5146088B2 JP5146088B2 JP2008120734A JP2008120734A JP5146088B2 JP 5146088 B2 JP5146088 B2 JP 5146088B2 JP 2008120734 A JP2008120734 A JP 2008120734A JP 2008120734 A JP2008120734 A JP 2008120734A JP 5146088 B2 JP5146088 B2 JP 5146088B2
- Authority
- JP
- Japan
- Prior art keywords
- relay
- host name
- relay server
- extracted
- uniform resource
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
- Y02P20/00—Technologies relating to chemical industry
- Y02P20/50—Improvements relating to the production of bulk chemicals
- Y02P20/52—Improvements relating to the production of bulk chemicals using catalysts, e.g. selective catalysts
Landscapes
- Information Transfer Between Computers (AREA)
Description
本発明は、中継サーバによるマッシュアップサービスのためのウェブ情報中継方法及び装置に関する。
近年、Ｗｅｂ２．０、Software as a Service （ＳａａＳ）等の文脈の中で、Ｗｅｂは「閲覧されるもの」としてのみではなく、「マッシュアップして使われるもの」としての役割を担うようになっている。マッシュアップにより、あるドメインのＷｅｂアプリケーションから他のドメインのＷｅｂアプリケーションのデータを利用することが可能になる。
一般にマッシュアップを行うには、対象となるシステムがマッシュアップを前提にあらかじめ設計・実装されている必要がある。しかし、企業内の巨大なＷｅｂシステム等では、マッシュアップにより大きな効果を生むもものの、そのための改修には莫大な費用がかかり現実的でない。このため、既存のＷｅｂシステムに全く改修を加えずに、Ｗｅｂページをマッシュアップする方法が望まれている。
このような問題の解決に結びつく技術として、他のサイトの内容を機械的に翻訳してユーザに提供する翻訳サイト等のような、コンテンツフィルタという技術がある。コンテンツフィルタ技術によれば、ユーザのブラウザからのアクセスを一旦中継サーバで受け、中継サーバが目的サーバにアクセスし、その内容を取得して翻訳等の加工を加えた上で、ユーザのブラウザに送信する。
この技術を応用し、中継サーバにおいて別のＷｅｂアプリケーションとのマッシュアップを行うコードを挿入し、ブラウザに送信することで、既存アプリに改修を加えなくてもマッシュアップが可能になる。
中継サーバ経由で目的サーバにアクセスするため、ユーザには目的サーバのUniform Resource Locator（ＵＲＬ、ユニフォームリソースロケータ）ではなく、特殊な加工を施したＵＲＬを指定させることになる。ＵＲＬ指定方法としては、Common Gateway Interface（ＣＧＩ）パラメタを使用した方式やパスを使用した方式、Contents Delivery Network （ＣＤＮ）で使われた方式等、いくつかの方式が提案され、実際に運用されている。
ＣＧＩパラメタを使用した方式では、以下の例に示されるように、アクセス対象のＵＲＬがＣＧＩ経由のＵＲＬに変更される。
対象ＵＲＬ http://target.example/contact/services/
ＣＧＩ経由ＵＲＬ
http://relay.example/?url=http://target.example/contact/services/
また、パスを使用した方式では、以下の例に示されるように、アクセス対象のＵＲＬがＣＧＩ経由のＵＲＬに変更される（例えば、特許文献１を参照）。
対象ＵＲＬ http://target.example/contact/services/
ＣＧＩ経由ＵＲＬ http://relay.example/target.example/contact/services/
さらに、ＣＤＮで使われた方式では、以下の例に示されるように、アクセス対象のホス
ト名を書き換えてユーザにアクセスしてもらうことで、ＣＤＮ経由のキャッシュを返す処理を実現している（例えば、非特許文献１を参照）。
対象ＵＲＬ http://target.example/contact/services/
ＣＤＮ経由ＵＲＬ http://target.example.relay.example/contact/services/
特開２００６−０１８７９５号公報
"The Coral Content Distribution Network"、［online］、［平成２０年４月１１日検索］、インターネット＜ＵＲＬ：http://www.coralcdn.org ＞
対象ＵＲＬ http://target.example/contact/services/
ＣＧＩ経由ＵＲＬ
http://relay.example/?url=http://target.example/contact/services/
また、パスを使用した方式では、以下の例に示されるように、アクセス対象のＵＲＬがＣＧＩ経由のＵＲＬに変更される（例えば、特許文献１を参照）。
対象ＵＲＬ http://target.example/contact/services/
ＣＧＩ経由ＵＲＬ http://relay.example/target.example/contact/services/
さらに、ＣＤＮで使われた方式では、以下の例に示されるように、アクセス対象のホス
ト名を書き換えてユーザにアクセスしてもらうことで、ＣＤＮ経由のキャッシュを返す処理を実現している（例えば、非特許文献１を参照）。
対象ＵＲＬ http://target.example/contact/services/
ＣＤＮ経由ＵＲＬ http://target.example.relay.example/contact/services/
上述した従来の中継方法には、次のような問題がある。
Ｗｅｂシステム、特に企業内のＷｅｂシステムにおいてはセキュリティの確保が重要な課題となっているが、従来のコンテンツフィルタ技術を用いて中継サーバを利用した場合、このセキュリティの確保ができないという問題がある。具体的には、以下の通りである。
（１）ＣＧＩパラメタを使用した方式及びパスを使用した方式では、ＵＲＬがすべてrelay.example という同一ドメインに属するパスになってしまうため、ブラウザに備わっているsame origin policyというセキュリティのための機構が働かなくなってしまう。
Ｗｅｂシステム、特に企業内のＷｅｂシステムにおいてはセキュリティの確保が重要な課題となっているが、従来のコンテンツフィルタ技術を用いて中継サーバを利用した場合、このセキュリティの確保ができないという問題がある。具体的には、以下の通りである。
（１）ＣＧＩパラメタを使用した方式及びパスを使用した方式では、ＵＲＬがすべてrelay.example という同一ドメインに属するパスになってしまうため、ブラウザに備わっているsame origin policyというセキュリティのための機構が働かなくなってしまう。
つまり、中継サーバを経由してあるサイトＡのページを閲覧中に、別のサイトＢにアクセスした場合、ブラウザからはどちらのサイトもrelay.example というドメインに属するページだと認識されてしまう。このため、サイトＡのページに悪意のあるスクリプトが記述されていると、サイトＢとやり取りした情報がサイトＡに盗まれてしまう危険性があり、システム間連携においては重要な問題となる。
（２）ＣＤＮで使われた方式では、中継サーバを経由しても、別々のホストが同一ドメインと認識されることはないため、上記（１）のような問題は生じない。しかしながら、現在Ｗｅｂシステムを用いる上で重要なセキュリティ技術であるHypertext Transfer Protocol Security（ＨＴＴＰＳ）を用いる場合、ＣＤＮで使われた方式では問題がある。
（２）ＣＤＮで使われた方式では、中継サーバを経由しても、別々のホストが同一ドメインと認識されることはないため、上記（１）のような問題は生じない。しかしながら、現在Ｗｅｂシステムを用いる上で重要なセキュリティ技術であるHypertext Transfer Protocol Security（ＨＴＴＰＳ）を用いる場合、ＣＤＮで使われた方式では問題がある。
ＨＴＴＰＳ仕様においては、１つのInternet Protocol （ＩＰ）アドレスに対して１つのSecure Socket Layer （ＳＳＬ）証明書しか対応させることができないため、relay.exampleサーバがＳＳＬ証明書を取得したとしても、それはrelay.exampleというドメインのみで有効である。つまり、target.example.relay.example というアドレスに対してはサーバの正当性を証明することができない。
ワイルドカードＳＳＬ証明書という方法も存在するが、例えば、*.relay.exampleというアドレスの証明書はrelay.exampleの上の１階層分しか有効でない。このため、example.relay.exampleに対しては正当性を証明できても、target.example.relay.example に対しては証明することができない。したがって、ユーザに対して、正当性を確認できない状態で中継サーバを利用させることになり、セキュリティ上の大きな不安要素となる。
このように、従来の中継方法では、上記（１）及び（２）の問題を同時に解決することができない。same origin policyによるセキュリティの確保及びＨＴＴＰＳによる通信のセキュリティの確保は、Ｗｅｂシステムを用いる上で必須の要件であり、既存のＷｅｂシステムにおけるマッシュアップ実現のために、この２つの要件を同時に満足させる中継方法が求められている。
本発明の課題は、中継サーバによるマッシュアップサービスにおいて、same origin po
licyによるセキュリティ及びＨＴＴＰＳによるセキュリティを両立させることである。
licyによるセキュリティ及びＨＴＴＰＳによるセキュリティを両立させることである。
開示の中継サーバによるウェブ情報中継方法は、受信ステップ、編集ステップ、及び送信ステップを含む。
受信ステップは、クライアントからのリクエストを受信する。編集ステップは、受信したリクエストに対応するウェブページを編集する際に、マッシュアップ対象のページに記述されたユニフォームリソースロケータ情報を抽出し、抽出されたユニフォームリソースロケータ情報のホスト名のドットを別の文字に置換するとともに、中継サーバのホスト名を付加する。送信ステップは、編集後のウェブページをクライアントへ送信する。
受信ステップは、クライアントからのリクエストを受信する。編集ステップは、受信したリクエストに対応するウェブページを編集する際に、マッシュアップ対象のページに記述されたユニフォームリソースロケータ情報を抽出し、抽出されたユニフォームリソースロケータ情報のホスト名のドットを別の文字に置換するとともに、中継サーバのホスト名を付加する。送信ステップは、編集後のウェブページをクライアントへ送信する。
このようなウェブ情報中継方法によれば、マッシュアップ対象のページに記述されたＵＲＬ情報からＷｅｂサイト毎に異なるホスト名が生成されるため、same origin policyによるセキュリティが確保される。また、ホスト名のドットを別の文字に置換することにより、中継サーバのホスト名より前の部分が１階層分の文字列に編集されるため、上述したワイルドカードＳＳＬ証明書を用いることが可能になる。
中継サーバによるマッシュアップサービスにおいて、same origin policyによるセキュリティ及びＨＴＴＰＳによるセキュリティを両立させることができる。
以下、図面を参照しながら、本発明を実施するための最良の形態を詳細に説明する。
図１は、実施形態の中継システムの構成例を示している。この中継システムは、クライアント１０１、中継サーバ１０２、及び目的サーバ１０４〜１０６を備える。これらの装置は、インターネットのような通信ネットワークを介して互いに通信することができる。
図１は、実施形態の中継システムの構成例を示している。この中継システムは、クライアント１０１、中継サーバ１０２、及び目的サーバ１０４〜１０６を備える。これらの装置は、インターネットのような通信ネットワークを介して互いに通信することができる。
この中継システムでは、目的サーバ１０４が提供するサービスを目的サーバ１０５や目的サーバ１０６が提供するサービスとつなげて利用するため、ユーザはクライアント１０１から中継サーバ１０２を介して各目的サーバにアクセスする。そして、もともと他のシステムと連携できるように設計されていない各目的サーバの入出力を、中継サーバ１０２で加工して連携可能な入出力に置き換えることにより、システム間連携が実現される。
例えば、relay.example というドメインで中継サーバ１０２を運用する場合、ＷｅｂサイトのＵＲＬのFully Qualified Domain Name （ＦＱＤＮ、完全修飾ドメイン名）部分を、以下のように書き換える。
（ｅｘ１）
http://target.example/
→http(s)://http-target-example.relay.example/
（ｅｘ２）
https://target.number2.example/path/
→http(s)://https-target-number2-example.relay.example/path/
（ｅｘ３）
http://with-hyphen.example/
→http(s)://http-with--hyphen-example.relay.example/
（ｅｘ４）
http://with.port.example:8080/
→http(s)://http-with-port-example--8080.relay.example/
ｅｘ１〜ｅｘ４では、ＦＱＤＮの“. ”（ドット）が“- ”（ハイフン）に置換されるとともに、中継サーバ１０２のホスト名relay.exampleが付加されている。さらに、ｅｘ３では、ＦＱＤＮのハイフンがハイフン２つに置換されており、ｅｘ４では、ＦＱＤＮのポート番号8080が取り出され、http-with-port-exampleの後ろにハイフン２つで連結されている。これにより、元ＵＲＬのＦＱＤＮが書き換え後のＵＲＬのホスト名にエンコードされる。
（ｅｘ１）
http://target.example/
→http(s)://http-target-example.relay.example/
（ｅｘ２）
https://target.number2.example/path/
→http(s)://https-target-number2-example.relay.example/path/
（ｅｘ３）
http://with-hyphen.example/
→http(s)://http-with--hyphen-example.relay.example/
（ｅｘ４）
http://with.port.example:8080/
→http(s)://http-with-port-example--8080.relay.example/
ｅｘ１〜ｅｘ４では、ＦＱＤＮの“. ”（ドット）が“- ”（ハイフン）に置換されるとともに、中継サーバ１０２のホスト名relay.exampleが付加されている。さらに、ｅｘ３では、ＦＱＤＮのハイフンがハイフン２つに置換されており、ｅｘ４では、ＦＱＤＮのポート番号8080が取り出され、http-with-port-exampleの後ろにハイフン２つで連結されている。これにより、元ＵＲＬのＦＱＤＮが書き換え後のＵＲＬのホスト名にエンコードされる。
このような書き換え後のＵＲＬを用いることで、クライアント１０１から中継サーバ１０２を介してＷｅｂサイトにアクセスすることが可能になる。中継サーバ１０２は、そのＷｅｂサイトからレスポンスを加工して、クライアント１０１に返送する。このとき、テキスト置換により以下の変換も併せて行われる。
１．httpから始まる絶対パス記述を上記書き換えルールに従って変換する。
２．すでに上記書き換えルールに従っているパスは変換しない。
１．httpから始まる絶対パス記述を上記書き換えルールに従って変換する。
２．すでに上記書き換えルールに従っているパスは変換しない。
この中継方法の特長は以下の通りである。
１．システム間連携に必要な以下の２点のセキュリティを両立させることができる。
（１）ワイルドカードＳＳＬ証明書を利用することで、中継サーバのサーバ認証が可能 になる。上記のｅｘ１〜ｅｘ４では、Common Name （ＣＮ）を*.relay.example としてワイルドカードＳＳＬ証明書を取得すればよい。
（２）異なるホストは異なるサブドメインにマップされるため、Cross Site Scripting（ＸＳＳ）攻撃を回避できる。
２．レスポンスのHyperText Markup Language （ＨＴＭＬ）文書のDocument Object Model （ＤＯＭ）解析及びパス解決が不要なため、中継処理の負担が軽い。
３．ユーザが一度この形式のＵＲＬにアクセスすると、リンクをたどるいわゆるＷｅｂブラウズ行為を通して、自然にずっと中継サーバ１０２経由のアクセスが保たれる。
１．システム間連携に必要な以下の２点のセキュリティを両立させることができる。
（１）ワイルドカードＳＳＬ証明書を利用することで、中継サーバのサーバ認証が可能 になる。上記のｅｘ１〜ｅｘ４では、Common Name （ＣＮ）を*.relay.example としてワイルドカードＳＳＬ証明書を取得すればよい。
（２）異なるホストは異なるサブドメインにマップされるため、Cross Site Scripting（ＸＳＳ）攻撃を回避できる。
２．レスポンスのHyperText Markup Language （ＨＴＭＬ）文書のDocument Object Model （ＤＯＭ）解析及びパス解決が不要なため、中継処理の負担が軽い。
３．ユーザが一度この形式のＵＲＬにアクセスすると、リンクをたどるいわゆるＷｅｂブラウズ行為を通して、自然にずっと中継サーバ１０２経由のアクセスが保たれる。
図２は、中継サーバ１０２による中継動作の例を示している。この例では、目的サーバ２０３上のhttp://target.example/path というＷｅｂサイトに中継サーバ１０２経由でアクセスするため、クライアント１０１のブラウザは、http://http-target-example.relay.example/pathにアクセスする。
中継サーバ１０２は、ＣＮを*.relay.example としたワイルドカードＳＳＬ証明書２０２を保持している。また、Domain Name Server（ＤＮＳ、ドメイン名サーバ）２０１は、*.relay.example というホスト名を含むリクエストをすべて中継サーバ１０２に送るように設定されている。具体的な動作手順は、以下の通りである。
（１）ＤＮＳ２０１は、ホスト名解決を行って中継サーバ１０２のＩＰアドレスをクライアント１０１に返す。
（２）ブラウザは、中継サーバ１０２に対して、/pathに対するリクエストを発行する。
（３）中継サーバ１０２は、リクエストヘッダからhttp-target-exampleという文字列を取得し、これをhttp://target.exampleに変換する。そして、http://target.exampleを/pathというパス情報と合わせて、http://target.example/pathへのリクエストを発行し、目的サーバ２０３からのレスポンスを受信する。
（４）レスポンスのMultipurpose Internet Mail Extension（ＭＩＭＥ）タイプに応じて、レスポンスに対する所定の加工を行う。リンクを伴うコンテンツタイプの場合は、単純テキスト置換で絶対パスの書き換えを行う。この場合、ＤＯＭ解析は不要なので処理が高速になる。画像等のように加工の必要のないコンテンツに対しては、何も行わない。
（５）加工されたレスポンスをクライアント１０１に返す。ここで返されるＨＴＭＬ文書上のパスは、やはり中継サーバ１０２を経由するものになるが、そのパスへのアクセスも同様に処理されるため、再帰的に整合性の取れたページがブラウザ画面に表示される。
（１）ＤＮＳ２０１は、ホスト名解決を行って中継サーバ１０２のＩＰアドレスをクライアント１０１に返す。
（２）ブラウザは、中継サーバ１０２に対して、/pathに対するリクエストを発行する。
（３）中継サーバ１０２は、リクエストヘッダからhttp-target-exampleという文字列を取得し、これをhttp://target.exampleに変換する。そして、http://target.exampleを/pathというパス情報と合わせて、http://target.example/pathへのリクエストを発行し、目的サーバ２０３からのレスポンスを受信する。
（４）レスポンスのMultipurpose Internet Mail Extension（ＭＩＭＥ）タイプに応じて、レスポンスに対する所定の加工を行う。リンクを伴うコンテンツタイプの場合は、単純テキスト置換で絶対パスの書き換えを行う。この場合、ＤＯＭ解析は不要なので処理が高速になる。画像等のように加工の必要のないコンテンツに対しては、何も行わない。
（５）加工されたレスポンスをクライアント１０１に返す。ここで返されるＨＴＭＬ文書上のパスは、やはり中継サーバ１０２を経由するものになるが、そのパスへのアクセスも同様に処理されるため、再帰的に整合性の取れたページがブラウザ画面に表示される。
図３は、中継サーバ１０２の構成例を示している。図３の中継サーバ１０２は、要求受付部３０１、サブドメイン解釈部３０２、要求転送部３０３、クライアントセッション管理部３０４、ユーザ情報格納部３０５、証明書格納部３０６、応答転送部３０７、応答変換部３０８、応答解釈部３０９、及び応答受付部３１０を備える。
要求受付部３０１は、クライアント１０１からのリクエストを受信し、サブドメイン解釈部３０２は、リクエスト中のサブドメイン部分を解釈し、要求転送部３０３は、目的サーバにリクエストを転送する。
応答受付部３１０は、目的サーバからのレスポンスを受信し、応答解釈部３０９は、レスポンスの内容を解釈し、応答変換部３０８は、レスポンスの内容を変換し、応答転送部３０７は、変換後のレスポンスをクライアント１０１に返送する。例えば、ハイパーテキストの場合は応答変換部３０８により変換されるが、画像等の場合は応答変換部３０８をバイパスして応答転送部３０７に転送される。
ユーザ情報格納部３０５は、クライアント１０１のユーザのユーザ名、パスワード等のユーザ情報を格納し、クライアントセッション管理部３０４は、そのユーザ情報を用いてクライアント１０１とのセッションを管理する。
証明書格納部３０６は、ワイルドカードＳＳＬ証明書を格納し、中継サーバ１０２は、クライアント１０１とＨＴＴＰＳ通信を行う際にこの証明書を参照する。これにより、ＨＴＴＰＳアクセスに対するサーバ認証が行なわれ、安全なＳＳＬハンドシェイクが可能になる。
サブドメイン解釈部３０２は、リクエストに対するＵＲＬ逆変換加工を行う。例えば、クライアント１０１が要求してきたＵＲＬがhttp://http-with-port-example--8080.relay.example/index.htmlである場合、そのホスト名部分http-with-port-example--8080から、元ＵＲＬのプロトコル部分、ＦＱＤＮ部分、及びポート番号部分を抽出する。そして、抽出した部分にパス名を結合することで、元ＵＲＬであるhttp://with.port.example:8080/index.htmlを生成する。
要求転送部３０３は、このＵＲＬへのアクセスを行ってレスポンスを取得する。応答解釈部３０９は、レスポンスのＭＩＭＥタイプを解釈し、変換が必要な情報のみを応答変換部３０８に転送する。
応答変換部３０８は、レスポンスに対してマッシュアップ用のスクリプト等を挿入したり、ＵＲＬ変換加工を行ったりすることで、レスポンスのＷｅｂページを編集する。ＵＲＬ変換加工では、レスポンスに含まれるＵＲＬのうち、httpから始まる絶対パス記述が所定のルールに従って変換され、中継サーバ１０２経由のＵＲＬに書き換えられる。ただし、レスポンス中のＵＲＬが既にこの形式になっている場合は、書き換えを行わない。
クライアントセッション管理部３０４は、利用権限のないユーザからのアクセスを制限するため、クライアント１０１からの初回利用時には認証画面を出力し、あらかじめ登録してあるユーザ名とパスワードの入力を求める。入力内容がユーザ情報格納部３０５のユーザ情報と一致しない場合は、そのクライアント１０１による利用を許可しない。
ユーザが認証されると、中継サーバ１０２は、クッキー、認証ヘッダ等の情報をクライアント１０１と目的サーバの間でそのまま転送し、中継時にこれらの情報の書き換えは行わない。
次に、図４から図１５までを参照しながら、クライアント１０１から受信したリクエスト及び目的サーバから受信したレスポンスの加工方法について説明する。
図４及び図５は、サブドメイン解釈部３０２によるリクエストの加工例を示している。この例では、リクエストに含まれる情報のうち、メソッド、パス、及びメッセージボディは加工されない。一方、ホスト及びポートはＵＲＬ逆変換加工により変換され、ヘッダは図５に示すように加工される。ヘッダに含まれる情報のうち、Host及びReferer はＵＲＬ逆変換加工により変換され、Accept、If-Modified-Since 、及びUser-Agentは加工されない。例えば、図６のようなリクエストヘッダは、加工されて図７のようなリクエストヘッダに変換される。
図４及び図５は、サブドメイン解釈部３０２によるリクエストの加工例を示している。この例では、リクエストに含まれる情報のうち、メソッド、パス、及びメッセージボディは加工されない。一方、ホスト及びポートはＵＲＬ逆変換加工により変換され、ヘッダは図５に示すように加工される。ヘッダに含まれる情報のうち、Host及びReferer はＵＲＬ逆変換加工により変換され、Accept、If-Modified-Since 、及びUser-Agentは加工されない。例えば、図６のようなリクエストヘッダは、加工されて図７のようなリクエストヘッダに変換される。
図８及び図９は、応答変換部３０８によるレスポンスの加工例を示している。この例では、レスポンスに含まれる情報のうち、応答コードは加工されない。ＭＩＭＥタイプを示すContent-typeがtext/*である場合は、メッセージボディの全体に対してＵＲＬ変換加工が行われる。さらに、Content-typeがtext/htmlである場合は、SCRIPTタグが挿入される。ただし、Framesetタグが発見されたときは、SCRIPTタグの挿入は行われない。
ヘッダは図９に示すように加工される。ヘッダに含まれる情報のうち、Content-type、Content-Disposition 、Connection、Content-Language、及びExpires は加工されない。Content-Lengthは、加工後のコンテンツの長さに変更され、Set-Cookieは、中継サーバ１０２でセッション管理を行う場合は加工される。Locationは、ＵＲＬ変換加工により変換され、WWW-Authenticateは、後述するシングルサインオンを行う場合を除いて加工されない。
例えば、図１０のようなレスポンスヘッダは、加工されて図１１のようなレスポンスヘッダに変換され、図１２のようなメッセージボディは、加工されて図１３のようなメッセージボディに変換される。
この場合、図１０のContent-Lengthは、6110から6432に変換され、図１３のメッセージボディには、SCRIPTタグが挿入されている。このレスポンスを受信したクライアント１０１のブラウザは、SCRIPTタグにより指定されたスクリプトを使用して出力情報を加工する。
ユーザは、目的サーバと挿入したいスクリプトの組をユーザ情報として、あらかじめ中継サーバ１０２に登録しておくこともできる。この場合、クライアントセッション管理部３０４は、ユーザ情報を参照してユーザを特定し、応答変換部３０８は、その指定に応じたスクリプトをメッセージボディに挿入する。
図８及び図９に示したＵＲＬ変換加工としては、サブドメイン名（ホスト名）に適用可能な文字列パターンの可逆変換（エンコーディング）であれば、いかなる変換方法でも用いることができる。このような可逆変換の具体例としては、所定の変換ルールによるテキスト置換、暗号化等が考えられる。図４及び図５に示したＵＲＬ逆変換加工は、この可逆変換の逆変換である。
テキスト置換を用いたＵＲＬ変換加工の具体例としては、前述したｅｘ１〜ｅｘ４が挙げられる。この場合の加工手順は、以下の通りである（図１４を参照）。
１．入力ＵＲＬからプロトコル、ＦＱＤＮ、及びポート番号（省略されているときを除く
）の文字列を取り出す（ステップ４０１）。
２．ＦＱＤＮ文字列にハイフンが含まれていれば（ステップ４０２）、これをハイフン２つに置換する（ステップ４０３）。
３．上記２で生成された文字列のドットをハイフンに置換する（ステップ４０４）。
４．上記１で取り出したプロトコル文字列（http、https 等）を、上記３で生成された文字列の前にハイフンで連結する（ステップ４０５）。
５．上記１で取り出したポート番号文字列があれば（ステップ４０６）、上記４で生成された文字列の後ろにハイフン２つで連結する（ステップ４０７）。
６．上記５で生成された文字列をホスト名として、中継サーバ１０２のドメイン（relay.example）に付加する形で、出力ＵＲＬを生成する（ステップ４０８）。
１．入力ＵＲＬからプロトコル、ＦＱＤＮ、及びポート番号（省略されているときを除く
）の文字列を取り出す（ステップ４０１）。
２．ＦＱＤＮ文字列にハイフンが含まれていれば（ステップ４０２）、これをハイフン２つに置換する（ステップ４０３）。
３．上記２で生成された文字列のドットをハイフンに置換する（ステップ４０４）。
４．上記１で取り出したプロトコル文字列（http、https 等）を、上記３で生成された文字列の前にハイフンで連結する（ステップ４０５）。
５．上記１で取り出したポート番号文字列があれば（ステップ４０６）、上記４で生成された文字列の後ろにハイフン２つで連結する（ステップ４０７）。
６．上記５で生成された文字列をホスト名として、中継サーバ１０２のドメイン（relay.example）に付加する形で、出力ＵＲＬを生成する（ステップ４０８）。
図１２のメッセージボディに含まれているhttp://target.example/foo.html というＵＲＬは、このＵＲＬ変換加工により、図１３のhttp://http-target-example.relay.example/foo.htmlに変換される。
一方、ＵＲＬ逆変換加工の加工手順は、以下の通りである（図１５を参照）。
１．入力ＵＲＬのホスト名文字列（ＦＱＤＮの一番左側の要素）を取り出す（ステップ５０１）。
２．上記１で取り出した文字列は先頭がhttp- またはhttps-で始まっているはずなので、この先頭文字列をプロトコル文字列とする（ステップ５０２）。
３．上記１で取り出した文字列の末尾がハイフン２つに続く数字列となっていれば（ステップ５０３）、この数字列をポート番号文字列とする（ステップ５０４）。そうでない場合は、ポート番号文字列は省略する。
４．上記１で取り出した文字列から、上記２及び３で解釈に用いた先頭及び末尾の文字列を削除する（ステップ５０５）。
５．上記４で残った文字列のハイフンをすべてドットに置換する（ステップ５０６）。
６．上記５で生成された文字列にドットが２つ連続して現れれば（ステップ５０７）、その２つのドットを１つのドットに置換し、ＦＱＤＮ文字列を生成する（ステップ５０８）。
７．上記２で取り出したプロトコル文字列、上記６で生成されたＦＱＤＮ文字列、及び上記３で取り出したポート番号文字列を用いて、出力ＵＲＬを生成する（ステップ５０９）。
１．入力ＵＲＬのホスト名文字列（ＦＱＤＮの一番左側の要素）を取り出す（ステップ５０１）。
２．上記１で取り出した文字列は先頭がhttp- またはhttps-で始まっているはずなので、この先頭文字列をプロトコル文字列とする（ステップ５０２）。
３．上記１で取り出した文字列の末尾がハイフン２つに続く数字列となっていれば（ステップ５０３）、この数字列をポート番号文字列とする（ステップ５０４）。そうでない場合は、ポート番号文字列は省略する。
４．上記１で取り出した文字列から、上記２及び３で解釈に用いた先頭及び末尾の文字列を削除する（ステップ５０５）。
５．上記４で残った文字列のハイフンをすべてドットに置換する（ステップ５０６）。
６．上記５で生成された文字列にドットが２つ連続して現れれば（ステップ５０７）、その２つのドットを１つのドットに置換し、ＦＱＤＮ文字列を生成する（ステップ５０８）。
７．上記２で取り出したプロトコル文字列、上記６で生成されたＦＱＤＮ文字列、及び上記３で取り出したポート番号文字列を用いて、出力ＵＲＬを生成する（ステップ５０９）。
図６のリクエストヘッダのHost及びReferer に含まれているhttp-target-example.relay.exampleという文字列は、このＵＲＬ逆変換加工により、図７のtarget.example に変換される。
以上のＵＲＬ変換加工及びＵＲＬ逆変換加工の例では、置換文字としてハイフンを用いているが、他の文字を置換文字として用いても構わない。例えば、ハイフンの代わりにアルファベットの“j "を用いた場合、ＵＲＬ変換加工は次のようになる。
（ｅｘ５）
http://target.example/
→http(s)://httpjtargetjexample.relay.example/
さらに、次に示すように、上記ｅｘ５で得られた文字列の順序を反転させる加工を追加してもよい。
（ｅｘ６）
http://target.example/
→http(s)://httpjtargetjexample.relay.example/
→http(s)://elpmaxejtegratjptth.relay.example/
また、次に示すように、置換文字としてハイフンを用いた文字列の末尾にユーザ名を付加する加工を追加してもよい。
（ｅｘ７）
http://target.example/
→http(s)://http-target-example.relay.example/
→http(s)://http-target-example-sato.relay.example/
さらに、次に示すように、上記ｅｘ７で得られた文字列の末尾に「本日」の日付を付加する加工を追加してもよい。
（ｅｘ８）
http://target.example/
→http(s)://http-target-example.relay.example/
→http(s)://http-target-example-sato.relay.example/
→http(s)://http-target-example-sato-20080415.relay.net/
さらに、次に示すように、上記ｅｘ８で得られた文字列の５文字目以降を換字暗号で変換する加工を追加してもよい。
（ｅｘ９）
http://target.example/
→http(s)://http-target-example.relay.example/
→http(s)://http-target-example-sato.relay.example/
→http(s)://http-target-example-sato-20080415.relay.example/
→http(s)://http7jkh2zj7ztk6g5z7ikjf7v8838-r0.relay.example/
上記ｅｘ９で用いた換字暗号を１行のPractical Extraction and Report Language（Ｐｅｒｌ）プログラムで記述すると、次のようになる。ただし、可逆暗号化の種類及び方式はこれに限られない。
暗号 perl -pe "tr/abcdefghijklmnopqrstuvwxyz\-0123456789/klxyz12abpq56efg9hijmnstuo78rvc\-0dw34/"
復号 perl -pe "tr/klxyz12abpq56efg9hijmnstuo78rvc\-0dw34/abcdefghijklmnopqrstuvwxyz\-0123456789/"
人間にとっての可読性や計算機資源の節約を考慮すると、ハイフンを用いたテキスト置換が最も実用的と考えられる。しかし、目的サーバのＵＲＬをユーザから隠蔽する等の特殊な用途においては、その用途に応じて適切な変換ルールを用いることが可能である。
（ｅｘ５）
http://target.example/
→http(s)://httpjtargetjexample.relay.example/
さらに、次に示すように、上記ｅｘ５で得られた文字列の順序を反転させる加工を追加してもよい。
（ｅｘ６）
http://target.example/
→http(s)://httpjtargetjexample.relay.example/
→http(s)://elpmaxejtegratjptth.relay.example/
また、次に示すように、置換文字としてハイフンを用いた文字列の末尾にユーザ名を付加する加工を追加してもよい。
（ｅｘ７）
http://target.example/
→http(s)://http-target-example.relay.example/
→http(s)://http-target-example-sato.relay.example/
さらに、次に示すように、上記ｅｘ７で得られた文字列の末尾に「本日」の日付を付加する加工を追加してもよい。
（ｅｘ８）
http://target.example/
→http(s)://http-target-example.relay.example/
→http(s)://http-target-example-sato.relay.example/
→http(s)://http-target-example-sato-20080415.relay.net/
さらに、次に示すように、上記ｅｘ８で得られた文字列の５文字目以降を換字暗号で変換する加工を追加してもよい。
（ｅｘ９）
http://target.example/
→http(s)://http-target-example.relay.example/
→http(s)://http-target-example-sato.relay.example/
→http(s)://http-target-example-sato-20080415.relay.example/
→http(s)://http7jkh2zj7ztk6g5z7ikjf7v8838-r0.relay.example/
上記ｅｘ９で用いた換字暗号を１行のPractical Extraction and Report Language（Ｐｅｒｌ）プログラムで記述すると、次のようになる。ただし、可逆暗号化の種類及び方式はこれに限られない。
暗号 perl -pe "tr/abcdefghijklmnopqrstuvwxyz\-0123456789/klxyz12abpq56efg9hijmnstuo78rvc\-0dw34/"
復号 perl -pe "tr/klxyz12abpq56efg9hijmnstuo78rvc\-0dw34/abcdefghijklmnopqrstuvwxyz\-0123456789/"
人間にとっての可読性や計算機資源の節約を考慮すると、ハイフンを用いたテキスト置換が最も実用的と考えられる。しかし、目的サーバのＵＲＬをユーザから隠蔽する等の特殊な用途においては、その用途に応じて適切な変換ルールを用いることが可能である。
以上のような中継方法によれば、次のような効果が得られる。
（１）中継サーバを適切に設定することにより、既存のＷｅｂページ及びＷｅｂアプリケーションに対して全く手を加えることなく、外部からスクリプト挿入等を行った改造版をユーザに提供することができる。
（２）元ドメインが異なるＵＲＬは中継サーバを経由しても別のドメインとして扱われる
ため、中継サーバ経由で複数のＷｅｂサイトにアクセスしているような状況でも、ブラウザ側のsame origin policyによって悪意のあるサイトからＷｅｂシステムを守ることが可能になる。
（３）中継サーバ経由の全ＵＲＬに対して有効なワイルドカードＳＳＬ証明書を事前に用意することができるため、ユーザのブラウザでサーバの正当性が確認でき、中継サーバ利用時の不安要素をなくすことができる。
（４）特に大規模な企業システム等に対して少しでも機能追加を行うためには、小規模とはいえプログラムに変更を加えることになる。このため、多くの場合、全機能の再テストが必要となり、コスト面で現実的ではない。しかし、中継サーバを用いることにより、既存システムに全く手を加えることなく、出力加工により対応できる範囲内で機能追加や機能変更が可能になる。Asynchronous JavaScript + XML （Ａｊａｘ）等のＷｅｂアプリケーションにおけるクライアント技術の台頭により、出力加工により対応できる範囲は非常に広がっており、特に他のシステムとの連携等を柔軟に行えるようになる。
（１）中継サーバを適切に設定することにより、既存のＷｅｂページ及びＷｅｂアプリケーションに対して全く手を加えることなく、外部からスクリプト挿入等を行った改造版をユーザに提供することができる。
（２）元ドメインが異なるＵＲＬは中継サーバを経由しても別のドメインとして扱われる
ため、中継サーバ経由で複数のＷｅｂサイトにアクセスしているような状況でも、ブラウザ側のsame origin policyによって悪意のあるサイトからＷｅｂシステムを守ることが可能になる。
（３）中継サーバ経由の全ＵＲＬに対して有効なワイルドカードＳＳＬ証明書を事前に用意することができるため、ユーザのブラウザでサーバの正当性が確認でき、中継サーバ利用時の不安要素をなくすことができる。
（４）特に大規模な企業システム等に対して少しでも機能追加を行うためには、小規模とはいえプログラムに変更を加えることになる。このため、多くの場合、全機能の再テストが必要となり、コスト面で現実的ではない。しかし、中継サーバを用いることにより、既存システムに全く手を加えることなく、出力加工により対応できる範囲内で機能追加や機能変更が可能になる。Asynchronous JavaScript + XML （Ａｊａｘ）等のＷｅｂアプリケーションにおけるクライアント技術の台頭により、出力加工により対応できる範囲は非常に広がっており、特に他のシステムとの連携等を柔軟に行えるようになる。
図３の中継サーバの処理をソフトウェアにより実装する場合、図１６に示すような情報処理装置（コンピュータ）が用いられる。図１６の情報処理装置は、Central Processing
Unit （ＣＰＵ）１４０１、メモリ１４０２、入力装置１４０３、出力装置１４０４、外部記憶装置１４０５、媒体駆動装置１４０６、およびネットワーク接続装置１４０７を備え、それらはバス１４０８により互いに接続されている。
Unit （ＣＰＵ）１４０１、メモリ１４０２、入力装置１４０３、出力装置１４０４、外部記憶装置１４０５、媒体駆動装置１４０６、およびネットワーク接続装置１４０７を備え、それらはバス１４０８により互いに接続されている。
メモリ１４０２は、例えば、Read Only Memory（ＲＯＭ）、Random Access Memory（ＲＡＭ）等を含み、処理に用いられるプログラムおよびデータを格納する。ＣＰＵ１４０１は、メモリ１４０２を利用してプログラムを実行することにより、中継サーバ１０２と同様の処理を行う。
入力装置１４０３は、例えば、キーボード、ポインティングデバイス等であり、オペレータからの指示や情報の入力に用いられる。出力装置１４０４は、例えば、ディスプレイ、プリンタ、スピーカ等であり、オペレータへの問い合わせや処理結果の出力に用いられる。
外部記憶装置１４０５は、例えば、磁気ディスク装置、光ディスク装置、光磁気ディスク装置、テープ装置等である。情報処理装置は、この外部記憶装置１４０５に、プログラムおよびデータを格納しておき、必要に応じて、それらをメモリ１４０２にロードして使用する。
媒体駆動装置１４０６は、可搬記録媒体１４０９を駆動し、その記録内容にアクセスする。可搬記録媒体１４０９は、メモリカード、フレキシブルディスク、光ディスク、光磁気ディスク等の任意のコンピュータ読み取り可能な記録媒体である。オペレータは、この可搬記録媒体１４０９にプログラムおよびデータを格納しておき、必要に応じて、それらをメモリ１４０２にロードして使用する。
ネットワーク接続装置１４０７は、インターネット等の通信ネットワークに接続され、クライアント１０１及び各目的サーバとの通信に伴うデータ変換を行う。また、情報処理装置は、必要に応じて、プログラムおよびデータを外部の装置からネットワーク接続装置１４０７を介して受け取り、それらをメモリ１４０２にロードして使用する。
図１７は、図１６の情報処理装置にプログラムおよびデータを提供する方法を示している。可搬記録媒体１４０９や外部装置１５０１のデータベース１５１１に格納されたプログラムおよびデータは、情報処理装置１５０２のメモリ１４０２にロードされる。外部装置１５０１は、そのプログラムおよびデータを搬送する搬送信号を生成し、通信ネットワ
ーク上の任意の伝送媒体を介して情報処理装置１５０２に送信する。ＣＰＵ１４０１は、そのデータを用いてそのプログラムを実行し、上述した処理を行う。
ーク上の任意の伝送媒体を介して情報処理装置１５０２に送信する。ＣＰＵ１４０１は、そのデータを用いてそのプログラムを実行し、上述した処理を行う。
以上、図１から図１７までを参照しながら説明した実施形態に関し、さらに以下の付記を開示する。
（付記１）中継サーバによるウェブ情報中継方法であって、
クライアントからのリクエストを受信するステップと、
前記リクエストに対応するウェブページを編集する際に、マッシュアップ対象のページに記述されたユニフォームリソースロケータ情報を抽出し、抽出されたユニフォームリソースロケータ情報のホスト名のドットを別の文字に置換するとともに、前記中継サーバのホスト名を付加するステップと、
編集後のウェブページを前記クライアントへ送信するステップと
を含むことを特徴とするウェブ情報中継方法。
（付記２）前記中継サーバは、前記抽出されたユニフォームリソースロケータ情報の完全修飾ドメイン名をホスト名にエンコードし、得られたホスト名に、前記中継サーバのプロトコル、前記中継サーバのホスト名、及び前記抽出されたユニフォームリソースロケータ情報のパス名を結合して、前記中継サーバを経由するためのユニフォームリソースロケータ情報を生成することを特徴とする付記１記載のウェブ情報中継方法。
（付記３）前記中継サーバを経由するためのユニフォームリソースロケータ情報を含むリクエストを前記クライアントから受信するステップと、
前記中継サーバを経由するためのユニフォームリソースロケータ情報に含まれるホスト名を抽出し、抽出されたホスト名から前記中継サーバのホスト名を削除し、残された文字列から、前記ドットを前記別の文字に置換する前のホスト名を生成するステップと、
生成されたホスト名を含むリクエストを目的サーバへ送信するステップと
をさらに含むことを特徴とする付記１又は２記載のウェブ情報中継方法。
（付記４）前記中継サーバにあらかじめ格納されている、前記マッシュアップ対象のページを有する目的サーバとスクリプト情報の組を示す情報を参照して、該目的サーバに対応するスクリプト情報を前記リクエストに対応するウェブページに挿入するステップをさらに含むことを特徴とする付記１、２、又は３記載のウェブ情報中継方法。
（付記５）クライアントからのリクエストを受信する受信部と、
前記リクエストに対応するウェブページを編集する際に、マッシュアップ対象のページに記述されたユニフォームリソースロケータ情報を抽出し、抽出されたユニフォームリソースロケータ情報のホスト名のドットを別の文字に置換するとともに、前記中継サーバのホスト名を付加する編集部と、
編集後のウェブページを前記クライアントへ送信する送信部と
を備えることを特徴とするウェブ情報中継装置。
（付記６）クライアントからのリクエストを受信するステップと、
前記リクエストに対応するウェブページを編集する際に、マッシュアップ対象のページに記述されたユニフォームリソースロケータ情報を抽出し、抽出されたユニフォームリソースロケータ情報のホスト名のドットを別の文字に置換するとともに、前記中継サーバのホスト名を付加するステップと、
編集後のウェブページを前記クライアントへ送信するステップと
を含む処理をコンピュータに実行させるためのプログラム。
（付記１）中継サーバによるウェブ情報中継方法であって、
クライアントからのリクエストを受信するステップと、
前記リクエストに対応するウェブページを編集する際に、マッシュアップ対象のページに記述されたユニフォームリソースロケータ情報を抽出し、抽出されたユニフォームリソースロケータ情報のホスト名のドットを別の文字に置換するとともに、前記中継サーバのホスト名を付加するステップと、
編集後のウェブページを前記クライアントへ送信するステップと
を含むことを特徴とするウェブ情報中継方法。
（付記２）前記中継サーバは、前記抽出されたユニフォームリソースロケータ情報の完全修飾ドメイン名をホスト名にエンコードし、得られたホスト名に、前記中継サーバのプロトコル、前記中継サーバのホスト名、及び前記抽出されたユニフォームリソースロケータ情報のパス名を結合して、前記中継サーバを経由するためのユニフォームリソースロケータ情報を生成することを特徴とする付記１記載のウェブ情報中継方法。
（付記３）前記中継サーバを経由するためのユニフォームリソースロケータ情報を含むリクエストを前記クライアントから受信するステップと、
前記中継サーバを経由するためのユニフォームリソースロケータ情報に含まれるホスト名を抽出し、抽出されたホスト名から前記中継サーバのホスト名を削除し、残された文字列から、前記ドットを前記別の文字に置換する前のホスト名を生成するステップと、
生成されたホスト名を含むリクエストを目的サーバへ送信するステップと
をさらに含むことを特徴とする付記１又は２記載のウェブ情報中継方法。
（付記４）前記中継サーバにあらかじめ格納されている、前記マッシュアップ対象のページを有する目的サーバとスクリプト情報の組を示す情報を参照して、該目的サーバに対応するスクリプト情報を前記リクエストに対応するウェブページに挿入するステップをさらに含むことを特徴とする付記１、２、又は３記載のウェブ情報中継方法。
（付記５）クライアントからのリクエストを受信する受信部と、
前記リクエストに対応するウェブページを編集する際に、マッシュアップ対象のページに記述されたユニフォームリソースロケータ情報を抽出し、抽出されたユニフォームリソースロケータ情報のホスト名のドットを別の文字に置換するとともに、前記中継サーバのホスト名を付加する編集部と、
編集後のウェブページを前記クライアントへ送信する送信部と
を備えることを特徴とするウェブ情報中継装置。
（付記６）クライアントからのリクエストを受信するステップと、
前記リクエストに対応するウェブページを編集する際に、マッシュアップ対象のページに記述されたユニフォームリソースロケータ情報を抽出し、抽出されたユニフォームリソースロケータ情報のホスト名のドットを別の文字に置換するとともに、前記中継サーバのホスト名を付加するステップと、
編集後のウェブページを前記クライアントへ送信するステップと
を含む処理をコンピュータに実行させるためのプログラム。
１０１ クライント
１０２ 中継サーバ
１０４、１０５、１０６、２０３ 目的サーバ
２０１ ＤＮＳ
２０２ ワイルドカードＳＳＬ証明書
３０１ 要求受付部
３０２ サブドメイン解釈部
３０３ 要求転送部
３０４ クライアントセッション管理部
３０５ ユーザ情報格納部
３０６ 証明書格納部
３０７ 応答転送部
３０８ 応答変換部
３０９ 応答解釈部
３１０ 応答受付部
１４０１ ＣＰＵ
１４０２ メモリ
１４０３ 入力装置
１４０４ 出力装置
１４０５ 外部記憶装置
１４０６ 媒体駆動装置
１４０７ ネットワーク接続装置
１４０８ バス
１５０１ 外部装置
１５０２ 情報処理装置
１５１１ データベース
１０２ 中継サーバ
１０４、１０５、１０６、２０３ 目的サーバ
２０１ ＤＮＳ
２０２ ワイルドカードＳＳＬ証明書
３０１ 要求受付部
３０２ サブドメイン解釈部
３０３ 要求転送部
３０４ クライアントセッション管理部
３０５ ユーザ情報格納部
３０６ 証明書格納部
３０７ 応答転送部
３０８ 応答変換部
３０９ 応答解釈部
３１０ 応答受付部
１４０１ ＣＰＵ
１４０２ メモリ
１４０３ 入力装置
１４０４ 出力装置
１４０５ 外部記憶装置
１４０６ 媒体駆動装置
１４０７ ネットワーク接続装置
１４０８ バス
１５０１ 外部装置
１５０２ 情報処理装置
１５１１ データベース
Claims (5)
- 中継サーバによるウェブ情報中継方法であって、
クライアントからのリクエストを受信するステップと、
前記リクエストに対応するウェブページを編集する際に、マッシュアップ対象のページに記述されたユニフォームリソースロケータ情報を抽出し、抽出されたユニフォームリソースロケータ情報のホスト名のドットを別の文字に置換するとともに、前記中継サーバのホスト名を付加するステップと、
編集後のウェブページを前記クライアントへ送信するステップと
を含むことを特徴とするウェブ情報中継方法。 - 前記中継サーバは、前記抽出されたユニフォームリソースロケータ情報の完全修飾ドメイン名をホスト名にエンコードし、得られたホスト名に、前記中継サーバのプロトコル、前記中継サーバのホスト名、及び前記抽出されたユニフォームリソースロケータ情報のパス名を結合して、前記中継サーバを経由するためのユニフォームリソースロケータ情報を生成することを特徴とする請求項１記載のウェブ情報中継方法。
- 前記中継サーバを経由するためのユニフォームリソースロケータ情報を含むリクエストを前記クライアントから受信するステップと、
前記中継サーバを経由するためのユニフォームリソースロケータ情報に含まれるホスト名を抽出し、抽出されたホスト名から前記中継サーバのホスト名を削除し、残された文字列から、前記ドットを前記別の文字に置換する前のホスト名を生成するステップと、
生成されたホスト名を含むリクエストを目的サーバへ送信するステップと
をさらに含むことを特徴とする請求項１又は２記載のウェブ情報中継方法。 - クライアントからのリクエストを受信する受信部と、
前記リクエストに対応するウェブページを編集する際に、マッシュアップ対象のページに記述されたユニフォームリソースロケータ情報を抽出し、抽出されたユニフォームリソースロケータ情報のホスト名のドットを別の文字に置換するとともに、前記中継サーバのホスト名を付加する編集部と、
編集後のウェブページを前記クライアントへ送信する送信部と
を備えることを特徴とするウェブ情報中継装置。 - クライアントからのリクエストを受信するステップと、
前記リクエストに対応するウェブページを編集する際に、マッシュアップ対象のページに記述されたユニフォームリソースロケータ情報を抽出し、抽出されたユニフォームリソースロケータ情報のホスト名のドットを別の文字に置換するとともに、前記中継サーバのホスト名を付加するステップと、
編集後のウェブページを前記クライアントへ送信するステップと
を含む処理をコンピュータに実行させるためのプログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2008120734A JP5146088B2 (ja) | 2008-05-02 | 2008-05-02 | ウェブ情報中継方法及び装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2008120734A JP5146088B2 (ja) | 2008-05-02 | 2008-05-02 | ウェブ情報中継方法及び装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2009271676A JP2009271676A (ja) | 2009-11-19 |
| JP5146088B2 true JP5146088B2 (ja) | 2013-02-20 |
Family
ID=41438182
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2008120734A Expired - Fee Related JP5146088B2 (ja) | 2008-05-02 | 2008-05-02 | ウェブ情報中継方法及び装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP5146088B2 (ja) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP5581820B2 (ja) * | 2010-06-04 | 2014-09-03 | 富士通株式会社 | 中継サーバ装置、クッキー制御方法およびクッキー制御プログラム |
| JP5565197B2 (ja) * | 2010-08-18 | 2014-08-06 | 富士通株式会社 | Ｗｅｂアプリケーションの連携方法、連携装置、および連携プログラム |
| JP5863398B2 (ja) * | 2011-11-04 | 2016-02-16 | サイボウズ株式会社 | サーバ装置及びサーバ装置の制御方法 |
| JP5811006B2 (ja) * | 2012-03-29 | 2015-11-11 | 富士通株式会社 | 情報処理装置、情報処理方法、および情報処理プログラム |
| JP6350235B2 (ja) * | 2014-11-18 | 2018-07-04 | 富士通株式会社 | 情報処理装置、情報処理装置制御方法及び情報処理装置制御プログラム |
| CN111064713B (zh) * | 2019-02-15 | 2021-05-25 | 腾讯科技（深圳）有限公司 | 一种分布式***中的节点控制方法和相关装置 |
-
2008
- 2008-05-02 JP JP2008120734A patent/JP5146088B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2009271676A (ja) | 2009-11-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2005321970A (ja) | コンピュータシステム | |
| JP5146088B2 (ja) | ウェブ情報中継方法及び装置 | |
| US20110131408A1 (en) | Document link security | |
| EP2144420A1 (en) | Web application security filtering | |
| JP2004029939A (ja) | 通信プロキシ装置、および、通信プロキシ装置を用いたサービス提供方法 | |
| US20090187820A1 (en) | Method and apparatus for checkout transition in an e-commerce application | |
| US8201238B1 (en) | Remote directory browsing through a secure gateway of a virtual private network | |
| WO2015183701A1 (en) | Client/server authentication using dynamic credentials | |
| WO2002039286A1 (en) | Encoding of universal resource locators in a security gateway to enable manipulation by active content | |
| CN101132420A (zh) | 一种基于ssl vpn的链接改写方法和设备 | |
| JP2008197973A (ja) | ユーザ認証システム | |
| JP2007334411A (ja) | 制御プログラムおよび通信システム | |
| US20170093772A1 (en) | Method and System for Optimizing and Preventing Failure of Sender Policy Framework (SPF) Lookups | |
| CN105072123A (zh) | 一种集群环境下的单点登陆退出方法及*** | |
| JP5347429B2 (ja) | ユニフォームリソースロケータ書換方法及び装置 | |
| CN101499100B (zh) | 电子商务应用中校验转换的方法和设备 | |
| KR102087268B1 (ko) | 웹 컨트롤 인터페이스를 제공하는 장치 및 이의 동작 방법 | |
| JP2007257500A (ja) | 被認証装置、被認証プログラム、被認証方法、ＷｅｂブラウザプラグインおよびＷｅｂブラウザブックマークレット | |
| JP6317506B2 (ja) | 中継装置、中継方法および中継プログラム | |
| JP2009301456A (ja) | データ変換プログラム、データ変換装置およびデータ変換方法 | |
| JP4871396B2 (ja) | ウェブサイトの閲覧を管理するシステム | |
| CN113824756A (zh) | 文件处理方法、装置、存储介质及电子设备 | |
| JP6897103B2 (ja) | 機器、認証システム、及び認証方法 | |
| JP4728634B2 (ja) | クライアントアクセス管理方法および装置 | |
| JP4937070B2 (ja) | 書類データ管理方法、書類データ作成方法、サーバおよびコンピュータプログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20110118 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20121017 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20121030 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20121112 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 5146088 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20151207 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |