CSP ゲートウェイの動作と構成

CSP ウェブゲートウェイ管理ページのローカライズ

CSP ウェブゲートウェイ管理ページのローカライズは、インストールされた CSPres.xml があれば、この内容に基づきます。ローカライズ・ファイルが存在しない場合、CSP ウェブゲートウェイ管理ページでは、既定で埋め込み英語テキストが使用されます。ブラウザの言語設定はこのメカニズムに影響しません。

代替言語は、ゲートウェイのホーム・ディレクトリにある適切なテキスト・リソース・ファイル (ファイル名 CSPres.xml) をインストールすることによってサポートできます。 ゲートウェイが起動 (または再起動) されると、CSPres.xml にあるテキスト・リソースがロードされ、管理フォームが選択した言語で表示されます。

CSPres.xml ファイルを作成するには、Caché bin ディレクトリの該当する CSPres_xx.xml ファイルの名前を CSPres.xml に変更します。

例えば、スペイン語に変換するには、以下のようにします。

1. CSPres_es.xml を CSPres.xml に変更します。

2. Web サーバを再起動します(言語テキストは指定された Web サーバの CSP モジュールに影響するため。再起動する必要があります)。

英語 (既定) に戻すには、以下のようにします。

1. CSPres.xml を CSPres_es.xml　に戻します。

2. Web サーバを再起動します。

CSP ウェブゲートウェイ管理ページでのセキュリティの考慮事項

既定では、ゲートウェイのホスト・コンピュータの管理下にあるクライアントのみが CSP ウェブゲートウェイ管理ページにアクセスできます。ブラウザ経由で管理フォームへアクセスする場合、そのブラウザは、Web サーバおよび CSP ゲートウェイと同じマシン上で実行されている必要があります。次に例を示します。

http://localhost:<port_no>/csp/bin/Systems/Module.cxw

承認された管理者のリストにクライアントを追加するには、CSP.ini (C:\Intersystems\Cache\CSP\bin) の SYSTEM セクションにある System_Manager パラメータにクライアントの IP アドレスを追加します。System_Manager パラメータには、CSP ウェブゲートウェイ管理ページへのアクセスを許可するクライアントの IP アドレスをコンマ (,) またはプラス記号 (+) で区切って指定します。以下の指示文は、既定のローカル・アクセスに加え、3 つのリモート・クライアントにアクセスを許可します。

[SYSTEM]
System_Manager=190.8.7.6, 190.8.7.5, 190.8.7.4

ゲートウェイの新規インストールにおいて、対応可能なローカル・ブラウザがない場合は、CSP.ini を編集してこの構成設定を手動で作成します。

CSP.ini の System_Manager パラメータは、CSP ウェブゲートウェイ管理ページの [デフォルトパラメータ] セクションにある [システム管理マシン] の設定と同じです。[システム管理マシン] パラメータのエントリには、ワイルドカードと数値域を指定できます。

以下の例は、IP アドレスの最後の部分が 4 ～ 6 の数値となることを示しています。

[SYSTEM]
System_Manager=190.8.7.4-6

上記の例は、以下の記述をより簡単にしたものです。

[SYSTEM]
System_Manager=190.8.7.6, 190.8.7.5, 190.8.7.4

以下の例のように、ワイルドカードも使用できます。

[SYSTEM]
System_Manager=190.8.7.*

以下の指示文は、すべてのクライアントにアクセス権を付与します。

[SYSTEM]
System_Manager=*.*.*.*

ただし、オペレーティング・システムでこのような指示文を使用することはお勧めしません。

CSP ウェブゲートウェイ管理ページを保護する手段としてのこの方法にはいくつかの短所があります。この方法では強力なセキュリティを実現できません。Web クライアントをチェックするために、クライアントの IP アドレスが CGI 環境変数 REMOTE_ADDR から取得されます。クライアント IP アドレスはスプーフィングが可能です。

クライアントと Web サーバ/ゲートウェイ間でプロキシを使用すると、事実上すべてのクライアントの IP アドレスがプロキシの IP アドレスに変換されます。この場合、Gateway Systems Manager としてプロキシの IP アドレスを指定して、Systems Manager がプロキシ経由で接続するすべての Web ユーザにアクセス権を付与するようにするか、指定した Systems Manager がプロキシ層を完全にバイパスするように設定する (推奨の設定) 必要があります。

IP 方式は防御の第一段階としては有効ですが、CSP ウェブゲートウェイ管理ページへのアクセスを制御する手段としてはこれだけでは不十分です。明らかに、インターネット経由で利用する CSP には適していません。プロダクション・システムでは、ホスト Web サーバの構成を使用して、ゲートウェイのシステム管理モジュールへのアクセスを制御することをお勧めします。

システム・ステータスの確認

[システムステータス] オプションには、すべてのアクティブな CSP 接続のステータスが表示されます。この機能を使用するには、システム管理者であることが必要です。以下の各表では、列見出しをクリックするとその列を基準にして並べ替えることができます。

最初のステータス・テーブル (Caché への接続) には、Caché への接続に関する情報が表示されます。

2 番目のステータス・テーブル (Caché サーバ) には、Caché に関する情報が表示されます。

3 番目のステータス・テーブルはアプリケーション・パスの情報を表示します。

4 番目のステータス・テーブルには、NSD の内部情報が表示されます。このテーブルは、NSD インストール、またはゲートウェイの応答キャッシュ機能を使用するインストールにのみ表示されます。

手動による接続の切断

CSP 接続がまだアクティブなときに Caché システムが停止した場合、以下のいずれかの状況になるまで、CSP は引き続きシステムに接続しようとします。

• システムへの再接続が成功する。

• CSP が停止する。

• 手動で接続を閉じる。

長時間にわたる Caché システムのダウンタイムを予定している場合は、以下のオプションから接続を閉じることができます。手動でセッションを閉じるには、以下の手順を実行します。

1. ウェブゲートウェイ管理のメイン・メニューから、[接続を閉じる] を選択します。

2. 切断したいサーバを選択します。* (アスタリスク) を選択すると、すべてのサーバへ　のすべての接続を閉じることができます。

3. [接続を閉じる] を選択します。

Caché システムの停止中に接続を閉じることができます。

サーバ接続のテスト

CSP ウェブゲートウェイ管理ページのメニューにある [サーバ接続のテスト] オプションは、Caché システムへの CSP ゲートウェイの接続をテストする際に役立ちます。この機能を使用するには、システム管理者であることが必要です。

CSP 接続をテストするには、以下の手順を実行します。

1. ウェブゲートウェイ管理のメイン・メニューから、[サーバ接続のテスト] を選択します。

2. 表示されたリストから、該当する Caché システムを選択します。

3. Caché サーバ上の CSP エラー・ログを表示するには、[サーバ上のイベントログを参照] を選択します。

4. [接続] を選択します。

選択した内容とサーバ接続の状態に応じて、以下のいずれかの結果が表示されます。

どのような場合でも、エラー状況が返された場合は、イベント・ログで追加および具体的なエラー情報を確認します。必要に応じ、ログ・レベルを上げて、追加の診断情報を取得することを検討してください。

イベント・ログの参照

メイン・メニューから [イベントログを参照] オプションを使用して、イベント・ログの内容を確認します。

既定では、日毎のログ・エントリ CSP.log の名前は CSP.log.old に変更されます。日付と時刻を使用した名前のファイルのすべてのログを保存するには、[デフォルトパラメータ] ページの[すべてのログ・ファイルを残す] にチェックを付けます。各ログ・エントリには、そのログ・エントリが作成された日付、時刻および追加情報を記録したヘッダ・レコードが表示されています。

以下はその例です。

>>> Time: Wed Jul 26 15:40:57 2006; RT Build: 664.896 (win32/isapi);
Log-Level: 9; Thread-Id: 2236; Connection-No: 0; Server: LOCAL;
Server-PID: 3028; Page: GET /csp/samples/menu.csp 

イベント・ログから現在のすべてのエントリを消去するには、[ログをクリア] を選択します。

ログは日付/時刻の昇順 (既定) または降順で表示できます。 フォームの右上隅にあるハイパーリンクを選択すると表示順が逆になります。 このハイパーリンクには、2 つのモードを切り替える役割があります。

最後に、ほとんどのブラウザでは、1MB ほどを超えるログ・データを 1 つのフォームで表示することはできません。 このため、返されるログ・データの容量が 1MB に達するとゲートウェイは表示を終了し、次ページのデータを表示するようユーザに指示します (フォームの左下隅にある [次] ハイパーリンクを参照)。 また、フォームの右下隅にある [トップ] ハイパーリンクを使用すると、一連のフォームのうち最初のフォームにすばやく戻ることができます。

HTTP トレース機能の使用法

HTTP トレース機能は、ログ・レベル v9 (未処理の HTTP 要求を記録) および v9r (HTTP 要求および応答を記録) で既に収集されているイベント・ログ情報がベースとなります。トレースには [HTTP トレースを表示] オプションからアクセスします。

トレース・ウィンドウは 2 つの主なフレームから構成されています。左側のフレームには、ゲートウェイで処理された HTTP 要求のリストがあり、時刻と (ゲートウェイから割り当てられた) 一意の要求 ID が示されます。それぞれの要求を選択すると、要求および応答データが右側のフレームに表示されます。ハイパーリンクにより、要求メッセージと応答メッセージの表示を簡単に切り替えることができます。

要求のリストは、数秒 (現行では 7 秒) おきに自動的に更新されます。このため、TCPTrace などのプロキシとほぼ同様のリアルタイム監視操作による全体的な効果が得られます。

既定のパラメータの構成

CSP ウェブゲートウェイ管理ページ・メニューの [デフォルトパラメータ] オプションでは、CSP ゲートウェイのグローバルな (システム全体の) 構成パラメータを管理するメカニズムが提供されます。このオプションを使用するには、システム管理者であることが必要です。

特定の Caché サーバへのアクセスを構成する場合、指定していないオプションのパラメータやカスタム・システム・フォームはグローバル構成から自動的に継承されます。例えば、特定のサーバに [サーバ応答タイムアウト] のパラメータを設定していない場合でも、そのサーバはグローバルな [サーバ応答タイムアウト] の設定を継承します。

既定のパラメータは、以下の 3 種類で構成されています。

1. CSP ゲートウェイ

2. セキュリティ

3. Caché への接続

4. ASP リダイレクト

5. 内部 HTTP サーバ (NSD ビルドのみ)

6. カスタム・エラー・メッセージ

セキュリティ

ここでユーザ名とパスワードを定義しておくと、すべてのシステム管理者は CSP ウェブゲートウェイ管理ページにアクセスする際に、このユーザ名とパスワードを入力する必要があります。

パスワードを忘れた場合は、ゲートウェイの構成ファイル CSP.ini を手動で編集して、SYSTEM セクションから Username パラメータと Password パラメータを削除します。これで、ユーザ名とパスワードなしで CSP ウェブゲートウェイ管理ページにアクセスでき、必要に応じて新しいユーザ名とパスワードを入力できます。

[SYSTEM]
Username=cm
Password=1Bx4tt88mttAWaf7isJg3Urqc2zE

以下の CSP セキュリティ・パラメータを構成できます。

[このフォームにアクセス]

このオプションを使用して、CSP ウェブゲートウェイ管理ページへのアクセスを有効または無効にすることができます。既定は [有効] です。アクセスが [無効] である場合、CSP ウェブゲートウェイ管理ページを使用して、アクセスを再度有効にすることはできません。アクセスを再度有効化するには、構成ファイル CSP.ini を手動で編集します。このファイルの SYSTEM セクションで、SM_Forms パラメータを Enabled に設定します。

[SYSTEM]
SM_Forms=Enabled

[ユーザ名]

CSP ウェブゲートウェイ管理ページへのアクセスに必要なユーザ名です。

[パスワード]

CSP ウェブゲートウェイ管理ページへのアクセスに必要なパスワードです。

[パスワード (確認)]

パスワードを修正する場合、ここで新しいパスワードを確認入力します。

[セッション・タイムアウト]

アクティブなシステム管理セッションがログオン状態になっているアイドル時間 (秒)。この時間が経過すると、管理セッションの有効期限が切れ、管理者は CSP ウェブゲートウェイ管理ページから自動的にログアウトします。

[システム管理マシン]

これらのシステム管理オプションにアクセスできるクライアント・マシンの IP アドレスのリストを定義します。システム管理者のアクセス権を持つクライアントは、CSP システムへのアクセスの追加や削除、構成ファイル内の設定の変更、およびアクティブなセッションを閉じる操作が可能です。各アドレスは、コンマまたはプラス記号で区切ります。以下の例では、2 つのクライアントにシステム管理者のアクセス権があります。

127.0.0.1, 45.123.231.12

このフィールドを定義しない場合、CSP ゲートウェイと同じマシンで動作しているクライアント (Web サーバのホスト) のみが CSP を構成できます。

このフィールドには、[ユーザ名とパスワードをオーバーライド] というチェック・ボックスも用意されています。チェック・ボックスにチェックを付けると、リストされているクライアント・マシンから管理フォームにアクセスするときにユーザ名やパスワードを入力しなくても済むようになります。

カスタム・ログイン・フォーム

ゲートウェイ管理スイートへのアクセスを制御するカスタム・ログイン・フォームを定義します。このパラメータは、物理ファイルまたはフォームを処理するホスト Web サーバを有効にするリンクへのフル・パスにすることができます。

例 ：

 C:\Inetpub\wwwroot\login.html
 /login.html    

物理ファイル名が指定されている場合、ゲートウェイはフォームを取得してクライアントに送信します。 そうでない場合、'HTTP リダイレクト' 応答ヘッダを送信して、クライアントがホスト Web サーバから直接フォームを要求できるようにします。 カスタム・フォームでゲートウェイ管理者がログインするには、HTTP POST 要求を実装する必要があります。

必須フォーム・フィールドは以下のとおりです。

<FORM METHOD=POST ACTION="/csp/bin/Systems/Module.cxw">
<INPUT TYPE=HIDDEN NAME="CSPSYS" VALUE="17">
<INPUT TYPE=HIDDEN NAME="CSPSYSsmSection" VALUE="SYSTEM">
<INPUT TYPE=TEXT NAME="CSPUNM" SIZE='20' VALUE="">  
<INPUT TYPE=PASSWORD NAME="CSPPWD" SIZE='20' VALUE=""> 
<INPUT TYPE=SUBMIT NAME="CSPSYSbOK" VALUE="Login"> 

ここで、CSPUNM はユーザ名で、CSPPWD はパスワードです。 ログイン (送信) ボタン (上記で 'Login' として表示) に割り当てられるテキストは変更可能です。

単純ですが完全な例を以下に示します。

<html>
<head>
<title>CSP Gateway Management</title>
</head>
<h2>CSP Gateway Management</h2>
<FORM METHOD=POST ACTION="/csp/bin/Systems/Module.cxw">
<INPUT TYPE=HIDDEN NAME="CSPSYS" VALUE="17">
<INPUT TYPE=HIDDEN NAME="CSPSYSsmSection" VALUE="SYSTEM">
<BR>
Username: 
<INPUT TYPE=TEXT NAME="CSPUNM" SIZE='20' VALUE="">
<BR>
Password:
<INPUT TYPE=PASSWORD NAME="CSPPWD" SIZE='20' VALUE="">
<BR>
<INPUT TYPE=SUBMIT NAME="CSPSYSbOK" VALUE="Login">
</form>
</html>

Caché への接続

このセクションでは、Caché への接続の維持に関連するパラメータについて説明します。

[サーバ応答タイムアウト]

ターゲットの Caché サーバが Web サーバからの要求に応答できるまでの最大許容時間 (秒)。タイムアウトとは、アクティビティのない時間のことです。例えば、HTML データの行を毎秒 10 時間送信していれば、タイムアウトは発生しません。このフィールドに入力できる最小値は 5 秒です。

ここで設定した値がシステムの既定値です。継承値が指定されていない場合、値は [デフォルトパラメータ] ページから取られます。ただし、サーバ固有の構成またはアプリケーション自体で別の値を設定できます。

Apache サーバがある場合は、Apache http.conf ファイルの Timeout を使用してこの値を設定できますので注意してください。これら 2 つのうち値の低い方が最初にトリガされます。

[キューイングされたリクエストのタイムアウト]

要求が、該当する Caché システムへの使用可能な接続をキュー内で待機できる最大時間 (秒)。入力できる最小値は 5 秒です。 継承値が指定されていない場合、値は [デフォルトパラメータ] ページから取られます。

[無使用タイムアウト]

このパラメータが該当するのはステートレス接続のみです。このパラメータは、ステートレス接続が開いたままのアイドル状態から閉じるまでの最大時間 (秒) を示します。このタイムアウトを超えると、セッションは自動的に閉じます。この機能を使用すると、Caché サーバにステートレス・セッションが蓄積されません。特に、負荷の増加に対応するために多数の接続が開かれた高アクティビティ期間の後でも、ステートレス・セッションが蓄積されません。この値を指定しない場合は、手動で閉じるまでステートレス接続は開いたままです。 継承値が指定されていない場合、値は [デフォルトパラメータ] ページから取られます。

[すべての接続にタイムアウトを適用]

[無使用タイムアウト] オプションを (最小の接続プール構成を含む) すべての接続に適用します。 このオプションにチェックを付けていない場合、ゲートウェイは [無使用タイムアウト] を最小の接続プール ([サーバ接続最小数] パラメータにて定義) に適用しません。 このオプションにチェックを付けている場合、ゲートウェイはタイムアウトをプールの接続すべてに適用します。 このオプションは、CSP の使用率がきわめて低いインストール環境で使用するものであり、その結果として、すべての CSP プロセスでタイムアウトよりもこのオプションが優先します。 継承値が指定されていない場合、値は [デフォルトパラメータ] ページから取られます。

[イベントログレベル]

イベント・ログに書き込まれる情報を制御します。詳細は、“イベント・ログ・パラメータ” のセクションを参照してください。

[イベントログファイル]

イベント・ログ・ファイル (CSP.log) の場所を指定します。指定しない場合、ログはゲートウェイのインストール環境をホストするディレクトリに書き込まれます。例えば、以下のようになります。

CSP.log に代替の場所を指定するには ：

/opt/logfiles/cspgateway/

イベント・ログの代替位置およびファイル名を指定するには ：

/opt/logfiles/cspgateway/event_log_01012006.log

[すべてのログ・ファイルを残す]

既定では、Caché は、CSP.log ファイルを CSP.log.old という名前のファイルにコピーします。 その後のログのローテーションによって、CSP.log.old は、イベント・ログの現在の内容に上書きされます。すべてのログ・ファイルを残すには、このように毎日上書きする代わりに、[すべてのログ・ファイルを残す] にチェックを付けます。このオプションを有効にすると、日々のログは、CSP_YYYYMMDD_hhmm.log のように日付と時刻を使用した名前が付けられます。

[イベント・ログのローテーション・サイズ]

このパラメータには、ログのローテーションが開始されるサイズを定義します。既定値は空白です。これは実際には、ゲートウェイが 1 つのログ・ファイルを管理し、管理者がそのファイルを手動で消去するまでファイルのサイズが増えることを意味します。

バイト単位	n
キロバイト単位	nK
メガバイト単位	nM

指定可能な最小サイズは 100K です。この値は、管理者が管理スイートでこれよりも低い値を設定しようとすると自動的に設定されます。

ローテーションされたログ・ファイルのコピーは、保持される場合、ローテーションの日付と時刻に応じて以下のように名前が付けられます。

CSP_YYYYMMDD_hhmm.log

YYYY	年
MM	月
DD	その月の日
hh	その日の時間
mm	その時間を経過した分

以下はその例です。

CSP_20090109_1830.log (Log rotated at 18:30 on 9th January 2009)

保持されないローテーションされたログ・ファイルには、CSP.log.old という名前が付けられます。

この機能を使用するには、ゲートウェイ・バイナリ (つまり、メインのログ・ファイルが格納されている場所) をホストするディレクトリに対するゲートウェイの作成/書き込みアクセス権が必要です。 ゲートウェイが正常にローテーションを実行できない場合は、その理由にかかわらず、現行のログ・ファイルである CSP.log に対して書き込みが続けられます。

このフィールドには、[すべてのログ・ファイルを残す] というチェック・ボックスも用意されています。このチェック・ボックスにチェックを付けると、前述した名前付け方式に従ってすべてのログ・ファイルを保存するようゲートウェイに指示されます。 そうでない場合、CSP.log.old という名前の 1 つのローテーションされたファイルが保存されます。

[SSL/TLS ライブラリ・パス]

OpenSSL ライブラリ (libssl.so および libcrypto.so) へのパスを指定します。既定の位置をゲートウェイに対して設定して、そのホーム・ディレクトリにてこれらのライブラリをローカルに参照します。詳細は、このドキュメントの “erberos ライブラリ” セクションの “SSL を使用する場合のライブラリ・パスのオーバーライド” を参照してください。

[保持モード除外ファイルの種類]

静的ファイルがステート認識アプリケーションで非同期に処理されるようにします。 ステートレス・アプリケーションでは、静的 (csp、cls、csr、および zen 以外のファイル) はメイン・セッションに対して非同期に処理されます。 つまり、これらのファイルの要求はセッション・ロックをバイパスして、アプリケーションのメイン処理ストリームの外部で同時に処理できます。

このパラメータにより、この方式がステート認識アプリケーションにも拡張されます。 ステート認識アプリケーションは、従来のセッション・ロックだけでなく、CSP ゲートウェイ内の接続ロックの対象にもなります。 接続ロックは、ユーザ/セッションに対するすべての要求が、同じ Cache プロセスに確実にルーティングされるようにします。 Cache から処理される静的コンポーネントに依存するアプリケーションの場合、これによって過剰な要求がキューイングされ、結果としてブラウザの動作が不安定になる (停止など) 場合があります。

このパラメータを使用して、ファイルの種類 (拡張子ごと) のスペースで区切られたリストを定義し、非同期の処理を可能にして、ゲートウェイおよび Cache において接続/セッション・ロックから除外されるようにします。リストに *- (アスタリスクとハイフン) の接頭語が付けられている場合、以下のリストで定義されたものを除くすべてのファイルが非同期で処理されます。

例

Preserve Mode Exclude File Types=gif jpg jpeg  

ステート認識セッションに対して GIF、JPG、および JPEG の種類のファイルを非同期で処理します。

Preserve Mode Exclude File Types=*- csp cls csr zen  

ステート認識セッションに対して、CSP、CLS、CSR、および ZEN の種類を除くすべてのファイルを非同期で処理します。 なお、これはステートレス・アプリケーションに対して CSP エンジンで適用されるルールです。

このメカニズムは、ゲートウェイ・ログ・レベル 4 (v4) を使用して監視できます。 要求に対して起動されると、以下に示すようなレコードがログに追加されます。

 >>> Time: Fri Oct 04 14:56:40 2013 ...GET /csp/samples/zenutils.js       
     State-Aware Session (preserve == 1)     
     Process this request concurrently in the pool of state-less connections (File Type=js)

[内部HTTPサーバ]

このセクションは NSD にのみ関連します。

このセクションには、以下のパラメータが含まれます。

[サービス状態]

HTTP サーバは、[有効] または [無効] のいずれかに設定できます。以下のどちらかを選択します。

• 有効

• 無効

既定は [有効] です。

NSD が未処理の HTTP 要求に応答できるようにする場合を除き、セキュリティの面ではこの機能を無効にすることをお勧めします。

[NSDドキュメントルート]

NSD 自体をスタンドアロンの Web サーバとして使用する場合、このパラメータは Web ドキュメント・ルートの完全な物理パスを定義します。

以下はその例です。

/opt/cspgateway/home/

このサーバを使用して CSP アプリケーションを処理する場合は、ブローカ・コンポーネントを以下にインストールする必要があります。

/opt/cspgateway/home/broker/

CSP サンプルのサポートに使用する静的ファイルは以下のとおりです。

/opt/cspgateway/home/samples/

管理ポータルのサポートに使用する静的ファイルは以下のとおりです。

/opt/cspgateway/home/sys/

サーバ・アクセスの構成

[サーバ接続] オプションでは、以下が可能です。

• 指定した Caché サーバに対する CSP ゲートウェイのアクセスを構成します。

• 構成したサーバのエントリを別の名前にコピーします。これは新しいサーバを簡単に追加する方法です。

• 構成した Caché サーバへのアクセスを無効にする。

• 構成したサーバ・エントリを削除する。

• 新しいサーバを追加する。

CSP ゲートウェイからアクセスする各 Caché システムをここで定義する必要があります。指定していないオプションのパラメータやカスタム・システム・フォームは、CSP ゲートウェイのグローバル構成から自動的に継承されます。

アプリケーション・アクセスの構成

アプリケーション・アクセスの構成のオプションを使用すると、以下が可能です。

• CSP アプリケーションへのパスを構成します。

• アプリケーション・パスを別のパスにコピーします。これは新しいアプリケーション・パスを追加する簡単な方法です。

• アプリケーション・パスへのアクセスを無効化します。

• アプリケーション・パスを削除します。

• 新しいアプリケーション・パスを追加します。

CSP アプリケーションごとに、CSP ファイルへのパスを構成する必要があります。各パスの構成によって、アプリケーションの実行を扱う Caché サーバが識別されます。フェイルオーバーや負荷分散を指定するオプションの指示文を、アプリケーション・パスの構成で指定します。既定のアプリケーション・パス、root (/) は、CSP ゲートウェイを初めて起動するときに自動的に構成されます。継承がアプリケーション・パスに適用されます。例えば、CSP 要求が /Accounts/Invoices 内のファイルを要求したとき、/Accounts/Invoices の構成が存在しない場合、CSP ゲートウェイは /Accounts に定義された構成を使用します。これが定義されていない場合は、既定のパスである / に対する構成が使用されます。

[CSPゲートウェイについて] ページ

このページには、CSP ウェブゲートウェイ管理ページが表示されます。この情報には、Caché ディストリビューションのバージョン、ゲートウェイのビルド番号、ホスト Web サーバのバージョン、アクティブ・インターフェース、ゲートウェイ構成ファイル (CSP.ini) の名前と場所、およびイベント・ログの場所が含まれています。

以下はその例です。

Version: 2016.2.1.803.0 
Gateway Build: 1602.1573d
Web Server Name: localhost 
Web Server Type: Apache Web Server: Apache/2.4.10 (win32) Cache_Server_Pages-Apache_Module/2016.2.1.803.0-1602.1573d 
Active Interface: Apache Module 
Configuration: C:InterSystems/HealthShare_2/CSP/bin/CSP.ini
Event Log: C:?InterSystems/HealthShare_2/CSP/bin/CSP.log

ゲートウェイのセキュリティ・パラメータ

CSP ウェブゲートウェイ管理アプリケーションを使用して、以下のセキュリティ・パラメータを管理することができます。[構成] セクションで [サーバ接続] を選択し、サーバの編集、コピー、または追加を選択します。[接続セキュリティ] セクションでは、以下の設定ができます。

• [接続セキュリティレベル]：選択肢は以下のとおりです。

  • [パスワード]

  • [Kerberos]

  • [Kerberosパケット整合性]

  • [Kerberos暗号化]

  • SSL

• [ユーザ名]

• [パスワード]

• [製品]：選択肢は以下のとおりです。

  • [Caché]

  • [Ensemble]

• [サービス・プリンシパル名]

• [キーテーブル]

最小の接続セキュリティ

最小の接続セキュリティでは、[接続セキュリティレベル] が [パスワード] に設定され、[ユーザ名] フィールドおよび [パスワード] フィールドは空欄のままです。

このモードでは、ゲートウェイと Caché 間の接続に対して最小レベルのセキュリティが適用されます。この処理モードは、ゲートウェイの以前のバージョンを使用する場合 (追加のセキュリティ・パラメータがないインストール) の既定のシナリオです。比較的新しいバージョンのゲートウェイを使用して以前のバージョンの Caché (5.1 より前) に接続する場合の処理モードでもあります。

この処理モードの場合、CSP サービス (%Service_CSP) と、そのサービスが機能するユーザ名 (CSPSystem など) が、任意の形式の認証を要求していないかどうかを確認します。

ユーザ名ベースおよびパスワード・ベースの単純な認証

ユーザ名およびパスワードがベースの認証では、[接続セキュリティレベル] は [パスワード] に設定され、[ユーザ名] フィールドおよび [パスワード] フィールドが適用されます。

これは、ゲートウェイと Caché 間に適用できる最も簡単な認証形式です。

Caché のパスワードは、Caché で認証するプレーン・テキストとしてネットワーク上に送信されるので、セキュリティの面で脆弱な形式の認証であることに注意してください。簡単に実行可能なネットワーク・スニッフィングによって、これらのパスワードが盗まれる可能性があります。この構成オプションで使用するパスワードは、以下のガイドラインに従って、ゲートウェイの構成ファイル (CSP.ini) で保持する必要があります。

どのような場合でも、CSP ゲートウェイに使用する既定のユーザ名とパスワードは以下のようになります。インストール・プロセスでは、この目的のために CSPSystem ユーザが作成されます。このユーザ (CSPSystem またはその他のユーザ) には、有効期限を設定する必要はありません。つまり、有効期限プロパティの値は 0 になります。

Username: CSPSystem
Password: SYS

パスワードは、Microsoft のデータ保護 API (DPAPI) で提供される機能によって暗号化されます。このパスワードの暗号化は、CSP ウェブゲートウェイ管理ページで処理されます。

Web ゲートウェイ管理ページのコンテキスト以外でパスワードを扱うことが必要になる場合もあります。例えば、Web ゲートウェイ構成がカスタム構成スクリプトによって設定されている場合などです。この場合、パスワードをプレーン・テキストとして保存しておくと、Web ゲートウェイを初めて起動したときにこのパスワードが暗号化されます。

Web ゲートウェイをホストしている Web サーバは、暗号化の基礎となる使用可能なユーザ・プロファイルがない保護された環境内で稼動するため、ユーザ・ストアではなくマシン・ストアを使用する必要があります。したがって、他のコンピュータで暗号化された Web ゲートウェイ・パスワードを解読することはできません。これによって、CSP.ini ファイルが共有ドライブに配置され、複数の関係するコンピュータ間で共有されるクラスタ環境の状況が作り出されます。実際にパスワード暗号化を行うコンピュータのみが、これを解読できます。暗号化されたパスワードを含む CSP.ini ファイルを別のコンピュータに移動することはできません。パスワードは、新しいマシンで再入力および再暗号化される必要があります。

この問題に対して考えられるアプローチを以下に示します。

• クラスタ外のマシンを Web サーバとして使用する。

• フェイルオーバーするたびに、Web ゲートウェイで同じパスワードを再設定する。

• そのクラスタに属していないディスクに Web ゲートウェイ構成ファイル (CSP.ini) のコピーをそれぞれ独自に持つように、クラスタに属する各コンピュータを構成する。Caché が、Web ゲートウェイの DLL をホストするディレクトリにファイルを保持する。個々のコンピュータそれぞれにパスワードを保存し、暗号化したうえで、ノードをクラスタに導入する。

  例えば、各マシンの Disk C がクラスタに属さず、Caché が Disk S にインストールされている場合は、次のようになります。

  CLUNODE-1 ： CLUNODE-1 で暗号化したパスワード XXX を記述した C:\INSTANCEDIR\CSP\bin\CSP.ini

  CLUNODE-2 ： CLUNODE-2 で暗号化したパスワード XXX を記述した C:\INSTANCEDIR\CSP\bin\CSP.ini

• Web ゲートウェイを起動してパスワードを追加する前に、以下の指示文を CSP.ini ファイルに手動で追加することによって、パスワードの暗号化を無効にする。

         [SYSTEM]
         DPAPI=Disabled
  

パスワードは、プレーン・テキストとして CSP.ini に格納されています。ゲートウェイ (またはホスト Web サーバ) を操作するアカウントに構成ファイルの所有者を設定することで、構成ファイルへのアクセスを保護する必要があります。アクセス・モードを 600 に設定します。

パスワードは、プレーン・テキストとして CSP.ini に格納されています。ゲートウェイ (またはホスト Web サーバ) を操作するアカウントに構成ファイルの所有者を設定することで、構成ファイルへのアクセスを保護する必要があります。ファイル保護は、(s:rwed, o:rwed, g:, w:) に設定します。

Kerberos ベース認証とデータ保護

Kerberos ベース認証とデータ保護では、[接続セキュリティレベル] パラメータによって 3 種類の認証レベル (およびデータ保護) が提供されます。

1. Kerberos ： 接続に対する初期の認証のみを提供します。

2. Kerberos パケット整合性 ： 初期の認証を提供し、データ・パケットの整合性を保証します。

3. Kerberos 暗号化 ： 最高レベルのセキュリティです。初期の認証、データ・パケットの整合性の保証、および送信されるすべてのメッセージの暗号化を行います。

Kerberos ライブラリ

Kerberos ベースのいずれかのモードを使用する場合、ゲートウェイは次の InterSystems Kerberos クライアント・ライブラリをロードする必要があります。

• Windows DLL ： cconnect.dll

• UNIX® 共有オブジェクト ： cconnect.so

• OpenVMS 共有可能イメージ ： CCONNECT.EXE

オペレーティング・システムの PATH 環境変数に指定した場所、またはゲートウェイのインストール場所を基準にした以下のいずれかの場所に、適切なライブラリをインストールします。

• . (ゲートウェイのローカル)

• ./bin

• ../bin

• ../../bin

ゲートウェイはライブラリが初めて必要なときにそれをロードしようとします。ロードが成功すると、ステータス・メッセージ「CSP Gateway Initialization The CCONNECT library is loaded - Version: 5.3.0.175.0. (This library is used for the optional Kerberos-based security between the Gateway and Caché)」がイベント・ログに書き込まれます。

ゲートウェイが cconnect ライブラリを見つけられない場合や、リンクできない場合は、失敗を示す適切な説明やエラー・メッセージがイベント・ログに書き込まれます。

ゲートウェイと Caché 間の通信が Kerberos で保護されている場合は、ゲートウェイが Kerberos クライアントになります。

Kerberos を使用するようにゲートウェイを構成する手順については、以下の “Windows” および “UNIX および OpenVMS” の 2 つのセクションで説明します。

SSL を使用する場合のライブラリ・パスのオーバーライド

既定のゲートウェイでは、そのホーム・ディレクトリ (つまり、ゲートウェイ・バイナリを保持するディレクトリ) に依存セキュリティ・ライブラリ (共有オブジェクト) がインストールされることを想定しています。

ゲートウェイと Caché 間で SSL 接続を使用する場合、これらのライブラリとして CCONNECT ライブラリおよび SSL/TLS ライブラリ (libssl.so と libcrypto.so) があります。ゲートウェイおよび Web サーバの処理領域にロードされた CCONNECT ライブラリが SSL ライブラリのコピーをロードする場合、ホスト Web サーバによって以前にロードされた同じライブラリの異なるバージョン間で競合が発生します。SSL ライブラリの 1 つのコピーだけが Web サーバの処理領域にロードされるようにするには、ゲートウェイが CCONNECT ライブラリに対して、ホスト Web サーバで使用されているものと同じ場所から SSL ライブラリをロードするように指示する必要があります。

そのためには、ゲートウェイの構成ファイル (CSP.ini) の SYSTEM セクションで CCONNECT_LIBRARY_PATH パラメータを使用して、SSL ライブラリのパスを指定します。 このパラメータを変更したら、ホスト Web サーバを再起動してください。以下はその例です。

[SYSTEM] 
CCONNECT_LIBRARY_PATH=/lib/amd64/  

SSL ベース認証とデータ保護

SSL プロトコルを使用して、ゲートウェイと Caché 間の通信を保護できます。

このモードでは、ホストに構成された SSL 転送により Caché への接続が保護されます。 [SSL構成名] フィールドを、ターゲット・サーバに適切な値に設定する必要があります。 [サービスプリンシパル名] および [キーテーブル] フィールドは無関係なので、空白にしておく必要があります。

Caché システムの SSL クライアント構成の作成に関する詳細は、"Caché セキュリティ管理ガイド" の "SSL/TLS を使用して Caché に接続するための CSP ゲートウェイの構成" の章を参照してください。また、SSL ライブラリのパス設定について、このドキュメントの “Kerberos ライブラリ” セクションのサブセクション “SSL を使用する場合のライブラリ・パスのオーバーライド” も参照してください。

Internet Information Services

1. [インターネット サービス マネージャ] ウィンドウを開きます。

2. 左側のウィンドウで、[既定の Web サイト] を選択します。

3. [既定の Web サイト] を右クリックして、メニューから [プロパティ] を選択し、[既定の Web サイトのプロパティ] ウィンドウを表示します。

4. [ドキュメント] タブを選択します。

5. [追加] を選択して、[既定のドキュメント名の追加] ウィンドウを表示します。

6. [既定のドキュメント名] ウィンドウにドキュメント名 (/csp/samples/menu.csp) を入力します。

7. [OK] を選択します。

8. [既定のドキュメントを有効にする] チェック・ボックスが選択されていることを確認します。

9. [ディレクトリ] タブで、矢印キーを使用して、新しい既定のドキュメント (/csp/samples/menu.csp) をリストの一番上へ移動します。

10. [適用] および [OK] を選択して、すべての変更を保存して有効にします。

新しい既定ページ (/csp/samples/menu.csp) は、Web サーバのドキュメント・ルート・ディレクトリを基準とする場所に存在している必要があります。これが必要になるのは、空のファイルを作成するときだけです。例えば、ドキュメントのルートが c:\inetpub\wwwroot の場合は、次のように操作します。

cd c:\inetpub\wwwroot
md csp
cd csp
md samples
cd samples
copy con menu.csp
^Z

Sun の Web サーバ

このセクションで説明する手順は、ビルド 663.763 以降のゲートウェイのみを対象としています。

以下の指示文は、obj.conf の既定のセクションで、Sun サーバのホーム・ページを指定します。

NameTrans fn="home-page" path="/csp/samples/menu.csp"

ただし、この指示文では、CSP フォーム menu.csp がサーバのホームページになりません。 これは、サーバが CSP ゲートウェイへ制御を渡す前に、要求されたページを基準にして環境変数を更新しないためです。 ゲートウェイは、/csp/samples/menu.csp ではなく、 / に対する要求を受け取ったと解釈します。 Netscape ベースのサーバは、NSAPI 拡張によってこのシナリオが認識され、要求されたページを識別する変数とそのパスが更新されることを予期しています。この動作を回避する方法は次のとおりです。

1. obj.conf の既定セクションで CSP ホーム・ページを定義します。

   NameTrans fn="home-page" path="/csp/samples/menu.csp"

2. 次のように、CSP ファイルとゲートウェイ・モジュール間のマッピングを指定するセクションに home-page-path 指示文を追加します。

   <Object ppath="*/*.[Cc][Ss][Pp]">
   Service method=(GET|HEAD|POST) fn=csp_req home-page-path="/cache-install-dir/csp/samples" 
   </Object> \
   <Object ppath="*/*.[Cc][Ll][Ss]">
   Service method=(GET|HEAD|POST) fn=csp_req home-page-path="/cache-install-dir/csp/samples" 
   </Object> \
   <Object ppath="*/*.[Zz][Ee][Nn]">
   Service method=(GET|HEAD|POST) fn=csp_req home-page-path="/cache-install-dir/csp/samples"
   </Object> 
   <Object ppath="*/CSPn3Sys.so">
   Service method=(GET|HEAD|POST) fn=csp_req_sys
   </Object> 
   <Object ppath="*/CSPn3.so">
   Service method=(GET|HEAD|POST) fn=csp_req
   </Object>
   
   

   

Service 指示文内の home-page-path プロパティでホームページのパスを指定する必要はありません。ただし、このパスを指定すると、/csp/samples/menu.csp を直接要求した場合と同じ値が PATH_TRANSLATED 環境変数に渡されます。 つまり、以下のようなホームページ (/) の PATH_TRANSLATED が返されます。

/install-dir/csp/samples/inspector.csp

以下は返されません。

/csp/samples/inspector.csp

Apache サーバ

Apache 構成ファイルで DirectoryIndex 指示文を探します。次に例を示します。

DirectoryIndex index.html index.html.var

リストの先頭に、Web サーバの新しい既定ページを追加します。

DirectoryIndex /csp/samples/menu.csp index.html index.html.var

GZIP/ZLIB ライブラリのインストール

GZIP/ZLIB ライブラリは、以下のサイトからダウンロードできます。

http://www.zlib.net/Opens in a new tab

このリソースは、Jean-loup Gailly および Mark Adler (Copyright (C) 1995-2006) によって開発されました。

このライブラリは、ゲートウェイをサポートするすべてのプラットフォームに対して無償で利用できます。Windows の場合は DLL (zlib.dll)、UNIX® システムの場合は共有オブジェクトまたは共有ライブラリ (libz.so または libz.sl) として実装されます。また、OpenVMS では、共有可能なイメージとして ZLIB ライブラリを利用できます。libz.so (または libz.sl) ライブラリは、通常、すべての Linux システムに事前にインストールされています (通常、/usr/lib/ または /usr/local/lib にインストールされます)。

ゲートウェイは、初めて応答の圧縮が要求されたときに、ZLIB ライブラリに動的にリンクします。以降は、ゲートウェイが停止するまで ZLIB ライブラリはロードされた状態になります。

Windows の場合は、次のように \Windows\System32 ディレクトリに ZLIB ライブラリをインストールしてください。

C:\WINDOWS\SYSTEM32\ZLIB.DLL

最新の配布キットでは、ライブラリの名前が ZLIB1.dll になっています。ゲートウェイがこのライブラリを見つけられるように、名前を ZLIB.DLL に変更する必要があります。

UNIX® システムの場合、ライブラリ (libz.so または libz.sl) は通常、以下のいずれかの場所にインストールされます。

• /usr/lib/

• /usr/local/lib/

ゲートウェイが必要に応じて ZLIB ライブラリをロードでき、すべての必要な機能を特定できれば、以下の初期化メッセージがイベント・ログに書き込まれます。

CSP Gateway Initialization
The ZLIB library is loaded - Version 1.2.3.
       (This library is used for the optional GZIP compression facility)

ゲートウェイが ZLIB ライブラリを見つけられないか、リンクできない場合、以前と同様に動作します (つまり、ページは圧縮されずに返されます)。この場合は、失敗を示すメッセージがイベント・ログに書き込まれます。

GZIP/ZLIB ライブラリの使用法

ゲートウェイは、ZLIB ライブラリを使用して応答データを圧縮する場合に 2 つの処理モード (1 および 2) を実装します。

1. このモードでは、ゲートウェイは Caché から受信したすべてのデータを圧縮機能にストリーム転送します。すべてのデータが処理されると、圧縮データがゲートウェイに返されます。この時点でデータはクライアントに転送されます。

   このモードでは、待ち時間はわずかに長くなりますが、可能な限り最適な圧縮が行われます。もちろん、形式が大きくなるほど待ち時間は長くなります。

2. このモードでは、ゲートウェイは Caché から受信したすべてのデータを圧縮機能にストリーム転送します。呼び出しを行うたびに、可能な範囲で最大限に圧縮されたデータが作成され、ゲートウェイに渡されてクライアントに転送されます。

   このモードでは、圧縮のレベルはわずかに低くなりますが、待ち時間は最小限に抑えられます。もちろん、形式が大きくなるほど圧縮レベルは低くなります。一般的に、モード 2 は CSP 応答に含まれるデータの量を事前に把握できない場合の CSP アプリケーションに適しています。

ゲートウェイが Caché から返されたデータ・ストリームを正常に圧縮できる場合 (そして圧縮できる場合のみ)、ゲートウェイでは HTTP 応答ヘッダを修正して、適切な Content-Encoding 指示文を追加します。次に例を示します。

HTTP/1.1 200 OK
Content-Type: text/html; charset=ISO-8859-1
Set-Cookie: CSPSESSIONID=000000000002119qMwh3003228403243; path=/csp/samples/;
CACHE-CONTROL: no-cache CONNECTION: Close DATE: Fri, 15 Aug 2003 10:05:18 GMT 
EXPIRES: Thu, 29 Oct 1998 17:04:19 GMT PRAGMA: no-cache Content-Encoding: gzip

ゲートウェイは応答データを圧縮する前に、常に Accept-Encoding HTTP 要求ヘッダの値 (HTTP_ACCEPT_ENCODING CGI 環境変数) を確認します。ゲートウェイは、クライアントが圧縮したコンテンツを処理できることを示した場合のみ応答を圧縮します。

次に例を示します。

Accept-Encoding: gzip, deflate

CSP 応答の圧縮を指定するにはいくつかの方法があります。これらは以下のセクションで説明しています。

ページごとの圧縮の指定

%response オブジェクトには、GzipOutput というプロパティがあります。このプロパティを True (または必要なモード) に設定すると、ゲートウェイは応答の圧縮を試みます。

<script language=Cache method=OnPreHTTP arguments=""
                 returntype=%Boolean>
         Set %response.GzipOutput = 2
         Quit 1
</script> 

HTTP 応答ヘッダに CSP-gzip 指示文を追加することで、ページごとに圧縮を指定することもできます。もちろん、OnPreHTTP メソッドで行う必要があります。次に例を示します。

<script language=Cache method=OnPreHTTP arguments="" 
               returntype=%Boolean> 
        Do %response.SetHeader("CSP-gzip", "2") 
        Quit 1 
</script>

CSP-gzip ヘッダ指示文は、必要な圧縮モード (1 または 2) に設定します。

アプリケーション・パス内のすべてのページに対する圧縮の指定

アプリケーション・パスごとに圧縮を指定できます。同時にこれは、Web サーバの出力フィルタ (mod_deflate など) を使用する場合に圧縮が必要であることを指定する最も一般的な方法です。

ゲートウェイの [アプリケーション・アクセス] セクションで以下の構成パラメータを使用します。

監視

イベント・ログ・レベル V3 では、圧縮が成功したすべての CSP 応答に対する圧縮のレベルを記録するようにゲートウェイに指示します。圧縮したデータのサイズと圧縮していない元のデータ・ストリームのサイズが記録されます。

次に例を示します。

GZIP Compression for /csp/samples/inspector.csp GZIP Mode=1; Uncompressed Content Size=19042; Compressed Content Size=2499 (13 percent)

%response.Expires プロパティ

標準の Expires プロパティは、ページがキャッシュ内に存在する期間を制御します。

例えば、あるページを 1 分で有効期限切れになるように設定した場合、ページがキャッシュ内に置かれてから 60 秒が経過すると、ゲートウェイはそのページを削除します。

%response.Expires=[60 seconds time]

これに相当する ASP.NET の指示文は以下のようになります。

<%@ OutputCache Duration="60"%>

%response.VaryByParam プロパティ

このプロパティを使用すると、HTTP POST/GET によって送信された名前と値のペアに基づいて、キャッシュに保存するページのバージョン数を制御できます。既定値は None です。None は、キャッシュに保存するページのバージョンを 1 つのみとすることを示します。すべての HTTP GET/POST パラメータが無視されます。None の反対の値は * です。このアスタリスクは、渡された名前と値のすべてのペアがページのキャッシュ・バージョンの作成に使用されることを意味します。ただし、パラメータを明示的に指定することにより、どの程度制御するかを指定できます (複数のパラメータ名はセミコロンで区切ります)。

VaryByParam プロパティの使用法について、次の例で説明します。米国の 50 州の天気予報を表示できる Web アプリケーションを構築するとします。このアプリケーションは、1 つのページ (Weather.csp) に完全にカプセル化されます。

Weather.csp には、州のドロップダウン・リストがあります。ドロップダウン・リストから州を選択し、その州の値を Weather.csp に戻します。例えば、State=WA や State=TX となります。簡素化のために、HTTP GET を使用してデータを送信するとします。1 つの項目 (State など) を選択すると、以下のように要求がサーバに送信されます。

Weather.csp?State=WA.

天気予報は 1 日に 1 回のみ更新され、予報の生成によって大きなオーバーヘッドが発生すると仮定します。

以下の指示文を Weather.csp の %response オブジェクトに追加できます。

%response.Expires=[2 hours time]
%response.VaryByParam="State"

ASP.NET では以下のようになります。

<%@ OutputCache Duration="10800" VaryByParam="State" %>

これによって州ごとにページが生成され、各ページは個別に 2 時間キャッシュされます。

Weather.csp
Weather.csp?State=WA
Weather.csp?State=TX
...etc.

ここで特定の都市の天気を示す機能を追加するとします。州や都市のパラメータに基づいてページをキャッシュするには、キャッシュの指示文を以下のように変更します。

%response.Expires=[2 hours time]
%response.VaryByParam="State;City"

ASP.NET では以下のようになります。

<%@ OutputCache Duration="10800" VaryByParam="State;City" %>

VaryByParam プロパティを使用すると、HTTP GET/POST によって送信されたパラメータに基づいて、同じページの複数のバージョンをキャッシュできます。* を使用する場合は特に注意してください。* を使用すると、頻繁にアクセスしないページで出力キャッシュがいっぱいになってしまう可能性があります。VaryByParam プロパティを具体的に指定するほど、ゲートウェイがキャッシュからページを取得できる頻度が高くなります。例えば、州のみを指定する場合、キャッシュには 51 バージョン (50 州 + パラメータを指定しないバージョン) のページがあります。都市のパラメータを追加するとき、州ごとに平均 15 都市あると仮定すると、キャッシュされた可能性があるページ数は瞬く間に 751 に増加します。

キャッシュの総容量が大きくなりすぎた結果として、メモリによって制約されるようになると、ゲートウェイはキャッシュからページを自動的に排除します。

キャッシュしたページに対するユーザのセッション ID の保存

要求を発行しているユーザのセッション ID は、セッションが Cookie (CSPSESSIONID) またはトークン (Form/URL 変数：CSPCHD) のどちらによって維持されているかを問わず、キャッシュから取得したページ内に保存する必要があります。

ページをキャッシュする場合、Caché から実際にページを取得したユーザの ID に対してページがキャッシュされます。このページには、CSPSESSIONID Cookie または CSPCHD トークンとしてのセッション ID が含まれます。キャッシュしたページをユーザに提供する前に、ゲートウェイは検出された両方の変数をすべて、要求を発行しているユーザのセッション・トークンに置き換えます。実際、要求しているユーザのブラウザで Cookie が保存されているので、その Cookie と動作が同じセッション cookie はキャッシュから削除されます。

例えば、あるページがユーザ xxxxxxx によってキャッシュされるとします。このページは以下の ID でキャッシュされます。

Set-Cookie: CSPSESSIONID=xxxxxxx;

続いて、別のユーザ aaaaaaa がキャッシュからこのページを取得すると、Cookie は理論的には以下のように変更されます。

Set-Cookie: CSPSESSIONID=aaaaaaa;

実際には、上記で説明したように、Cookie は要求しているユーザのブラウザにのみ存在します。

ただし、ゲートウェイでは、セッション・トークン CSPCHD を経由してユーザのセッションを管理するページを処理する必要があります。この場合、最初にキャッシュされるページには、以下に示すように元のユーザへの参照が含まれます。

<A HREF="/csp/page.csp?CSPCHD=xxxxxxx">
<INPUT TYPE=SUBMIT NAME="CSPCHD" VALUE="xxxxxxx">

ゲートウェイは、要求を発行しているユーザの ID を反映するために、セッション・トークンの値を自動的に変更します。例えば、ユーザ aaaaaaa がキャッシュからこのページを要求すると、ゲートウェイはこれらの行を以下のように変更します。

<A HREF="/csp/page.csp?CSPCHD=aaaaaaa">
<INPUT TYPE=SUBMIT NAME="CSPCHD" VALUE="aaaaaaa">

CSP でのクライアント側 VBScript

クライアントの Internet Explorer 環境で実行する VBScript は、JavaScript を使用する場合と同じように CSP ページに追加できます。

以下に例を示します。

<script language=vbscript>
        document.write "The time is: ",time
</script>

CSP でのサーバ側 VB-Script (CSP による ASP コンテンツの処理)

CSP アプリケーションから完全な ASP ページを構築して提供する場合もあります。この場合、CSP で生成したページには、クライアントのブラウザとは対照的に、ASP エンジンにある Web サーバ・ホストで実行する VBScript が含まれます。

CSP ゲートウェイと同様に、ASP (および ASP.NET) エンジンは、IIS の ISAPI 拡張として実装されています。ただし、CSP で生成した ASP コンテンツを、CSP ゲートウェイから ASP エンジンを使用して送るメカニズムは存在しません。

CSP 経由で ASP コンテンツを提供する機能は、CSP ゲートウェイに実装されています。これは、CSP から返された ASP ページを、IIS ドキュメント・ルートに物理ファイルとして保存することで実現できます。これを行うと、クライアントはそのページにリダイレクトされます。2 回目のリダイレクトで、ASP エンジンで処理される、新規の ASP ページが作成され、この時点でサーバ側の VBScript が実行されて、最終的なページがクライアントに配信されます。

CSP ゲートウェイは、2 つのうちのいずれかの方法で ASP リソースへのリダイレクトを管理します。

• サーバ側リダイレクト ： この選択をお勧めします。CSP から返された ASP コンテンツは一時 ASP ファイルとして保存されているので、CSP ゲートウェイは単に IIS を経由してそのページを要求します。IIS は、ページが ASP エンジンによって処理され、コンテンツがクライアントに配信されるように確認します。その後、一時 ASP ページは削除されます。クライアントの観点から見たこの方法の利点は、ASP コンテンツが CSP から直接提供されているように見えることです。要求した元の CSP ページは、ブラウザのアドレス・ボックスに登録されます。

• クライアント側リダイレクト ： このシナリオでは、HTTP リダイレクト・ヘッダをクライアントに送信することで、ゲートウェイは新規作成された ASP リソースにクライアントをリダイレクトします。クライアントと Web サーバ間で SSL を使用する場合は、このオプションを使用する必要があります。クライアントへの余分なラウンドトリップを除外すると、この方法の主な利点は、一時 ASP ページへの URL がブラウザのアドレス・ボックスに登録されることです。つまり、クライアントは一時 ASP リソースを再要求することができます (ユーザが [更新] ボタンを押したとき、または後のページで [戻る] ボタンを使用したとき)。この要件を容易に満たすことができるように、ゲートウェイでは一時 ASP ファイルを作成後 24 時間保持します。

以下の規則に従って、一時 ASP ファイルの名前が付けられます。

CSPASP[n].asp

n は一意の数です。新しい ASP ページを作成するたびにインクリメントされ、ゲートウェイを再起動すると 1 にリセットされます。

CSP アプリケーションから ASP ページが提供されるように Web サーバおよび CSP ゲートウェイを構成するには

1. まず、IIS ドキュメント・ルートの下に一時 ASP ファイルの物理的な場所を作成します。次に例を示します。

   C:\Inetpub\wwwroot\asptemp

2. 多くの場合、Windows (特に Windows 2000 以降) をインストールした環境では、ドキュメント・ルート下のディレクトリに CSP ゲートウェイから書き込むには、Web サーバに割り当てられた既定の権限では不十分です。

   したがって、asptemp ディレクトリに対する書き込み権限を Web サーバに割り当てるか、Web サーバに Administrator 権限を付与する必要があります。

   ファイル・アクセス権限は、Windows エクスプローラで変更できます。または、以下のコマンドを使用することもできます。

   cacls C:\Inetpub\wwwroot\asptemp /E /G IUSR_xxx:F

   IUSR_xxx は、Web サーバのユーザ権限です。通常、xxx はコンピュータの名前です。インターネット サービス マネージャで特定の名前を検索するには、以下の手順で [認証方法] ダイアログ・ボックスを開きます。

   1. [インターネット サービス マネージャ] を開きます。

   2. 左側のウィンドウで、[既定の Web サイト] を選択します。

   3. [既定の Web サイト] を右クリックします。メニューから [プロパティ] を選択して、[既定の Web サイトのプロパティ] ウィンドウを表示します。

   4. [ディレクトリ セキュリティ] タブを選択します。

   5. [匿名アクセスおよび認証コントロール] パネルの [編集] を選択します。[認証方法] ダイアログに [ユーザ名] が表示されます。

3. asptemp ディレクトリに割り当てられた実行許可を変更して、IIS がそのディレクトリで ASP ページを実行できるようにします。

   1. [インターネット サービス マネージャ] を開きます。

   2. 左側のウィンドウで、[既定の Web サイト] を選択します。

   3. [既定の Web サイト] を右クリックします。一時 ASP ディレクトリ (asptemp) を右クリックして、メニューから [プロパティ] を選択し、[既定の Web サイトのプロパティ] ウィンドウを表示します。

   4. [ホーム ディレクトリ] タブを選択します。

   5. [実行アクセス許可] が [スクリプトおよび実行可能ファイル] に設定されていることを確認します。

   6. [適用]、[OK] の順に選択します。

   7. ゲートウェイ構成 ([デフォルトパラメータ]) で以下の 2 つのパラメータを設定します。

      [ウェブドキュメントルート]：C:\Inetpub\wwwroot

      [ASP一時ディレクトリ]：/asptemp

4. IIS を再起動します。

ASP エンジンでページをさらに処理する必要があることを CSP ゲートウェイに指示するには、以下の手順を実行します。

1. ページの OnPreHTTP メソッドで %response.UseASPredirect プロパティを true に設定します。

   <script language=Cache method=OnPreHTTP arguments=""
              returntype=%Boolean>
           Set %response.UseASPredirect=1 Quit 1
   </script>
   

   

2. CSP ページで VBScript を宣言します。

   <%@ LANGUAGE="VBSCRIPT"%>

これで、インライン VBScript と、スクリプト化された完全なセクションの両方をページに追加できます。

例 ：

<% Response.Write("<BR><B>ASP inline</B><BR>") %>

<script language=vbscript runat=server>
      Response.Write("<br><b>Message from ASP script</b><br>")
</script>

<%
    Dim n
    For n = 1 To 10 Step 1
    Response.write("<BR>These lines were generated by a 'for' loop in VBSCRIPT: <B>Line # " & n & "</B>")
    Next
%>

完全な例 ：

<script language=Cache method=OnPreHTTP arguments=""
        returntype=%Boolean>
     Set %response.UseASPredirect=1 Quit 1
</script>
<html>
<head>
<title> CSP/VBScript demonstration </title>
</head>
<body>
<h2> CSP/VBScript demonstration page </h2>
<script language=vbscript>
     msgbox "Message from client-side vbscript"
     document.write "The time is ",time
</script>
<% Response.Write("<BR><B>Message from ASP inline</B><BR>") %>
<SCRIPT LANGUAGE=VBScript RUNAT=Server>
     Response.Write("<BR><B>Message from ASP script</B><BR>")
</SCRIPT>
<script language=cache runat=server>
     set x="message from Cach&eacute"
</script>
<br>Message from CSP #(x)# <br>
</body>
9</html>

Apache での標準 HTTP 認証 (mod_auth)

このメソッドは、Apache により (mod_auth モジュール経由で) 提供される標準メカニズムで、CSP モジュールへの最新の変更に依存しません。ここでは、完全を期すために説明しています。

Apache ベースの認証を使用する CSP サンプルを保護するために必要な基本パラメータの例は、以下の構成ブロック (httpd.conf) のとおりです。

<Location "/csp/samples/"> 
AuthType Basic 
AuthName "CSP samples" 
AuthUserFile conf/csp.pwd 
require valid-user 
</Location> 

以下はその説明です。

AuthType は要求された認証タイプ (通常は Basic) です。

AuthName はレルムです。

AuthUserFile はユーザ名とそれに関連付けられたパスワードを (暗号化された形で) 保持するファイル (Web サーバのルートとの相対パスで表されたもの) です。このファイルは、Apache htpasswd ユーティリティで作成され、管理されます。

require パラメータは、保護されたリソース (この場合は CSP サンプル) にアクセスが許可されたユーザのリストです。valid-user 引数は、ユーザを (AuthUserFile で宣言されたとおり) ユーザ名/パスワード・ファイルで定義する必要があることを示します。

Apache は、ユーザ 'groups' にグループ化されるユーザに対応しています。詳細は、AuthGroupFile 指示文を参照してください。

http://httpd.apache.org/docs/2.0/mod/mod_auth.html

要求の処理と同時に CSP で行われる認証

これは、CSP アプリケーションでの HTTP 認証の実装に推奨される (また、最もパフォーマンスのよい) メソッドです。

CSP ベースの認証を使用する CSP サンプルを保護するために必要な基本パラメータは、以下の Apache 構成ブロック (httpd.conf) のとおりです。

<Location "/csp/samples/"> 
AuthType Basic 
AuthName "CSP samples" 
require valid-user 
AuthCSPEnable On 
# The following directive is necessary for Apache v2.2 (and later)
AuthBasicAuthoritative Off
</Location> 

パラメータ AuthType、AuthName、および require は認証のトリガに使用される標準 Apache パラメータです。

また、追加の AuthCSPEnable パラメータは、(mod_auth で) Apache により行われる認証チェックを迂回し、本来の Web 要求と共にユーザ名とパスワードを認証のために Caché に渡すように CSP モジュールに指示します。CSP アプリケーションは、以下の CGI 環境変数を使用して、このユーザをチェックする必要があります。

• AUTH_TYPE ： これは Basic です。

• REMOTE_USER ： ユーザ名。

• AUTH_PASSWORD ： ユーザのパスワード (プレーン・テキスト)。

これらのパラメータに保持された値に基づいて、ユーザが正常に認証されると、アプリケーションは要求の処理を続行します (つまり、要求された CSP リソースを返します)。認証されなかった場合、最低でも次のような HTTP 401 Authorization Required 応答が返されます。

HTTP/1.1 401 Authorization Required 
WWW-Authenticate: Basic realm="CSP samples" 
Content-Type: text/html 
Connection: close 
<html> 
<head><title>401 Authorization Required</title>
</head><body> <h1>Authorization Required</h1> 
<p> The Cache server could not verify that you are authorized 
to access the application. Check your username and password. 
</p> 
<hr> 
</body> 
</html> 

このメッセージが受信されると、ユーザが既定の回数 (通常は 3 回) を超えてログインを試行していない限り、ブラウザにはログイン・ダイアログが再表示されます。超えてしまった場合は、ヘッダに続いてこのメッセージが表示されます。

Caché システム v5.1 (およびそれ以降) では、ユーザは、ログイン・ページを変更することにより、この認証メソッドを実装できます。要求が到着したときに、アプリケーションを実行するために必要な権限をユーザが保持していなかった場合、ログイン・ページが呼び出され、要求から認証情報 (AUTH_TYPE、REMOTE_USER、AUTH_PASSWORD など) を抽出する処理が行われます。これらのパラメータが正当と判断された場合、ログイン・スクリプトは、本来要求されたアプリケーション・ページに制御をリダイレクトします。Caché セキュリティのコントロール・レイヤが展開されている場合、パブリック・ページすべてに対してこの認証プロシージャを繰り返す必要はありません。

要求の処理前に CSP で行われる認証

これは、Caché で HTTP 認証を実装するための代替方法です。これは主に、CSP アプリケーションでの要求処理時には認証を実行することが難しいか、実行に時間がかかる場合に行われます。例えば、Caché v5.0 (またはそれ以前) で実行される既存アプリケーションでは、標準ログイン・ページがない場合、すべてのパブリック・ページに認証チェックを追加するのは実用的ではありません。

この方法では、ユーザ認証のために、専用の認証クラスが呼び出されます。CSP ゲートウェイは、Caché に元の要求を送信する前に、このチェックを実行します。認証クラスによるユーザの詳細チェックが正常に終了すると、これ以上、CSP アプリケーションで選択を実行する必要はありません。

もちろん、この方法には、Web 要求 1 回に対して、認証に 1 回、CSP リソースに対する実際の要求の処理に 1 回の合計 2 回 (Caché への) 要求を処理するというオーバーヘッドがあります。

この認証方法を実装するために必要な基本パラメータは、以下の Apache 構成ブロック (httpd.conf) のとおりです。

<Location "/csp/samples/"> 
AuthType Basic 
AuthName "CSP samples" 
require valid-user 
AuthCSPEnable On 
AuthCSPClass /csp/samples/%CSP.HTTPAuthentication.cls 
# The following directive is necessary for Apache v2.2 (and later)
AuthBasicAuthoritative Off
</Location> 

パラメータ AuthType、AuthName、require、および AuthCSPEnable はメソッド (2) と同じです。

また、AuthCSPClass パラメータはユーザ認証を実行するクラスを定義します。このクラスは、適切な CGI 環境変数を使って %CSP.PageOpens in a new tab を拡張し、ユーザ・ログインの詳細をチェックして、操作に成功した場合は 200 OK 応答ヘッダ、失敗した場合は 401 Authorization Required 応答ヘッダを返す必要があります。

%Users ファイルに保存されているレコードに対するユーザ・ログインの詳細のチェックが行われる単純な認証クラスは以下のとおりです。

Class %CSP.HTTPAuthentication Extends %CSP.Page 
{ 
ClassMethod OnPreHTTP() As %Boolean 
{ 
Set %response.ContentType = "text/html" 
Set %session.Preserve = 0 
Quit 1 
} 
ClassMethod OnPage() As %Status 
{ 
Set crlf=$Char(13,10) 
Set type=%request.GetCgiEnv("AUTH_TYPE", "") 
Set user=%request.GetCgiEnv("REMOTE_USER", "") 
Set pwd=%request.GetCgiEnv("AUTH_PASSWORD", "") 
Set httpauth=%request.GetCgiEnv("HTTP_AUTHORIZATION", "")
If httpauth'="" {
      Set type=$Piece(httpauth," ",1)
      Set user=$system.Encryption.Base64Decode($Piece(httpauth," ",2))
      Set pwd=$Piece(user,":",2)
      Set user=$Piece(user,":",1)
}
Set auth=0 If $ZConvert(type,"L")'="basic" Set auth=1 
If auth=0,user'="",$Get(^%Users(user))=pwd Set auth=1 
If auth=1 { 
Write "HTTP/1.1 200 OK"_crlf 
Write "Content-Type: text/html"_crlf 
Write "Content-Length: 0"_crlf 
Write "Connection: close"_crlf_crlf 
} 
Else { 
Write "HTTP/1.1 401 Authorization Required"_crlf 
Write "WWW-Authenticate: Basic realm=""CSP samples"""_crlf 
Write "Content-Type: text/html"_crlf 
Write "Content-Length: 0"_crlf 
Write "Connection: close"_crlf_crlf 
} 
Quit $$$OK 
} 
ClassMethod OnHTTPHeader(ByRef OutputBody As %Boolean) As %Status 
{ 
Quit $$$OK 
} 

メソッド (1) および (3) では、Apache ErrorDocument 指示文を使用して、ログインの失敗に対するカスタム・エラー・ページを指定できます。以下はその例です。

ErrorDocument /error/my_authentication_error.html 

もちろん、メソッド (2) では、エラー・メッセージの内容は CSP アプリケーションによって制御されます。

複数の Web サーバ間の負荷分散とフェイルオーバー

ほとんどの環境では、Web サーバ層で負荷を分散して高可用性を実現するために、複数の Web　サーバが使用されます。 一般に、参加する Web サーバに対してユーザ接続を行うには、ロード・バランサが必要です。 最適なパフォーマンスと復元力を得るには、ハードウェア・ベースのソリューションの使用をお勧めします。 Cisco ACE 4710 や F5 BigIP LTM アプライアンスなどの負荷分散システムは、Web サーバ群の前面に配置されます。 この構成では、Caché ECP 構成のように、複数の Caché サーバ・インスタンスも存在している場合、各 Web サーバ (およびゲートウェイ・インスタンスも含めて) を特定の Caché サーバ・インスタンスに接続するように構成してください。

ソフトウェア・ベースの負荷分散およびフェイルオーバー・システムは、ハードウェア・ベースのソリューションほど堅牢ではありませんが、非常に低コストで導入できます。 ソフトウェア・ベースのソリューションの例としては、HAProxy や Apache Group の mod_proxy_balancer があります。詳細は、HAProxy のサイト www.haproxy.orgOpens in a new tab を参照してください。

上記のアプローチが最も推奨される方法ですが、ゲートウェイには複数の Caché サーバ 間で負荷分散やフェイルオーバーを実装するための基本の (ソフトウェア・ベースの) システムが含まれています。 このような構成では、ゲートウェイのインストールは複数の Caché サーバ に接続するように構成されます。 この機能については、このセクションの以降の部分で説明します。

ゲートウェイの負荷分散およびフェイルオーバーは、[CSP ゲートウェイ管理]ページ ([システム管理]→[構成]→[CSP ゲートウェイ管理]) の [アプリケーションアクセス] セクションで構成されます。

Caché サーバのリストを、アプリケーション (パス) に対して定義できます。 Servers パラメータを使用して、それらの使用目的を確認します。 これには以下の 3 つのオプションがあります。

• [負荷分散とフェイルオーバを使用する]

• [フェイルオーバのみ使用する] メイン (つまり最初の)　サーバが使用不能になった場合にのみ代替を使用します。

• [最初のサーバのみを使用する] リスト内の最初のサーバのみを使用します。

複数の Caché サーバ・インスタス間の負荷分散とフェイルオーバー

複数 (同等) の Caché サーバ・インスタンスが含まれる構成 (Caché ECP 構成など) では、ゲートウェイは、それらの Caché インスタンス間で負荷分散とフェイルオーバーを実装するための基本 (ソフトウェア・ベース) の機能を Web アプリケーションに提供します。 しかし、第一に推奨されるのは、前述のような外部ソリューションです。

ゲートウェイによって提供されるフェイルオーバー・メカニズムでは、フェイルオーバー・クラスタリングや Caché ミラーリングなどの一般的な高可用性構成において、複数の Caché データベース・サーバ間にフェイルオーバーを実装する必要はありません。 それらのテクノロジは仮想 IP ベースのフェイルオーバーを提供しており、その IPアドレスに接続するようにゲートウェイを構成できます。

このセクションの残りの部分では、ゲートウェイによって提供される負荷分散およびフェイルオーバー機能について説明します。

ゲートウェイの負荷分散およびフェイルオーバーは、[CSP ゲートウェイ管理] ページの [アプリケーションアクセス] セクションで構成されます。

Caché サーバのリストを、アプリケーション (パス) に対して定義できます。 [代替サーバの使用目的] パラメータの下にリストされているオプションを使用して、そのサーバの使用目的を選択します。 これには、以下の 2 つのオプションがあります。

• フェイルオーバー

• 負荷分散とフェイルオーバー

どちらのオプションも選択されていない場合の既定の対策は、リストで定義されている最初の Caché サーバを使用することです。

以下は、Caché サーバーのリストです。それぞれは server# と指定されます (# はサーバ番号です)。

構成画面には、常に 3 つの空のサーバ・スロットのみが表示されていますが、任意の数の代替サーバを定義できます。それぞれのサーバは、[有効] または [無効] としてマークできます。 既定の設定は [有効] です。

負荷分散は、ラウンドロビン方式で実装されます。 新しい各ユーザ・セッションは、次に使用可能な "代替" サーバに接続されます。 ユーザ・セッションがサーバで確立されると、ゲートウェイはサーバが使用不可能にならない限り、そのサーバでセッションを維持しようとします。このサーバが使用不可能になった場合、セッションはリスト内で次に使用可能なサーバにフェイルオーバーされます。 ステート認識セッション (保持モード = 1) の場合、どのような状況でもフェイルオーバーは行われないので、ホスト・サーバが使用不可能になるとセッションは閉じます。

ミラー構成

ミラー Caché 構成を使用すると、データベースは参加するミラー・メンバ間で複製 (またはミラーリング) されます。 Caché ミラー・セット構成は、インストールに参加するミラー・メンバのセットを表します。Caché ミラーリングの詳しい説明は、"Caché 高可用性ガイド" の "ミラーリング"　の章を参照してください。

プライマリ・メンバに対してネットワークのリダイレクトを提供するためにミラー仮想 IP (または同等のテクノロジ) が使用される場合は、そのアドレスに接続するように CSP ゲートウェイを構成します。それ以上のアクションは必要ありません。 仮想 IP アドレスは常にミラー・プライマリにマップされます。

ミラー仮想 IP を使用できない (または特定の災害シナリオでは機能しない) 構成の場合、CSP ゲートウェイをミラー認識になるように構成できます。 ゲートウェイがミラー認識の場合、どのメンバがプライマリかを決定する責任を負います。 ゲートウェイをミラー認識にするには、CSP ゲートウェイの [サーバ接続] セクションで、[構成はミラーを認識する] を選択し、ミラー・メンバのいずれかのアドレスを指定します。

ミラー認識のゲートウェイ構成が、ミラー・メンバでない Caché サーバに接続する場合、接続は失敗し、影響を受けるクライアントは Server Availability エラーを受け取ります。

ゲートウェイは、最初に接続するメンバから、フェイルオーバー・メンバおよび災害復旧 (DR)　メンバのリストを入手します。 ゲートウェイはこのリストをローカル構成ファイル (CSPRT.ini) に維持します。 その後、ゲートウェイがその構成で定義されたメンバに接続できなくなる場合、以前にローカルに記録されたリストを使用して、代替メンバを識別し、それに接続できるようにします。

ゲートウェイは、プライマリを見つけるまで、メンバ・リストを循環します。 プライマリが見つからない場合、接続は失敗し、影響を受けるクライアントは Server Availability エラーを受け取ります。

• ゲートウェイは、プライマリとして定義されたメンバが見つかるまで、リストを繰り返し循環します。

• 密接なループ構造がパフォーマンスに与える悪影響を回避するため、ゲートウェイは各サイクルの終了後、試行回数に相当する秒数の間、停止します。

• 特定の HTTP 要求では、ゲートウェイは、[サーバ応答タイムアウト] パラメータで定義された時間を超えてプライマリを見つけることはありません。

• プライマリを検索する場合、ゲートウェイが最初に接続するのは、常にフェイルオーバー・メンバです。 フェイルオーバー・メンバの中にプライマリが見つからない場合のみ、非同期メンバを試行します。 非同期メンバを手動でプライマリと指定する場合のみ、非同期メンバはプライマリになります。

最初の接続時に、ミラー・メンバがゲートウェイ・システム・ステータス・フォームに表示されます。 ミラー・メンバは、(ゲートウェイの [サーバ接続] セクションで定義されたとおりに) 現行の構成名で表示されます。その際に、ツールのヒントとしてミラー・セット名、ミラー、ミラー・メンバ名が表示されます。

2 つの新規列である　[ミラー名] および [ミラー・ステータス] が [Caché サーバ] テーブルに追加されました。 ミラー・セットおよびミラー・メンバの名前が [ミラー名] 列に表示されます。現在のメンバ・ステータスが [ミラー・ステータス] 列に表示されます。[メンバタイプ] (Failover または Async) が表示され、プライマリ・メンバには Primary.というラベルが付けられます。

ステート認識モードの起動

以下のように保持モードを設定することで、セッションをステート認識にします。

Set %session.Preserve = 1

フォームの OnPreHTTP メソッドでセッションをステート認識としてマークすることを推奨します。

<script language=Cache method=OnPreHTTP arguments="" returntype=%Boolean>
Set %session.Preserve = 1
Quit 1
</script>

ここで指示を出すことで、CSP エンジンは HTTP 応答ヘッダを作成してゲートウェイに送信する前に、セッションの cookie (またはトークン) をステート認識としてマークできます。

OnPreHTTP メソッドが起動した後でセッションをステート認識としてマークすることもできますが、この場合、セッションの cookie/トークンは既に作成されています。 CSP エンジンは、preserve=1 という指示を応答フッタでゲートウェイに渡し (応答ペイロードの後で送信)、ゲートウェイは接続を private とマークして、そのセッション ID に対する指示をキャッシュします。これによってゲートウェイは、以降の要求が到着した際、unmodified セッション・トークンをステート認識として識別することが可能になります。

OnPreHTTP メソッドでセッションがステート認識としてマークされた場合、その情報は事実上クライアントに常駐するセッションの cookie/トークンで運ばれるため、ゲートウェイはそのセッションの移行をキャッシュする必要はありません。

ステート認識モードの維持とエラーへの応答

セッションがステート認識としてマークされ、ゲートウェイがステートの移行を認識して接続をプライベートとマークすると、以下のイベントのいずれかが発生するまでセッションは透過的にステート認識モードで動作します。

• アプリケーションがステートレス処理モードに戻った場合。

• アプリケーションがプログラムによってセッションを終了するか、セッションがタイムアウトした場合。

• エラー状態の結果としてプライベート接続が不完全に閉じた場合。

(おそらくエラー状態の結果として) ステート認識アプリケーションをホストするプライベート接続が不完全に閉じた場合、ゲートウェイはプールで利用可能なステートレス接続に要求を転送し、Caché エラー番号 5974 が返されます。

CSP error occurred
Error: The persistent session is no longer available because the server process does not exist
ErrorNo: 5974
CSP Page: /csp/samples/loop.csp
Namespace: %SYS
Class: <Unknown>

この時点では、要求はステートレス・モードで処理され、このエラーにはアプリケーションが例えばユーザにアプリケーションのログイン・フォームを再度表示するなどして応答します。

ステート認識モードで動作している際は、全ページの %session.NewSession の値をチェックする必要があります。 または、アプリケーションへのアクセスをユーザが最初に許可されたときに、アプリケーションが %session.Data に格納されているユーザ固有の認証データの有効性をチェックする必要があります。これらのチェックはセキュリティのためにも、ユーザ・セッションが依然としてステート認識処理モードにしっかり固定されていることを確認するためにも重要です。 これらの状況では、エラー状態は自動的に発生しません。なぜなら、セッションは既に (適切な手順を踏んで正常に) ステート認識モードから移行している可能性があるからです。 例えば、受信セッションのトークンは依然としてステート認識とマークされているもののアプリケーションは既にステートレス・モードに移行している状況を考えてみましょう。この状況は、移行が行われる前に処理されたフォームに (CSPCHD として) セッションのトークンが埋め込まれているために起こります。

最後に、(例えば、タイムアウトの後で) セッションが終了する際、CSP エンジンはそのセッションに関連付けられたすべての処理データを削除することに注意してください。その後は、そのセッションに対する受信要求は、すべて新しいセッションに対する要求のように処理されます。

Caché が CSP アプリケーションに提供する埋め込みのセキュリティ・メカニズムは、前述の不測の事態から保護します。 (Caché プロセスに関して) ステート認識アプリケーション内の継続性が失われた場合は必ず、ユーザには自動的にログイン・フォームが表示されます。

ステート認識モードの終了

以下のように保持モードを設定することで、アプリケーションをステートレス処理モードに戻すことができます。

Set %session.Preserve = 0

このコードは、フォームの OnPreHTTP メソッドで実行することを推奨します。

<script language=Cache method=OnPreHTTP arguments="" returntype=%Boolean>
Set %session.Preserve = 0
Quit 1
</script>

ここで指示を出すことで、CSP エンジンは HTTP 応答ヘッダを作成してゲートウェイに送信する前に、セッションの cookie (またはトークン) をステートレスとしてマークできます。

セッションは以下のように即座に終了できます。

Set %session.EndSession = 1

このプロパティを設定すると、セッションは現在の要求を処理した後で直ちに終了します。

以下のようにセッションのタイムアウトを設定できます。

Set %session.AppTimeout = 900

アクティビティがない時間が所定の秒数に達すると、セッションはタイムアウトして終了します。 既定値は 900 秒 (15 分) です。

構成を再ロードするようゲートウェイを強制する

ゲートウェイの構成が外部エージェント (つまり、ゲートウェイ独自のシステム管理スイート以外のエージェント) によって変更される場合があります。

完全な再起動を必要とせずに、ゲートウェイに構成を再ロードするようインタラクティブに指示するには、以下の 2 つの方法があります。

Caché ベースのゲートウェイ・レジストリの使用

以下のレジストリ・メソッドが提供されています。

Set status = %CSP.Mgr.GatewayMgr.ActivateCSPIni()

呼び出しが成功すると、ゲートウェイはその構成ファイル (CSP.ini) を読み取り、行われたすべての変更を有効化します。

Caché 外部のスクリプトの使用

スクリプトでは、変更されたゲートウェイの構成ファイル (CSP.ini) の SYSTEM セクションに次の行 (大文字と小文字が区別される) を追加する必要があります。

[SYSTEM]
RELOAD=1

ゲートウェイ・ケアテイカー・デーモンは、ほぼ 1 分おきに RELOAD フラグを確認し、正しく設定されていれば、その構成を再ロードおよび再起動して、ファイルからフラグを削除します。 再ロード操作が成功すると、以下のメッセージがイベント・ログに書き込まれます。

Gateway Management 
Gateway Configuration Reloaded and Reactivated

WebSocket プロトコル

WebSocket プロトコル (RFC 6455) は、クライアントとサーバの間で全二重のメッセージ指向の通信チャネルを指定することによって、サーバがクライアントにメッセージを事前にプッシュできるようにするという、基本的な要件に対処します。 このプロトコルは、クライアントとサーバの間に既に確立されている標準 TCP チャネルを介して動作するように (したがって保護されるように) 設計されています。 つまり、Web ブラウザと Web サーバの間で HTTP プロトコルをサポートするために既に使用されているチャネルです。

WebSocket プロトコルおよびその API は、W3C によって標準化され、クライアント部分は HTML 5 に組み込まれています。

媒体 (プロキシやファイアウォールなど) は、WebSocket プロトコルを認識していること (およびサポートしていること) が期待されています。

WebSocket プロトコルの最終規格の作成は数回行われ、それぞれに程度の異なるブラウザのサポートが組み込まれています。その履歴を以下のまとめます。

• Hixie-75 ：

  • Chrome 4.0+5.0、Safari 5.0.0

• HyBi-00/Hixie-76 ：

  • Chrome 6.0-13.0、Safari 5.0.2+5.1、Firefox 4.0 (無効)、Opera 11 (無効)

• HyBi-07+ ：

  • Chrome 14.0、Firefox 6.0、IE 9 (Silverlight 拡張経由)

• HyBi-10 ：

  • Chrome 14.0+15.0、Firefox 7.0+8.0+9.0+10.0、IE 10 (Windows 8 開発者プレビュー経由)

• HyBi-17/RFC 6455

  • Chrome 16

  • Safari 6

  • Firefox 11

  • Opera 12.10/Opera Mobile 12.1

  • IE 10

最後の強調表示されたセクションは、ポータブル Web アプリケーションを開発する目的では最も重要です。

サーバ指向の JavaScript ベースの Node.js テクノロジは、最も精巧で、現在最も成熟した WebSocket プロトコルの実装を確実に提供します。 このため、WebSocket は、このドキュメント作成時点 (2013 年 3 月) まで Node.js と深く関連付けられてきました。 しかし、他の Web サーバ・テクノロジが急速に追いついていて、主な Web サーバすべての最新バージョンが、以下に示すように WebSocket のサポートを提供するようになりました。

• Node.js

  • すべてのバージョン

• Apache v2.2

• IIS v8.0

  • Windows 8 および Windows Server 2012

• Nginx v1.3

• Lighttpd

強調表示されたセクションは、CSP を備えたポータブル Web アプリケーションを開発する目的では最も重要です。

WebSocket の作成には、クライアントとサーバの間のメッセージの順序付けされた交換が含まれます。 まず、WebSocket ハンドシェイクを実行する必要があります。 ハンドシェイクは、HTTP メッセージ交換に基づいていて、これに似ています。そのため、既存の HTTP インフラストラクチャ使用して問題なく渡すことができます。

• クライアントは、WebSocket 接続のハンドシェイク要求を送信します。

• サーバは、ハンドシェイク応答を送信します (可能な場合)。

Web サーバは、ハンドシェイク要求メッセージの従来の HTTP ヘッダ構造を認識し、WebSocket プロトコルをサポートしていることを示す、同じように構成された応答メッセージをクライアントに送信します (応答メッセージを送信できることが前提)。 両者が同意した場合、チャネルは HTTP (http://) から WebSocket プロトコル (ws://) に切り替わります。

• プロトコルが正常に切り替わると、チャネルは、クライアントとサーバの間の全二重通信を許可します。

• 個別のメッセージのデータ・フレーミングは最小です。

クライアントからの典型的な WebSocket ハンドシェイク・メッセージ

GET /csp/user/MyApp.MyWebSocketServer.cls HTTP/1.1
Host: localhost
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat
Sec-WebSocket-Version: 13
Origin: http://localhost

サーバからの典型的な WebSocket ハンドシェイク・メッセージ

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat

プロトコルを HTTP から WebSocket にアップグレードすることをクライアントのハンドシェイク・メッセージが要求する方法に注意してください。 クライアント (Sec-WebSocket-Key) とサーバ (Sec-WebSocket-Accept) の間の一意のキーの交換にも注意してください。

WebSocket のクライアント・コード (JavaScript)

ブラウザ環境では、WebSocket プロトコルのクライアント側は JavaScript コードで実装されます。 標準のテキスト本に使用法のモデルについて詳細に説明されています。 このドキュメントでは、その基本について簡単に説明します。

最初のパラメータは、WebSocket アプリケーションのサーバ側を特定する URL を表します。 2 番目のパラメータは任意です。これがある場合、WebSocket 接続が成功することをサーバがサポートする必要がある、サブプロトコルを指定します。

var ws = new WebSocket(url, [protocol]);

例：

ws = new WebSocket(((window.location.protocol == "https:")
     ? "wss:" : "ws:") \
     + "//" + window.location.host
     + /csp/user/MyApp.MyWebSocketServer.cls);

基盤となるトランスポートが SSL/TLS を使用して保護されているかどうかに応じて、プロトコルが ws または wss に定義される方法に注意してください。

読み取り専用属性 ws.readyState は、接続の状態を定義します。以下の値のいずれかになります。

• 0 ： 接続はまだ確立されていません。

• 1 ： 接続が確立され、通信可能です。

• 2 ： 接続は閉じているハンドシェイクに従います。

• 3 ： 接続が閉じられているかまたは開くことができませんでした。

読み取り専用属性 ws.bufferedAmount は、send() メソッドを使用してキューに入っている UTF-8 テキストのバイト数を定義します。

以下のイベントを使用できます。

• ws.onopen ： ソケット接続が確立されるとトリガされます。

• ws.onmessage ： クライアントがサーバからデータを受信するとトリガされます。

event.data で受信されるデータ。

• ws.onerror ： 通信でエラーが発生するとトリガされます。

• ws.onclose ： 接続が閉じられるとトリガされます。

以下のメソッドを使用できます。

• ws.send(data) ： クライアントにデータを送信します。

• ws.close() ： 接続を閉じます。

WebSocket のサーバ・コード (CSP)

WebSocket サーバを実装するベース Caché クラスは %CSP.WebSocketOpens in a new tab です。

クライアントが WebSocket 接続を要求すると、初期 HTTP 要求 (初期ハンドシェイク・メッセージ) は、アプリケーションの WebSocket サーバを初期化するように CSP エンジンに指示します。 WebSocket サーバは、要求元の URL で名前を付けられたクラスです。 例えば、WebSocket サーバが MyApp.MyWebSocketServer という名前で、USER NameSpace で動作するように設計されている場合、WebSocket 接続を要求するために使用される URL は以下のようになります。

/csp/user/MyApp.MyWebSocketServer.cls

WebSocket サーバの実装は、ベースの %CSP.WebSocket クラスから派生します。 応答として以下のイベントに実装する重要なメソッドは 3 つあります。 これらのメソッドのいずれかを呼び出す前に、CSP セッションがロック解除されることに注意してください。

OnPreServer (optional)

このメソッドを使用して、WebSocket サーバが確立される前に実行する必要があるコードを呼び出します。 SharedConnection プロパティの変更はここで行う必要があります。

Server (Mandatory)

WebSocket サーバ。 これは、WebSocket アプリケーションのサーバ側の実装です。 Read() メソッドおよび Write() メソッドを使用して、クライアントとメッセージを交換できます。 EndServer() メソッドを使用して、サーバ側から WebSocket を正常に閉じます。

OnPostServer (optional)

このメソッドを使用して、WebSocket サーバが閉じられた後に実行する必要があるコードを呼び出します。

以下のメソッドが用意されています。

Method Read(ByRef len As %Integer = 32656,
     ByRef sc As %Status,
     timeout As %Integer = 86400) As %String

このメソッドは、クライアントから len で指定された文字まで読み取ります。 呼び出しに成功すると、ステータス (sc) は $$$OK として返されます。失敗すると、以下のエラー・コードのいずれかが返されます。

• $$$CSPWebSocketTimeout ： 読み取りメソッドはタイムアウトになりました。

• $$$CSPWebSocketClosed ： クライアントが WebSocket を終了しました。

Method Write(data As %String) As %Status

このメソッドは、データをクライアントに書き込みます。

Method EndServer() As %Status

このメソッドは、クライアントとの接続を閉じることによって WebSocket サーバを正常に終了します。

Method OpenServer(WebSocketID As %String = "") As %Status

このメソッドは、既存の WebSocket サーバを開きます。 このメソッドを使用してアクセスできるのは、非同期で動作している WebSocket (SharedConnection=1) のみです。

以下のプロパティが用意されています。

SharedConnection (default: 0)

このプロパティによって、クライアントと WebSocket サーバの間の通信を専用のゲートウェイ接続を介して行う必要があるか、または共有接続のプールを介して非同期で行う必要があるかが決まります。 このプロパティは、OnPreServer() メソッドで設定する必要があり、以下のように設定できます。

• SharedConnection=0 ： WebSocket サーバは、専用のゲートウェイ接続を介してクライアントと同期して通信します。 このモードの処理では、ホスト接続は、アプリケーションの WebSocket サーバに対して事実上「プライベート」です。

• SharedConnection=1 ： WebSocket サーバは、共有ゲートウェイ接続のプールを介してクライアントと非同期で通信します。

WebSocketID

このプロパティは、WebSocket の一意の ID を表します。

SessionId

このプロパティは、WebSocket が作成されたホスト CSP セッション ID を表します。

BinaryData

このプロパティは、転送されたデータ・ストリームを UTF-8 エンコード・テキストとして解釈する機能をバイパスし、WebSocket フレーム・ヘッダに適切なバイナリ・データ・フィールドを設定するようゲートウェイに指示します。

これは、バイナリ・データのストリームをクライアントに書き込む前に 1 に設定する必要があります。 次に例を示します。

Set ..BinaryData = 1

WebSocket サーバの例

以下の単純な WebSocket サーバ・クラスは、クライアントからの接続を受け入れ、受信したデータを単純にエコー・バックします。

タイムアウトは 10 秒に設定され、Read() メソッドがタイムアウトになるたびに、メッセージがクライアントに書き込まれます。 これは、WebSocket を実証する重要な概念の 1 つ (サーバからクライアントとのメッセージ交換の開始) を示します。

最後に、クライアント (つまりユーザ) が文字列 exit を送信すると、WebSocket は正常に閉じます。

Method OnPreServer() As %Status
{
   Quit $$$OK
}

Method Server() As %Status
{
   Set timeout=10
   For  {
      Set len=32656
      Set data=..Read(.len, .status, timeout)
      If $$$ISERR(status) {
If $$$GETERRORCODE(status) = $$$CSPWebSocketClosed {
Quit
}
         If $$$GETERRORCODE(status) = $$$CSPWebSocketTimeout {
               Set status=..Write(“Server timed-out at “_$Horolog)
         }
      }
      else {
         If data="exit" Quit
         Set status=..Write(data)
      }
   }
   Set status=..EndServer()
   Quit $$$OK
}

Method OnPostServer() As %Status
{
   Quit $$$OK
}

}

WebSockets サーバの非同期動作

前の節の例は、専用の Caché 接続を介して、WebSocket サーバがクライアントと同期して動作する例を示しています。 このような接続が確立されると、ゲートウェイ・システム・ステータス・フォームのステータス列で WebSocket というラベルが付けられます。 このモードでは、WebSocket は、ホスト CSP セッションのセキュリティ・コンテキスト内で動作し、そのセッションに関連付けられたすべてのプロパティに簡単にアクセスできます。

非同期モードでの動作 (SharedConnection=1) では、ホスト接続は、WebSocket オブジェクトが作成されるとすぐに解放され、クライアントとのその後の対話は、共有接続のプールを介して行われます。クライアントからのメッセージは、ゲートウェイ接続の従来のプールを介して Caché に到達し、クライアントへのメッセージは、ゲートウェイと Caché の間に確立されたサーバ接続のプールを介して送信されます。

非同期モードでは、WebSocket サーバは、メイン CSP セッションから分離されます。つまり、 SessionId プロパティは、ホスト・セッション ID の値を保持しますが、セッション・オブジェクトのインスタンスは自動的には作成されません。

前に示した例は、単純に OnPreServer() メソッドの SharedConnection プロパティを設定することによって、非同期で実行できます。 ただし、Caché プロセスを永遠に WebSocket と関連付ける必要はありません。 Server() メソッドは、WebSocket を閉じずに終了できます (ホスト・プロセスは停止します)。 WebSocketID が保持された場合、WebSocket は、次に別の Caché プロセスで開くことができ、クライアントとの通信が再開されます。

例 ：

Class MyApp.MyWebSocketServer Extends %CSP.WebSocket
{

Method OnPreServer() As %Status
{
MYAPP.SAVE(..WebSocketID)
   Set SharedConnection = 1
   Quit $$$OK
}

Method Server() As %Status
{
   Quit $$$OK
}

Method OnPostServer() As %Status
{
   Quit $$$OK
}

}

WebSocketID は OnPreServer() メソッドを次に使用できるように保持されることに注意してください。 また、OnPreServer() メソッドおよび Server() メソッドの SharedConnection プロパティの設定は単に終了することにも注意してください。

WebSocketID の後続の取得 ：

Set WebSocketID = MYAPP.RETRIEVE()

クライアントとのリンクの再確立 ：

Set ws=##class(%CSP.WebSocketTest).%New()
Set %status = ws.OpenServer(WebSocketID)

クライアントからの読み取りとクライアントへの書き込み ：

Set %status=ws.Write(message)
Set data=ws.Read(.len, .%status, timeout)

最後に、サーバ側からの WebSocket のクローズ ：

Set %status=ws.EndServer()