JP2009116407A - 情報処理装置及びクライアントサーバシステム - Google Patents

Abstract

【課題】Ｃｏｏｋｉｅを利用せず、簡易且つ確実にセッション管理を行う。
【解決手段】Ｗｅｂサーバ３６は、クライアント１０から受け付けたリクエストに認証キー付き絶対パスＵＲＩが含まれていれば、認証キー付き絶対パスＵＲＩから認証キーを抽出し、認証キーを含まない絶対パスを有する通常絶対パスＵＲＩに変換し、抽出された認証キーとともに、変換された通常絶対パスＵＲＩを含むリクエストをＷｅｂサーバ３６に対して発行する認証キー抽出部３８と、受け付けたリクエストに通常絶対パスＵＲＩとともに認証キーが含まれていれば、認証キーを用いて、通常絶対パスＵＲＩに係るコンテンツへのアクセスを許否を判定する認証処理部４０と、アクセスが許可された通常絶対パスＵＲＩに係るコンテンツに基づいて、Ｗｅｂページを生成するＷｅｂページ生成部４２とを備える。
【選択図】図１

Description

本発明は、セッション管理のための技術に関し、特にＣｏｏｋｉｅを利用しないでセッション管理をする技術に関する。

従来、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を用いた通信では、１回のアクセスごとに通信が切断する。従って、ＨＴＴＰを用いて、クライアントとサーバとが継続的に通信を行うために、セッションという概念が導入されている。そして、各セッションを識別するセッションＩＤは、Ｃｏｏｋｉｅを利用してクライアント−サーバ間でやりとりされる。

一方で、携帯電話機などのハードウェア資源に制限がある装置をユーザ端末として利用する場合には、Ｃｏｏｋｉｅが利用できない場合や、Ｃｏｏｋｉｅを利用しない方が好ましい場合がある。そのような場合のセッション管理方法としては、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）リライトや、特許文献１の手法が知られている。
特開２００３−５８４９８号公報

しかしながら、ＵＲＬリライトは、サーバがＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）の書き換え処理を行うので、サーバに負荷がかかる。また、ＵＲＬリライトは、ＨＴＭＬへの変換が正しく行えない場合もある。

また、特許文献１の技術では、架空ディレクトリ名と実体ディレクトリ名とを１対１に対応付けたテーブルを用意して、架空ディレクトリ名を実体ディレクトリ名へ読み替えている。このため、特許文献１の技術を実装するためには、Ｗｅｂサーバに、架空ディレクトリ名を実体ディレクトリ名へ読み替えるための専用モジュール（Ａｐａｃｈｅの場合、ハンドラ）をいくつも搭載する必要があり、従来から使用されているＷｅｂサーバのモジュールを利用できない。従来から使用されているＷｅｂサーバのモジュールを利用できれば実装が容易であり、実装に係るコストも抑えることができる。

そこで、本発明の目的は、Ｃｏｏｋｉｅを利用せず、簡易且つ確実にセッション管理を行うための技術を提供することである。

本発明の一つの実施態様に従う情報処理装置は、ユーザ端末装置からのリクエストを受け付けて、前記受け付けたリクエストを処理するリクエスト処理手段を備える。前記リクエスト処理手段は、前記受け付けたリクエストに、認証キーが含まれている見かけ上の絶対パスを有する認証キー付き絶対パスＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）が含まれていれば、前記認証キー付き絶対パスＵＲＩから前記認証キーを抽出するとともに、前記認証キー付き絶対パスＵＲＩを、認証キーを含まない絶対パスを有する通常絶対パスＵＲＩに変換し、前記抽出された認証キーとともに、前記変換された通常絶対パスＵＲＩを含むリクエストを前記リクエスト処理手段に対して発行する認証キー抽出手段と、前記受け付けたリクエストに前記通常絶対パスＵＲＩとともに前記認証キーが含まれていれば、前記認証キーを用いて、前記通常絶対パスＵＲＩに係るコンテンツへのアクセスを許可するか否かを判定する認証処理手段と、前記認証処理手段によってアクセスが許可された前記通常絶対パスＵＲＩに係るコンテンツに基づいて、そのリクエストの内容に応じた処理を実行する処理実行手段とを備える。

好適な実施形態では、前記ユーザ端末装置からのログイン要求を受け付けて認証を行うログイン認証手段と、前記ログイン認証手段による認証が成功すると、その認証に係るセッションを識別するための識別情報として認証キーを生成する手段と、をさらに備え、前記認証キー付き絶対パスＵＲＩに含まれる認証キーは、前記認証キー生成手段で生成された認証キーであってもよい。

好適な実施形態では、前記処理実行手段は、Ｗｅｂページの生成処理を行う手段、ＣＧＩ処理を行う手段及びファイル出力を行う手段のうちのいずれか一つ以上であってもよい。

本発明の一つの実施態様に従うクライアント及びサーバを備えたシステムにおいて、前記クライアントは、認証キーが含まれている見かけ上の絶対パスを有する認証キー付き絶対パスＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）を生成する手段と、前記生成手段により生成された認証キー付きＵＲＩのリクエストを発行する手段と、を備える。前記サーバは、前記クライアントからのリクエストを受け付けて、前記受け付けたリクエストを処理するリクエスト処理手段を備える。そして、前記リクエスト処理手段は、前記受け付けたリクエストに前記認証キー付き絶対パスＵＲＩが含まれていれば、前記認証キー付き絶対パスＵＲＩから前記認証キーを抽出するとともに、前記認証キー付き絶対パスＵＲＩを認証キーを含まない絶対パスを有する通常絶対パスＵＲＩに変換し、前記抽出された認証キーとともに、前記変換された通常絶対パスＵＲＩを含むリクエストを前記リクエスト処理手段に対して発行する認証キー抽出手段と、前記受け付けたリクエストに前記通常絶対パスＵＲＩとともに前記認証キーが含まれていれば、前記認証キーを用いて、前記通常絶対パスＵＲＩに係るコンテンツへのアクセスを許可するか否かを判定する認証処理手段と、前記認証処理手段によってアクセスが許可された前記通常絶対パスＵＲＩに係るコンテンツに基づいて、そのリクエストの内容に応じた処理を実行する処理実行手段とを備える。

以下、本発明の一実施形態に係るクライアントサーバシステムについて、図面を参照して説明する。

図１は、本システムの全体構成図である。本システムは、一以上のクライアント１０とサーバ３０とがネットワーク９を介して接続されている。

クライアント１０は、ユーザが操作するユーザ端末装置として機能し、例えばパーソナルコンピュータなどの汎用的なコンピュータシステムでもよいし、携帯電話機、携帯情報端末などの可搬型の通信装置でもよい。以下に説明するクライアント１０内の個々の構成要素または機能は、例えば、コンピュータプログラムを実行することにより実現される。

クライアント１０は、Ｗｅｂブラウザ１２を有する。

Ｗｅｂブラウザ１２は記憶部１４を有し、ＨＴＭＬなどのスクリプトで記述された文書を解析し、これを表示する機能を有する。また、Ｗｅｂブラウザ１２は、ユーザによってハイパーリンクが選択されたときに、そのハイパーリンクで指定されたＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）へのアクセス要求をサーバ３０へ送信する。また、Ｗｅｂブラウザ１２は、ＨＴＭＬファイルなどをサーバ３０から受信したときに、絶対パス指定のＵＲＩがあれば、そのＵＲＩ全体を記憶部１４に格納する。

ここで、付加データについて説明する。図２Ａは、付加データを含むＵＲＩの一例を示す。同図のＵＲＩは絶対パス指定のＵＲＩである。しかしながら、同図のＵＲＩには、現実の絶対パスとは無関係の“ｎｉｎｓｈｏ／ｘｘｘｘｘ／”という文字列を含んでいて、いわば見かけ上の絶対パス指定である。現実の絶対パスは、“ｎｉｎｓｈｏ／ｘｘｘｘｘ／”を除いた図２Ｂに示すＵＲＩである。ここで、“ｎｉｎｓｈｏ／”と、次の“／”までの文字列、つまりこの例では“ｎｉｎｓｈｏ／ｘｘｘｘｘ／”が付加データである。ここで、付加データに含まれる“ｎｉｎｓｈｏ”は、付加データであることを示す識別子であり、“ｘｘｘｘｘ”は、クライアント１０とサーバ３０との間に確立されたセッションを識別するための認証キーである（詳細については後述する）。すなわち、本実施形態では、付加データを絶対パス指定のＵＲＩに埋め込んでいる。

Ｗｅｂブラウザ１２の説明に戻ると、上述のように、サーバ３０から受信したＨＴＭＬファイルに付加データを含む絶対パス指定のＵＲＩが含まれるときは、Ｗｅｂブラウザ１２は、そのＵＲＩ全体、付加データあるいは付加データに含まれる認証キーの文字列を記憶部１４に記憶する。

さらに、Ｗｅｂブラウザ１２は、サーバ３０から受信したＨＴＭＬファイルに、付加データを含まない相対パス指定のＵＲＩがあれば、そのＵＲＩに記憶部１４に記憶されている認証キーを含む付加データなどを付加して、認証キーを含む絶対パス指定ＵＲＩを生成する。そして、サーバ３０に対しては、付加データを含む絶対パス指定のＵＲＩが送られる。

付加データを含むＵＲＩは、見かけ上の絶対パス指定であり、そのままでは所定のコンテンツにアクセスすることはできない。従って、後述するように、付加データを含むＵＲＩを受け付けたサーバ３０は、そのＵＲＩから付加データを取り除いて、通常の絶対パスＵＲＩに変換してから、その通常の絶対パスでのリクエストとして、内部的に処理し直す。

サーバ３０は、例えば汎用的なコンピュータシステムにより構成され、以下に説明するサーバ３０内の個々の構成要素または機能は、例えば、コンピュータプログラムを実行することにより実現される。

サーバ３０は、ユーザ情報記憶部３１と、ログイン処理部３２と、認証情報記憶部３４と、Ｗｅｂサーバ３６とを有する。

ユーザ情報記憶部３１は、本システムの正規ユーザとして予め登録されたユーザに関する情報を記憶する。ユーザ情報記憶部３１には、例えば、各ユーザのユーザＩＤ及びパスワードなどのログイン認証のための情報、及び各ユーザがアクセスできるデータの範囲を示すアクセス権限に関する情報などが記憶されている。

ログイン処理部３２は、クライアント１０からのログイン要求を受け付けて、ユーザ情報記憶部３１を参照してそのログイン要求を許可するか否かを判定する。例えば、ログイン処理部３２は、ログインを許可したときは、そのログイン要求に係るクライアント１０とのセッションを識別するための認証キーを生成する。ログイン処理部３２は、さらに、ログインを許可したユーザのアクセス権限情報をユーザ情報記憶部３１から取得する。ログイン処理部３２は、生成した認証キー及びログインを許可したクライアント１０を利用するユーザのアクセス権限情報を認証情報記憶部３４に格納する。

認証情報記憶部３４は、ログインが許可されたユーザのアクセス権限に関する情報と、そのユーザが使用するクライアント１０に対する認証キーとを対応付けて記憶する。

ここで、アクセス権限情報について説明する。本実施形態では、各ユーザのアクセス可否の設定は、ロケーション単位に行うことができる。つまり、本実施形態では、実ディレクトリ及びＵＲＩパスのどちらでもアクセス制御を行うことができる。例えば、ＵＲＩパスとして、ＳｅｒｖｌｅｔなどのＷｅｂアプリケーション、または外部サーバのリクエストを返すことのできるＰＲＯＸＹ機能など、実体のないものを指定することができる。

Ｗｅｂサーバ３６は、ログイン処理部３２でログインが許可されたクライアント１０からのリクエストを受けて、所定の処理を実行して、その結果をレスポンスとして返す。例えば、プロトコルにＨＴＴＰを利用する場合、Ｗｅｂサーバ３６としてＡｐａｃｈｅを利用することができる。以下の実施形態では、Ｗｅｂサーバ３６としてＡｐａｃｈｅを利用した場合を例にとり説明する。

Ｗｅｂサーバ３６には、その内部機能としては、認証キー抽出部３８と、認証処理部４０と、Ｗｅｂページ生成部４２と、ＣＧＩ処理部４４と、ファイル出力部４６とが実現される。Ｗｅｂサーバ３６としてＡｐａｃｈｅを利用した場合、認証キー抽出部３８、認証処理部４０、Ｗｅｂページ生成部４２、ＣＧＩ処理部４４及びファイル出力部４６は、それぞれハンドラとして実装される。

認証キー抽出部３８は、クライアント１０から受け付けたリクエストの中に、付加データを含む絶対パス指定のＵＲＩが含まれるときは、そのＵＲＩの付加データに含まれる認証キーを抽出する。例えば、認証キー抽出部３８は、付加データを含む絶対パス指定のＵＲＩ（図２Ａ参照）からその付加データを切り取り、付加データを含まない通常の絶対パス指定のＵＲＩ（図２Ｂ参照）を生成するとともに、付加データから認証キーを抽出する。認証キー抽出部３８は、付加データを含む絶対パス指定のＵＲＩから付加データを含まない通常の絶対パス指定のＵＲＩを生成した後、その通常の絶対パス指定のＵＲＩに抽出した認証キーを付加したリクエストをＷｅｂサーバ３６に対して発行する（インターナルリダイレクト）。認証キー抽出部３８が発行するこのリクエストは、Ｗｅｂサーバ３６によって、ログイン認証がされたクライアント１０からのリクエストと同じように処理される。一方、認証キー抽出部３８は、クライアント１０から受け付けたリクエスト、あるいは自身がインターナル理大レストしたリクエストの中に、付加データを含む絶対パス指定のＵＲＩが含まれていないときは何も処理を行わず、ＤＥＣＬＩＮＥＤを発行して処理を終了する。

Ａｐａｃｈｅのハンドラフェーズでは、いずれかのハンドラがＤＥＣＬＩＮＥＤ以外を出力すれば、そのリクエストに対する処理を終了する。例えば、いずれかのハンドラが処理を正常終了して、ＤＥＣＬＩＮＥＤではない正常終了を示す返却値を出力すれば、Ａｐａｃｈｅは処理を終了する。

認証処理部４０は、認証キー抽出部３８でＤＥＣＬＩＮＥＤが発行されたリクエストに対して認証処理を行う。例えば、認証キー抽出部３８がＤＥＣＬＩＮＥＤを発行したときのリクエストが、ＵＲＩに認証キーを付加したリクエストであれば、その付加されている認証キー（ここでは対象認証キーと呼ぶ）に基づいて認証を行う。例えば、認証処理部４０は、対象認証キーが認証情報記憶部３４に記憶されているか否かを判定する。認証処理部４０は、対象認証キーが認証情報記憶部３４に記憶されていないときは、対象認証キーに係るリクエストに対して応答することを許可せず、異常終了を示す返却値を出力して処理を終了する。一方、対象認証キーが認証情報記憶部３４に記憶されているときは、認証処理部４０は、認証情報記憶部３４から対象認証キーと対応付けられているアクセス権限情報を取得する。そして、認証処理部４０は、対象認証キーが付されている通常の絶対パス指定のＵＲＩのアクセス先が、取得したアクセス権限情報の範囲であればそのリクエストを許可し、ＤＥＣＬＩＮＥＤを発行して処理を終了する。

Ｗｅｂページ生成部４２は、認証処理部４０でＤＥＣＬＩＮＥＤが発行されたリクエストがＷｅｂページの生成要求であれば、ＵＲＩが示すコンテンツに基づいて、その要求に従ってＷｅｂページを生成する。Ｊａｖａ（登録商標）を用いる場合、Ｗｅｂページ生成部４２は、ＪＳＰ（Ｊａｖａ Ｓｅｒｖｅｒ Ｐａｇｅｓ）処理を行ってもよい。Ｗｅｂページ生成部４２は、Ｗｅｂページを生成したときは、正常終了を示す返却値を出力する。一方、Ｗｅｂページ生成部４２は、認証処理部４０でＤＥＣＬＩＮＥＤが発行されたリクエストがＷｅｂページの生成要求でないときは、何も処理を行わず、ＤＥＣＬＩＮＥＤを発行して処理を終了する。

ＣＧＩ処理部４４は、Ｗｅｂページ生成部４２でＤＥＣＬＩＮＥＤが発行されたリクエストがＣＧＩ処理を要求するものであるときは、ＵＲＩが示すコンテンツに基づいて、その要求に従ってＣＧＩ処理を行う。ＣＧＩ処理部４４がＣＧＩ処理を終了したときは、正常終了を示す返却値を出力する。一方、ＣＧＩ処理部４４は、Ｗｅｂページ生成部４２でＤＥＣＬＩＮＥＤが発行されたリクエストがＣＧＩ処理を要求するものでないときは、何も処理を行わず、ＤＥＣＬＩＮＥＤを発行して処理を終了する。

ファイル出力部４６は、ＣＧＩ処理部４４でＤＥＣＬＩＮＥＤが発行されたリクエストがＨＴＭＬなどのファイル出力を要求するものであるときは、ＵＲＩが示すコンテンツに基づいて、その要求に従ってファイル出力を行う。ファイル出力部４６がファイル出力処理を終了したときは、正常終了を示す返却値を出力する。

なお、Ｗｅｂサーバ３６が受け付けたリクエストは、Ｗｅｂサーバ３６内の各処理部３８〜４６のいずれかによって処理されるが、その処理を実行する優先順位は、高い方から、認証キー抽出部３８、認証処理部４０、Ｗｅｂページ生成部４２、ＣＧＩ処理部４４及びファイル出力部４６としてもよい。

ここで、本実施形態では、認証キー抽出部３８を備えることにより、Ｃｏｏｋｉｅを用いなくても、従来よりも簡易且つ正確なセッション管理を行うことができる。つまり、認証キー抽出部３８は、絶対パス指定のＵＲＩに埋め込まれた認証キーを抽出して、認証キーを含まない通常の絶対パス指定のＵＲＩを再合成して、再合成したＵＲＩに認証キーを添付してＷｅｂサーバ３６に対してインターナルリダイレクトするので、Ｗｅｂサーバ３６にとっては、Ｃｏｏｋｉｅを利用したリクエストと同等に取り扱うことができる。従って、認証処理部４０、Ｗｅｂページ生成部４２、ＣＧＩ処理部４４及びファイル出力部４６は、いずれも、一般的なＡｐａｃｈｅのハンドラでよい。

次に、本実施形態に係るＷｅｂサーバ３６の処理手順について、図３及び図４のフローチャートを用いて説明する。

まず、Ｗｅｂサーバ３６がリクエストを受け付けると（Ｓ１０）、認証キー抽出部３８がそのリクエストに含まれるＵＲＩが、付加データを含む絶対パス指定のＵＲＩであるか否かを判定する（Ｓ１２）。そして、そのリクエストに含まれるＵＲＩが付加データを含む絶対パス指定のＵＲＩである場合は（Ｓ１２：Ｙｅｓ）、認証キー抽出部３８は、その付加データから認証キーを抽出する（Ｓ１４）。認証キー抽出部３８は、さらに、付加データを含む絶対パス指定のＵＲＩから付加データを切り取り、通常の絶対パス指定のＵＲＩを再合成するととともに、その再合成した通常の絶対パス指定のＵＲＩに抽出した認証キーを付加して、Ｗｅｂサーバ３６に対して改めてリクエストを発行するインターナルリダイレクトを行う（Ｓ１６）。

一方、リクエストに含まれるＵＲＩが付加データを含む絶対パス指定のＵＲＩでない場合は（Ｓ１２：Ｎｏ）、認証キー抽出部３８は、ＤＥＣＬＩＮＥＤを発行して処理を終了する（Ｓ１８）。

次に、認証処理部４０が、認証キー抽出部３８でＤＥＣＬＩＮＥＤとなったリクエストについて、認証処理を行う（Ｓ２０）。この認証処理は、上述のように、認証キーによるセッションの認証とともに、アクセス権限に対する認証を行う。ここで、認証が不成功であれば（Ｓ２２：Ｎｏ）、エラー画面などのエラー情報を出力してＷｅｂサーバ３６としての処理を終了する（Ｓ２４）。一方、認証が成功であれば（Ｓ２２：Ｙｅｓ）、認証処理部４０は、ＤＥＣＬＩＮＥＤを発行して処理を終了する（Ｓ２６）。

次に、Ｗｅｂページ生成部４２が、認証処理部４０でＤＥＣＬＩＮＥＤとなったリクエストが、Ｗｅｂページ生成に係るリクエストであるか否かを判定する（Ｓ２８）。ここで、そのリクエストがＷｅｂページ生成に係るリクエストであるときには（Ｓ２８：Ｙｅｓ）、Ｗｅｂページ生成部４２がＷｅｂページ生成処理を行い、この処理が完了するとＷｅｂページ生成部４２は処理を終了する（Ｓ３０）。一方、そのリクエストがＷｅｂページ生成に係るリクエストでないときは（Ｓ２８：Ｎｏ）、Ｗｅｂページ生成部４２は、ＤＥＣＬＩＮＥＤを発行して処理を終了する（Ｓ３２）。

次に、ＣＧＩ処理部４４が、Ｗｅｂページ生成部４２でＤＥＣＬＩＮＥＤとなったリクエストがＣＧＩ処理に係るリクエストであるか否かを判定する（Ｓ３４）。ここで、そのリクエストがＣＧＩ処理に係るリクエストであるときには（Ｓ３４：Ｙｅｓ）、ＣＧＩ処理部４４がＣＧＩ処理を行い、この処理が完了するとＣＧＩ処理部４４は処理を終了する（Ｓ３６）。一方、そのリクエストがＣＧＩ処理に係るリクエストでないときは（Ｓ３４：Ｎｏ）、ＣＧＩ処理部４４は、ＤＥＣＬＩＮＥＤを発行して処理を終了する（Ｓ３８）。

最後に、ファイル出力部４６がファイル出力処理を行う（Ｓ４０）。

そして、ステップＳ２４，Ｓ３０，Ｓ３６，Ｓ４０の処理がそれぞれ終了したときは、Ｗｅｂサーバ３６は処理を終了する。

次に、本実施形態に係るクライアントサーバシステム全体の動作概要及び表示画面例について、図５及び図６の示すシーケンス図を用いて説明する。

まず、クライアント１０からサーバへログイン画面の取得リクエストが発行されると（Ｓ１１０）、サーバ３０は、このリクエストに対応するＨＴＭＬファイル２００をクライアント１０へ送信する（Ｓ１１２）。

クライアント１０では、Ｗｅｂブラウザ１２がＨＴＭＬ２００を解析して、ログイン画面３００を表示させる。Ｗｅｂブラウザ１２は、ユーザがこのログイン画面３００に入力したユーザＩＤ及びパスワードを含むログインリクエストをサーバ３０へ送信する（Ｓ１１４）。

サーバ３０では、ログイン処理部３２がこのログインリクエストに基づいてログイン処理を行う。そして、ログインが許可されると、ログイン処理部３２が認証キーを生成し、Ｗｅｂサーバ３６が付加データを含む絶対パス指定のＵＲＩを生成して、このＵＲＩを含むＨＴＭＬファイル２１０をクライアント１０へ送信する（Ｓ１１６）。

クライアント１０では、Ｗｅｂブラウザ１２がＨＴＭＬ２１０を解析して、インタフェース画面３１０を表示させる。Ｗｅｂブラウザ１２は、これとともに、ＨＴＭＬ２１０中の付加データを含む絶対パス指定のＵＲＩを記憶部１４に格納する。ここで、ユーザが画面３１０に表示されている、ハイパーリンクが設定されている“トップ画面へ”を選択すると、付加データを含む絶対パス指定のＵＲＩの取得リクエストがサーバ３０へ送信される（Ｓ１１８）。

サーバ３０では、Ｗｅｂサーバ３６が上述したような処理手順により、付加データを含む絶対パス指定のＵＲＩから付加データを切り取る。そして、Ｗｅｂサーバ３６が通常の絶対パス指定ＵＲＩを再合成したのち、インターナルリダイレクトにより、再度リクエストを発行する。Ｗｅｂサーバ３６は、さらに付加データに含まれる認証キーを使って認証も行った後、再合成されたＵＲＩが示すＨＴＭＬファイル２２０を取得して、クライアント１０へ送信する（Ｓ１２０）。このとき、ＨＴＭＬファイル２２０中のＵＲＩは、付加データを含む絶対パス指定のＵＲＩではなく、通常の相対パス指定のＵＲＩである。

クライアント１０では、Ｗｅｂブラウザ１２がＨＴＭＬ２２０を解析して、インタフェース画面３２０を表示させる。ここで、ユーザが画面３２０に表示されている、ハイパーリンクが設定されている“次の画面へ”を選択すると、Ｗｅｂブラウザ１２は、記憶部１４から認証キーを取得して、ＨＴＭＬ２２０に記述されている相対パスＵＲＩに基づいて付加データを含む絶対パス指定のＵＲＩを生成する。そして、Ｗｅｂブラウザ１２は、ここで生成した付加データを含む絶対パス指定のＵＲＩの取得リクエストをサーバ３０へ送信する（Ｓ１２２）。

サーバ３０では、このリクエストに対しても同様に、Ｗｅｂサーバ３６が付加データを含む絶対パス指定のＵＲＩから付加データを切り取り、通常の絶対パス指定ＵＲＩを再合成したのち、インターナルリダイレクトにより、再度リクエストを発行する。さらに、Ｗｅｂサーバ３６は、付加データに含まれる認証キーを使って認証も行った後、所望のＵＲＩのＨＴＭＬファイル２３０を取得して、クライアント１０へ送信する（Ｓ１２４）。このとき、ＨＴＭＬファイル２４０中のＵＲＩも、ＨＴＭＬファイル２２０の場合と同様に、付加データを含む絶対パス指定のＵＲＩではなく、通常の相対パス指定のＵＲＩである。

クライアント１０では、Ｗｅｂブラウザ１２がＨＴＭＬ２３０を解析して、インタフェース画面３３０を表示させる。ここで、ユーザが画面３３０に表示されている、ハイパーリンクが設定されている“別のディレクトリへ”を選択したときも同様に、Ｗｅｂブラウザ１２は、記憶部１４から認証キーを取得して、ＨＴＭＬ２４０に記述されている相対パスＵＲＩに基づいて付加データを含む絶対パス指定のＵＲＩを生成する。そして、Ｗｅｂブラウザ１２は、ここで生成した付加データを含む絶対パス指定のＵＲＩの取得リクエストをサーバ３０へ送信する（Ｓ１２６）。これ以降、上記と同様の処理を行われる。

これにより、Ｃｏｏｋｉｅを利用せず、簡易且つ確実にセッション管理を行うことができる。さらに、Ａｐａｃｈｅを用いた場合、従来からある一般的なハンドラを活用することができる。

上述した本発明の実施形態は、本発明の説明のための例示であり、本発明の範囲をそれらの実施形態にのみ限定する趣旨ではない。当業者は、本発明の要旨を逸脱することなしに、他の様々な態様で本発明を実施することができる。

本発明の一実施形態に係るクライアント−サーバシステムの構成図である。 付加データを含むＵＲＩと含まないＵＲＩの例である。 本実施形態に係るＷｅｂサーバ３６の処理手順を示すフローチャートである。 本実施形態に係るＷｅｂサーバ３６の処理手順を示すフローチャートである。 本実施形態に係るクライアントサーバシステム全体の動作概要及び表示画面例を示す。 本実施形態に係るクライアントサーバシステム全体の動作概要及び表示画面例を示す。

符号の説明

１０ クライアント
１２ Ｗｅｂブラウザ
１４ 認証キー記憶部
３０ サーバ
３１ ユーザ情報記憶部
３２ ログイン処理部
３４ 認証情報記憶部
３６ Ｗｅｂサーバ
３８ 認証キー抽出部
４０ 認証処理部
４２ Ｗｅｂページ生成部
４４ ＣＧＩ処理部
４６ ファイル出力部

Claims (6)

1. ユーザ端末装置からのリクエストを受け付けて、前記受け付けたリクエストを処理するリクエスト処理手段を備え、
   前記リクエスト処理手段は、
   前記受け付けたリクエストに、認証キーが含まれている見かけ上の絶対パスを有する認証キー付き絶対パスＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）が含まれていれば、前記認証キー付き絶対パスＵＲＩから前記認証キーを抽出するとともに、前記認証キー付き絶対パスＵＲＩを、認証キーを含まない絶対パスを有する通常絶対パスＵＲＩに変換し、前記抽出された認証キーとともに、前記変換された通常絶対パスＵＲＩを含むリクエストを前記リクエスト処理手段に対して発行する認証キー抽出手段と、
   前記受け付けたリクエストに前記通常絶対パスＵＲＩとともに前記認証キーが含まれていれば、前記認証キーを用いて、前記通常絶対パスＵＲＩに係るコンテンツへのアクセスを許可するか否かを判定する認証処理手段と、
   前記認証処理手段によってアクセスが許可された前記通常絶対パスＵＲＩに係るコンテンツに基づいて、そのリクエストの内容に応じた処理を実行する処理実行手段とを備える情報処理装置。
2. 前記ユーザ端末装置からのログイン要求を受け付けて認証を行うログイン認証手段と、
   前記ログイン認証手段による認証が成功すると、その認証に係るセッションを識別するための識別情報として認証キーを生成する手段と、をさらに備え、
   前記認証キー付き絶対パスＵＲＩに含まれる認証キーは、前記認証キー生成手段で生成された認証キーである請求項１記載の情報処理装置。
3. 前記処理実行手段は、
   Ｗｅｂページの生成処理を行う手段、ＣＧＩ処理を行う手段及びファイル出力を行う手段のうちのいずれか一つ以上であることを特徴とする請求項１または２に記載の情報処理装置。
4. ユーザ端末装置からのリクエストを受け付けて、前記受け付けたリクエストを処理するリクエスト処理手段を有する情報処理装置において、前記リクエスト処理手段がユーザ端末装置からのリクエストを処理する方法であって、
   前記受け付けたリクエストに、認証キーが含まれている見かけ上の絶対パスを有する認証キー付き絶対パスＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）が含まれていれば、前記認証キー付き絶対パスＵＲＩから前記認証キーを抽出するとともに、前記認証キー付き絶対パスＵＲＩを、認証キーを含まない絶対パスを有する通常絶対パスＵＲＩに変換し、前記抽出された認証キーとともに、前記変換された通常絶対パスＵＲＩを含むリクエストを前記リクエスト処理手段に対して発行する処理と、
   前記受け付けたリクエストに前記通常絶対パスＵＲＩとともに前記認証キーが含まれていれば、前記認証キーを用いて、前記通常絶対パスＵＲＩに係るコンテンツへのアクセスを許可するか否かを判定する処理と、
   前記認証処理手段によってアクセスが許可された前記通常絶対パスＵＲＩに係るコンテンツに基づいて、そのリクエストの内容に応じた処理を実行する処理と、を行う方法。
5. ユーザ端末装置からのリクエストを受け付けて、前記受け付けたリクエストを処理するリクエスト処理手段を情報処理装置に実現するためのコンピュータプログラムであって、
   前記リクエスト処理手段は、
   前記受け付けたリクエストに、認証キーが含まれている見かけ上の絶対パスを有する認証キー付き絶対パスＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）が含まれていれば、前記認証キー付き絶対パスＵＲＩから前記認証キーを抽出するとともに、前記認証キー付き絶対パスＵＲＩを、認証キーを含まない絶対パスを有する通常絶対パスＵＲＩに変換し、前記抽出された認証キーとともに、前記変換された通常絶対パスＵＲＩを含むリクエストを前記リクエスト処理手段に対して発行する処理と、
   前記受け付けたリクエストに前記通常絶対パスＵＲＩとともに前記認証キーが含まれていれば、前記認証キーを用いて、前記通常絶対パスＵＲＩに係るコンテンツへのアクセスを許可するか否かを判定する処理と、
   前記認証処理手段によってアクセスが許可された前記通常絶対パスＵＲＩに係るコンテンツに基づいて、そのリクエストの内容に応じた処理を実行する処理と、を行うことを特徴とするコンピュータプログラム。
6. クライアント及びサーバを備えたシステムにおいて、
   前記クライアントは、
   認証キーが含まれている見かけ上の絶対パスを有する認証キー付き絶対パスＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）を生成する手段と、
   前記生成手段により生成された認証キー付きＵＲＩのリクエストを発行する手段と、を備え、
   前記サーバは、
   前記クライアントからのリクエストを受け付けて、前記受け付けたリクエストを処理するリクエスト処理手段を備え、
   前記リクエスト処理手段は、
   前記受け付けたリクエストに前記認証キー付き絶対パスＵＲＩが含まれていれば、前記認証キー付き絶対パスＵＲＩから前記認証キーを抽出するとともに、前記認証キー付き絶対パスＵＲＩを認証キーを含まない絶対パスを有する通常絶対パスＵＲＩに変換し、前記抽出された認証キーとともに、前記変換された通常絶対パスＵＲＩを含むリクエストを前記リクエスト処理手段に対して発行する認証キー抽出手段と、
   前記受け付けたリクエストに前記通常絶対パスＵＲＩとともに前記認証キーが含まれていれば、前記認証キーを用いて、前記通常絶対パスＵＲＩに係るコンテンツへのアクセスを許可するか否かを判定する認証処理手段と、
   前記認証処理手段によってアクセスが許可された前記通常絶対パスＵＲＩに係るコンテンツに基づいて、そのリクエストの内容に応じた処理を実行する処理実行手段とを備えるクライアントサーバシステム。

Images