test

Sun Java System Portal Server Secure Remote Access 7.2 管理ガイド

パート I Secure Remote Access サーバーコンポーネント

第 1 章 Portal Server Secure Remote Access サーバーの概要

この章では、Sun JavaTM System Portal Server Secure Remote Access について、および Sun Java System Portal Server と Sun Java System Portal Server Secure Remote Access コンポーネントの関係について説明します。

この章の内容は次のとおりです。

Secure Remote Access の概要

Secure Remote Access を使えば、リモートエンドユーザーは所属する組織のネットワークとサービスに、インターネット経由で安全にアクセスできます。また、セキュリティー保護されたインターネットポータルを組織に提供し、従業員、ビジネスパートナー、一般ユーザーなど、ターゲットとするユーザーがコンテンツ、アプリケーション、およびデータを利用できるようにします。

リモートデバイスからポータルコンテンツおよびサービスにアクセスする場合、Secure Remote Access ではブラウザによる、セキュリティー保護されたリモートアクセスが提供されます。Secure Remote Access は、Java™ テクノロジに対応したブラウザを使用するすべてのデバイスからユーザーへのアクセスが可能な、セキュリティー保護されたアクセスソリューションであり、クライアントソフトウェアを使用する必要はありません。Portal Server に統合すると、アクセス権のあるコンテンツおよびサービスへの暗号化されたセキュリティー保護されたアクセスが、ユーザーに対して保証されます。

Secure Remote Access ソフトウェアは、安全性の高いリモートアクセスポータルを提供する企業を対象に設計されています。このようなポータルは、イントラネットリソースのセキュリティー、保護、およびプライバシに重点が置かれています。Secure Remote Access のアーキテクチャーは、これらのタイプのポータルに適しています。ユーザーは Secure Remote Access ソフトウェアを利用することで、イントラネットリソースをインターネットに公開しなくても、これらのリソースにインターネットを通じて安全にアクセスできます。

Portal Server は、次の節で説明するオープンモードとセキュリティー保護されたモードの 2 つのモードで動作します。

オープンモード

オープンモードの場合、Portal Server のインストール時に Secure Remote Access ソフトウェアはインストールされません。このモードでの HTTPS 通信は可能ですが、セキュリティー保護されたリモートアクセスは使用できません。したがって、ユーザーはセキュリティー保護されたリモートファイルシステムとアプリケーションにはアクセスできません。

オープンポータルとセキュリティー保護されたポータルの主な違いは、オープンポータルを通じて提供されるサービスは、通常は保護されたイントラネット内ではなく非武装ゾーン (DMZ) 内に存在する点にあります。DMZ は一般のインターネットと私的なイントラネットの間に存在する保護付きの小規模ネットワークで、通常は両端のファイアウォールで境界が定められます。

公開情報の配布、無償アプリケーションへのアクセス許可について、ポータルに機密情報が含まれていない場合、大量のアクセス要求への応答は、セキュリティー保護されたモードに比べて速くなります。

オープンモードでは、Portal Server はファイアウォールの背後にある単一のサーバーにインストールされています。複数のクライアントが単一のファイアウォールを経由して、インターネット上の Portal Server にアクセスしています。

図 1–1 Secure Remote Access を使用するオープンモードの Portal Server

オープンモードの Portal Server

セキュリティー保護されたモード

セキュリティー保護されたモードは、必要とされるイントラネットファイルシステムとアプリケーションへのセキュリティー保護されたリモートアクセスを可能にします。

ゲートウェイは非武装ゾーン (DMZ) に常駐します。ゲートウェイはすべてのイントラネット URL とアプリケーションへの単一のセキュリティー保護されたアクセスポイントとして機能し、ファイアウォールに開かれるポートの数は減ります。その他のセッション、認証、および標準のポータルデスクトップなどの Portal Server サービスはすべて、保護されたイントラネットの DMZ の背後で実行されます。クライアントブラウザからゲートウェイへの通信は、SSL (Secure Socket Layer) を使った HTTP を使って暗号化されます。ゲートウェイからサーバーおよびイントラネットリソースへの通信には HTTP または HTTPS が使用されます。

セキュリティー保護されたモードでは、SSL を使用してクライアントとゲートウェイ間のインターネット上の接続を暗号化しています。また、SSL はゲートウェイとサーバー間の接続の暗号化にも使用されます。イントラネットとインターネット間にゲートウェイが存在することで、クライアントと Portal Server 間のパスの安全性が強化されます。

図 1–2 Secure Remote Access を使用するセキュリティー保護されたモードの Portal Server

Secure Remote Access を使用するセキュリティー保護されたモードの Portal Server

サーバーとゲートウェイをさらに追加して、サイトを拡張することができます。Secure Remote Access ソフトウェアは、ビジネスの要件に基づいてさまざまな方法で構成することができます。ビジネス要件への対応方法の詳細については、『Sun Java System Portal Server 7.2 Deployment Planning Guide 』を参照してください。

Secure Remote Access サービス

Secure Remote Access ソフトウェアには、次に示す 5 つの主要なコンポーネントがあります。

Secure Remote Access 属性の設定

Secure Remote Access の属性は、Portal Server 管理コンソールで次のサービスを使用して設定します。

注意 – 注意 –

ゲートウェイの実行中に行われた属性変更は、ゲートウェイに通知されません。更新された (ゲートウェイまたはその他のサービスに属する) プロファイル属性を有効にするには、ゲートウェイを再起動します。詳細については、「コマンド行オプションによるゲートウェイ属性の設定」を参照してください。

競合解決の設定

Procedure競合の解決レベルを設定する

  1. 『Sun Java System Portal Server 7.2 管理ガイド』の「管理コンソールにログインする」

  2. 「Secure Remote Access」タブを選択し、適切なサービスタブ (「ネットレット」、「ネットファイル」、または「プロキシレット」) をクリックします。

  3. 「DN を選択」ドロップダウンメニューから「組織」または「ロール」を選択します。

  4. 「COS 優先順位」ドロップダウンボックスで適切な競合解決レベルを選択します。

  5. 「保存」をクリックして終了します。

サポートされるアプリケーション

SRA は、次のアプリケーションをサポートします。

準備

Procedureポータル用の SRA を有効にする

  1. PortalServer_base/bin/psadmin switch-sra-status -u amadmin -f <passwordfile> on コマンドを使用して、SRA の状態を切り替えます。

  2. PortalServer_base/bin/psadmin provision-sra -u amadmin -f <passwordfile> -p <portal-id> --gateway-profile <profile-name> --enable コマンドを使用して、SRA の状態をプロビジョニングします。

第 2 章 ゲートウェイの操作

この章では、ゲートウェイに関連する概念について説明します。ゲートウェイの管理については、第 16 章「ゲートウェイの管理」を参照してください。ゲートウェイの設定については、第 8 章「Secure Remote Access ゲートウェイの設定」を参照してください。

この章の内容は次のとおりです。

ゲートウェイの概要

ゲートウェイは、インターネットから送信されるリモートユーザーセッションと企業イントラネットの間のインタフェースおよびセキュリティーバリアとして機能します。ゲートウェイはリモートユーザーとの単一のインタフェースを通じて、内部 Web サーバーとアプリケーションサーバーのコンテンツを安全に提供します。

ゲートウェイインスタンスごとに、次のタスクを完了してください。

そのほかに、次のゲートウェイ関連トピックがあります。

ゲートウェイプロファイルの作成

ゲートウェイプロファイルには、ゲートウェイが待機するポート、SSL オプション、およびプロキシオプションなどのゲートウェイの設定に関連したすべての情報が収められています。ゲートウェイをインストールする場合、デフォルトの値を選択すると、「default」という名前のデフォルトゲートウェイプロファイルが作成されます。デフォルトプロファイルに相当する設定ファイルは、次の場所にあります。/etc/opt/SUNWportal/platform.conf.default

/etc/opt/SUNWportal は、すべての platform.conf.* ファイルが格納されるデフォルトの場所です。platform.conf ファイルの詳細については、「platform.conf ファイルの概要」を参照してください。

プロファイルを操作するときは、次の作業を実行できます。

注意 – 注意 –

同じマシン上で稼動するゲートウェイの複数のインスタンスには、同じプロファイルを割り当てないでください。このように設定すると、ポート番号が同じになることにより競合が発生します。

また、同じゲートウェイに作成された複数のプロファイルに、同じポート番号を指定しないでください。同じゲートウェイの複数のインスタンスを同じポートで実行すると、競合が発生します。

複数のゲートウェイインスタンスの作成

複数のゲートウェイインスタンスの作成については、『Sun Java System Portal Server 7.2 Installation and Configuration Guide』の第 4 章「Installing and Configuring a Gateway With Portal Server」を参照してください。

マルチホームゲートウェイのインスタンスの作成

マルチホームゲートウェイのインスタンスとは、1 つの Portal Server 上に作成された複数のゲートウェイです。これらのインスタンスを作成するには、platform.conf ファイルを次のように変更します。

gatewaybindipaddress = 0.0.0.0

同じ LDAP を使用するゲートウェイインスタンスの作成

最初のゲートウェイを作成したあとで、同じ LDAP を使用する複数のゲートウェイを作成する場合は、次の操作を行います。

次の部分を参照しながら、/etc/opt/SUNWam/config/ の AMConfig-instance-name.properties を、最初にインストールしたゲートウェイインスタンスと一致するように変更します。

「同じ LDAP を使用するゲートウェイインスタンスを作成する」を参照してください。

ゲートウェイの再起動

通常はゲートウェイを再起動する必要はありません。再起動が必要なのは、次のいずれかに該当する場合だけです。

ゲートウェイウォッチドッグの設定

ウォッチドッグがゲートウェイを監視する間隔を設定することができます。ウオッチドッグを開始または停止するには、次のコマンドを実行します。./psadmin sra-watchdog -u amadmin -f <password-file> -t <type> on|offこの間隔は、デフォルトでは 60 秒に設定されています。この値を変更する場合は、crontab ユーティリティーで次の行を編集します。


0-59 * * * * gateway-install-root/SUNWportal/bin/
/var/opt/SUNWportal/.gw. 5 > /dev/null 2>&1

crontab のエントリを設定する方法については、crontab のマニュアルページを参照してください。

仮想ホストの指定

仮想ホストとは、同じマシンの IP とホスト名をポイントする追加のホスト名のことです。たとえば、ホスト名 abc がホスト IP アドレス 192.155.205.133 をポイントしている場合には、同じ IP アドレスをポイントする別のホスト名 cde を追加できます。

Access Manager へアクセスするプロキシの設定

ゲートウェイが、Portal Server に配備されている SRA コア (RemoteConfigServlet) にアクセスするために使用するプロキシホストを指定することができます。このプロキシは、Portal Server および Access Manager にアクセスするためにゲートウェイが使用します。「プロキシを指定する」を参照してください。

platform.conf ファイルの概要

platform.conf ファイルは、デフォルトでは次の場所にあります。/etc/opt/SUNWportal

platform.conf ファイルには、ゲートウェイが必要とする詳細情報が収められています。ここでは、サンプルの platform.conf ファイルを提示し、すべてのエントリについて説明します。

マシン固有の詳細を設定ファイルにすべて格納しているため、複数のマシンで実行するゲートウェイが共通のプロファイルを共有できるという利点があります。

次に platform.conf ファイルのサンプルを示します。


Tue May 30 11:51:23 IST 2006
debug.com.sun.portal.rewriter.original.level=INFO
gateway.favicon=
gateway.bindipaddress=10.12.154.236
debug.com.sun.portal.sra.rproxy.toFromServer.handler.java.util.logging.FileHandler.pattern=
/var/opt/SUNWportal/logs/sra/default/Gateway.toFromServer.%u.%g.log
gateway.port=443
rewriterproxy.jvm.flags=-ms64m -mx128m
portal.server.instance=default
debug.com.sun.portal.handler.java.util.logging.FileHandler.filter=
gateway.jdk.dir=/usr/jdk/entsys-j2se
gateway.ignoreURIList=/MSOffice/cltreq.asp,/_vti_bin/owssvr.dll
debug.com.sun.portal.rewriter.rest.level=INFO
gateway.trust_all_server_certs=true
debug.com.sun.portal.handler.java.util.logging.FileHandler.append=true
gateway.cdm.cacheCleanupTime=300000
gateway.httpurl=
debug.com.sun.portal.handler.java.util.logging.FileHandler.count=1
gateway.jvm.classpath=
debug.com.sun.portal.setserverlogs=false
gateway.protocol=https
debug.com.sun.portal.sra.rproxy.toFromServer=java.util.logging.FileHandler
rewriterproxy.jvm.classpath=
gateway.enable.customurl=false
debug.com.sun.portal.sra.rproxy.toFromBrowser=java.util.logging.FileHandler
debug.com.sun.portal.handler.java.util.logging.FileHandler.formatter=com.sun.portal.
log.common.PortalLogFormatter
debug.com.sun.portal.sra.rproxy.toFromBrowser.handler.java.util.logging.FileHandler.pattern=
/var/opt/SUNWportal/logs/sra/default/Gateway.toFromBrowser.%u.%g.log
debug.com.sun.portal.level=INFO
debug.com.sun.portal.rewriter.unaffected.separatefile=true
gateway.enable.accelerator=false
debug.com.sun.portal.rewriter.original.separatefile=true
gateway.virtualhost=nicp236.india.sun.com 10.12.154.236
debug.com.sun.portal.stacktrace=true 
gateway.host=nicp236.india.sun.com
debug.com.sun.portal.handler.java.util.logging.FileHandler.pattern=
/var/opt/SUNWportal/logs/sra/default/%logger.%sraComponentType.%u.%g.log
gateway.certdir=/etc/opt/SUNWportal/cert/default
gateway.sockretries=3
gateway.allow.client.caching=true
debug.com.sun.portal.rewriter.unaffected.level=INFO
debug.com.sun.portal.rewriter.uriinfo.separatefile=true
log.config.check.period=2000
debug.com.sun.portal.rewriter.rewritten.level=INFO
gateway.userProfile.cacheSize=1024
debug.com.sun.portal.rewriter.rulesetinfo.level=INFO
netletproxy.jvm.classpath=
gateway.userProfile.cacheSleepTime=60000
debug.com.sun.portal.rewriter.uriinfo.level=INFO
debug.com.sun.portal.rewriter.rest.separatefile=true
gateway.notification.url=notification
debug.com.sun.portal.rewriter.rulesetinfo.separatefile=true
gateway.logdelimiter=&&
gateway.ignoreServerList=false
gateway.jvm.flags=-ms64m -mx128m
debug.com.sun.portal.handler.java.util.logging.FileHandler.limit=5000000
gateway.dsame.agent=http\://sunone216.india.sun.com\:8080/portal/RemoteConfigServlet
gateway.httpsurl=
gateway.retries=6
gateway.userProfile.cacheCleanupTime=300000
gateway.logging.password=X03MO1qnZdYdgyfeuILPmQ\=\= UX9x0jIua3hx1YOVRG/TLg\=\=
netletproxy.jvm.flags=-ms64m -mx128m
debug.com.sun.portal.rewriter.rewritten.separatefile=true
gateway.user=noaccess
gateway.external.ip=10.12.154.236
debug.com.sun.portal.handler=java.util.logging.FileHandler
gateway.cdm.cacheSleepTime=60000
rewriterproxy.accept.from.gateways=
rewriterproxy.checkacl=false

次の表は、platform.conf ファイルのすべてのフィールドと、その説明を示しています。

表 2–1 ファイルのプロパティー

エントリ 

デフォルト値 

説明 

gateway.user

noaccess 

ゲートウェイは、このユーザーとして実行されます。 

ゲートウェイは root として起動する必要があり、初期化のあと、root 権限を失いこのユーザーになります。 

gateway.jdk.dir

 

ゲートウェイが使用する JDK ディレクトリの場所。 

gateway.dsame.agent

 

ゲートウェイが起動中にそのプロファイルを取得するために通信する Access Manager の URL。 

portal.server.protocol

portal.server.host

portal.server.port

 

デフォルトの Portal Server が使用しているプロトコル、ホスト、およびポート。 

gateway.protocolgateway. hostgateway.port

 

ゲートウェイのプロトコル、ホスト、およびポート。これらの値は、インストール時に指定したモードおよびポートと同じです。これらの値は通知 URL の作成に使用されます。 

gateway. trust_all_server_certs

true 

ゲートウェイがすべてのサーバーの証明書を信頼する必要があるか、またはゲートウェイ認証データベースの証明書のみを信頼するべきかを指定します。 

gateway. trust_all_server_cert_domains

false 

ゲートウェイとサーバーの間で SSL 通信が行われるとき、サーバーの証明書がゲートウェイに提示されます。デフォルトでは、ゲートウェイはサーバーのホスト名がサーバーの証明書 CN と同じであるかどうかを検査します。 

この属性値が true に設定されている場合、ゲートウェイは受け取ったサーバーの証明書に対するドメインチェックを無効にします。 

gateway.virtualhost

 

ゲートウェイマシンに複数のホスト名が設定されている場合、このフィールドで別の名前およびアイデンティティープロバイダアドレスを指定できます。 

gateway.virtualhost. defaultOrg=org

 

ユーザーがログインするデフォルトの org を指定します。 

たとえば、仮想ホストフィールドのエントリが次のようになっていると仮定します。 

gateway.virtualhost=test.com employee.test.com

Managers.test.com

この場合、デフォルトの org エントリは次のようになります。 

test.com.defaultOrg = o=root,dc=test,dc=com

employee.test.com.defaultOrg = o=employee,dc=test,dc=com

Manager.test.com.defaultOrg = o=Manager,dc=test,dc=com

ユーザーは https://manager.test.com を使用して、https://test.com/o=Manager,dc=test,dc=com ではなくマネージャーの org にログインできます。

注 –

virtualhost と defaultOrg は platform.conf file ファイルでは大文字と小文字が区別されますが、URL で使用する場合は区別されません。

gateway.notification.url

 

ゲートウェイのホスト、プロトコル、およびポートの組み合わせが、通知 URL の作成に使用されます。これは Access Manager からセッション通知を受け取るときに使用されます。 

notification URL が組織名と一致しないことを確認します。通知 URL が組織名と一致する場合、その組織に接続しようとするとログインページではなく空のページが表示されます。 

gateway.retries

 

ゲートウェイが起動時に Portal Server にアクセスを試みる回数。 

gateway.debug

error

ゲートウェイのデバッグレベルを設定します。デバッグログファイルの場所は、debug-directory/files です。デバッグファイルの場所は、gateway.debug.dir エントリで指定されます。

次のデバッグレベルがあります。 

  • error: 重要なエラーのみがデバッグファイルにログとして記録される。このようなエラーが発生すると、通常はゲートウェイの機能が停止する。

  • warning: 警告メッセージがログとして記録される。

  • message: すべてのデバッグメッセージがログとして記録される。

  • on: すべてのデバッグメッセージがコンソールに表示される。

次のデバッグファイルがあります。 

srapGateway.gateway-profile-name : ゲートウェイデバッグメッセージを格納する。

Gateway_to_from_server.gateway-profile-name : メッセージモードの場合、ゲートウェイと内部サーバーの間のすべての要求と応答のヘッダーがこのファイルに格納される。

このファイルを生成するには、/var/opt/SUNWportal/debug ディレクトリの書き込み権を変更します。

Gateway_to_from_browser.gateway-profile-name : メッセージモードの場合、ゲートウェイとクライアントブラウザの間のすべての要求と応答のヘッダーがこのファイルに格納される。

このファイルを生成するには、/var/opt/SUNWportal/debug ディレクトリの書き込み権を変更します。

gateway.debug.dir

 

すべてのデバッグファイルが生成されるディレクトリ。 

このディレクトリは、gateway.user 内のユーザーがファイルの書き込みを行うための十分な権限を必要とします。

gateway.logdelimiter

 

現在は使用されていません。 

gateway.external.ip

 

複数の IP アドレスを持つマルチホームゲートウェイマシンでは、外部 IP アドレスをここで指定する必要があります。この IP は、ネットレットが FTP を実行するために使用されます。 

gateway.certdir

 

証明書データベースの場所を指定します。 

gateway.allow.client.caching

true 

クライアントのキャッシングを許可または拒否します。 

許可する場合、クライアントのブラウザでは、スタティックページおよびイメージをキャッシュして (ネットワークトラフィックを低減することで) パフォーマンスを向上できます。 

拒否する場合、キャッシュは行われずセキュリティーは高まりますが、ネットワークの負荷が増えるのでパフォーマンスは低下します。 

gateway.userProfile.cacheSize

 

ゲートウェイでキャッシュされるユーザープロファイルのエントリ数。エントリ数がこの値を超えると、キャッシュのクリーンアップが頻繁に再試行されます。 

gateway.userProfile. cacheSleepTime

 

キャッシュクリーンアップのためのスリープ時間 (秒単位) を設定します。 

gateway.userProfile. cacheCleanupTime

 

プロファイルエントリが削除されるまでの最大時間 (秒)。 

gateway.bindipaddress

 

マルチホームマシンで、ゲートウェイがサーバーソケットをバインドする IP アドレス。すべてのインタフェースを待機するようにゲートウェイを設定するには、IP アドレスを gateway.bindipaddress=0.0.0.0 に置き換えます。

gateway.sockretries

3 

現在は使用されていません。 

gateway.enable.accelerator

false 

true に設定した場合、外部アクセラレータの使用が許可されます。 

gateway.enable.customurl

false 

true に設定した場合、管理者はゲートウェイがページを書き換えるためのカスタム URL を指定できます。 

gateway.httpurl

 

ゲートウェイがページを書き換えるためのカスタム URL 用の HTTP 逆プロキシ URL。プロキシレットが有効の場合、このエントリを使用します。 

gateway.httpsurl

 

ゲートウェイがページを書き換えるためのカスタム URL 用の HTTPS 逆プロキシ URL。プロキシレットが有効の場合、このエントリを使用しないでください。 

gateway.favicon

 

favicon.icon ファイルに対する要求をゲートウェイがリダイレクトする URL。

これは、Internet Explorer および Netscape 7.0 以降の「お気に入り」のアイコンとして使用されます。 

何も指定しない場合、ゲートウェイはファイルが見つからないことを意味する 404 メッセージをブラウザに返します。 

gateway.logging.password

 

ゲートウェイがアプリケーションセッションの作成に使用する amService-srapGateway ユーザーの LDAP パスワード。

暗号化された形式、プレーンテキストのいずれかを指定できます。 

http.proxyHost

 

このプロキシホストが Portal Server へのアクセスに使用されます。 

http.proxyPort

 

Portal Server へのアクセスに使用されるホスト用のポート。 

http.proxySet

 

プロキシホストが必要な場合は、このプロパティーを true に設定します。false に設定すると、http.proxyHost および http.proxyPort は無視されます。

portal.server.instance

 

このプロパティーの値には、対応する /etc/opt/SUNWam/config/AMConfig-instance-name.properties ファイルを指定します。この値がデフォルトの場合は、AMConfig.properties をポイントします。

gateway.cdm.cacheSleepTime

60000 

クライアント検出モジュールの応答で、Access Manager からゲートウェイに送信されるキャッシュのタイムアウト値。 

gateway.cdm.cacheCleanupTime

300000 

クライアント検出モジュールの応答で、Access Manager からゲートウェイに送信されるキャッシュのタイムアウト値。 

netletproxy.port

10555 

ネットレットプロキシデーモンは、このポートで要求を待機します。 

rewriterproxy.port

10555 

リライタプロキシデーモンは、このポートで要求を待機します。 

gateway.ignoreServerList

false 

true に設定した場合、Access Manager サーバーの URL は AMConfig.properties ファイルで指定した値を使用して作成されます。Access Manager サーバーがロードバランサの背後にある場合、このプロパティーを true に設定します。

rewriterproxy.accept.from.gateways

 

これは、リライタプロキシでの要求の受け入れを可能にする IP アドレスのリストです。HTTP モードと HTTPS モードの両方で機能します。これはセキュリティーを高める目的で使用されます。このリストのアドレスからの要求のみが受け入れられ、その他の要求は一切処理されません。各 IP アドレスをコンマで区切って指定できます。デフォルト値は空で、その場合は旧バージョンモードとして扱われます。つまり、リライタプロキシへのすべての要求が受け入れられます。 

rewriterproxy.checkacl=

false 

このプロパティーが有効になっている場合、リライタプロキシは、ゲートウェイと同じように ACL の値をチェックします。旧バージョンモードの値は false です。true に設定すると、リライタプロキシは指定された DN で、URL をゲートウェイアクセスサービスに指定された値と照合し、リストの設定に従って要求を許可または拒否します。この値は、HTTP モードと HTTPS モードの両方で機能します。 

Web プロキシの使用

SUN 以外の Web プロキシを使用して HTTP リソースにアクセスするように、ゲートウェイを設定できます。Web プロキシは、クライアントとインターネットの間に設置されます。

Web プロキシの設定

ドメインおよびサブドメインごとに異なるプロキシを使用できます。これらのエントリから、特定のドメインの特定のサブドメインへのアクセスに使用するプロキシがゲートウェイに伝えられます。ゲートウェイで指定したプロキシ設定は次のように機能します。

注 –

標準のポータルデスクトップのブックマークチャネルを通じて URL にアクセスする場合、前述したいずれの条件にも合わない場合は、ゲートウェイはブラウザにリダイレクトを送信します。ブラウザは独自のプロキシ設定を使用して URL にアクセスします。

構文


domainname [web_proxy1:port1]|subdomain1 [web_proxy2:port2]|

例


sesta.com wp1:8080|red wp2:8080|yellow|* wp3:8080

* はすべてに一致するワイルドカードです。

各表記の意味は次のとおりです。

sesta.com はドメイン名、wp1 はポート 8080 にアクセスするプロキシです。

red はサブドメイン、wp2 はポート 8080 にアクセスするプロキシです。

yellow はサブドメインです。プロキシが指定されていないため、ドメインに指定されたプロキシ、つまりポート 8080 の wp1 が使用されます。

* は、ほかのすべてのサブドメインがポート 8080 で wp3 を使用する必要があることを表します。

注 –

デフォルトでは、ポートを指定しない場合ポート 8080 が使用されます。

Web プロキシ情報の処理

クライアントが特定の URL へのアクセスを試みると、URL のホスト名が「ドメインとサブドメインのプロキシ」リスト内のエントリと照合されます。指定されたホスト名でもっとも長いサフィックスに一致するエントリが選ばれます。たとえば、ホスト名 host1.sesta.com が要求されているとします。一致するエントリが見つかるまで、次の検索が順に行われます。

「ドメインとサブドメインのプロキシ」リストに次のようなエントリがあるとします。


com p1| host1 p2 | host2 | * p3
sesta.com p4 | host5 p5 | * p6
florizon.com | host6
abc.sesta.com p8 | host7 p7 | host8 p8 | * p9
host6.florizon.com p10
host9.sesta.com p11
siroe.com | host12 p12 | host13 p13 | host14 | * p14
siroe.com | host15 p15 | host16 | * p16
* p17

ゲートウェイは、次の表に示すように、これらのエントリを内部的に 1 つのテーブルにマッピングします。

表 2–2 「ドメインとサブドメインのプロキシ」リストのエントリのマッピング

番号 

「ドメインとサブドメインのプロキシ」リストのエントリ 

プロキシ 

説明 

1 

com 

p1 

リストで指定されたプロキシ 

2 

host1.com 

p2 

リストで指定されたプロキシ 

3 

host2.com 

p1 

host2 に対してプロキシが指定されないため、ドメインのプロキシが使用されます。 

4 

*.com 

p3 

リストで指定されたプロキシ 

5 

sesta.com 

p4 

リストで指定されたプロキシ 

6 

host5.sesta.com 

p5 

リストで指定されたプロキシ 

7 

*.sesta.com 

p6 

リストで指定されたプロキシ 

8 

florizon.com 

直接 

詳細はエントリ 14 の説明を参照 

9 

host6.florizon.com 

– 

詳細はエントリ 14 の説明を参照 

10 

abc.sesta.com 

p8 

リストで指定されたプロキシ 

11 

host7.abc.sesta.com 

p7 

リストで指定されたプロキシ 

12 

host8.abc.sesta.com 

p8 

リストで指定されたプロキシ 

13 

*.abc.sesta.com 

p9 

リストで指定されたプロキシabc.sesta.com ドメインの host7 と host8 以外のすべてのホストについては、p9 がプロキシとして使用されます。

14 

host6.florizon.com 

p10 

エントリ 9 と同じエントリ。エントリ 9 は直接接続を指定するのに対し、このエントリはプロキシ p10 の使用を指定します。このような 2 つのエントリがある場合、プロキシ情報のあるエントリが有効なエントリと見なされます。もう 1 つのエントリは無視されます。 

15 

host9.sesta.com 

p11 

リストで指定されたプロキシ 

16 

siroe.com 

直接 

siroe.com に対して指定されるプロキシがないため、直接接続が試みられます。

17 

host12.siroe.com 

p12 

リストで指定されたプロキシ 

18 

host13.siroe.com 

p13 

リストで指定されたプロキシ 

19 

host14.siroe.com 

直接 

host14 に対して指定されるプロキシがないため、直接接続が試みられます。

20 

*.siroe.com 

p14 

エントリ 23 の説明を参照 

21 

host15.siroe.com 

p15 

リストで指定されたプロキシ 

22 

host16.siroe.com 

直接 

host16 または siroe.com に対して指定されるプロキシがないため、直接接続が試みられます。

23 

*.siroe.com 

p16 

エントリ 20 に類似していますが、指定されるプロキシが異なります。このような場合、ゲートウェイの正確な動作がわかりません。2 つのプロキシのいずれかが使用されます。 

24 

* 

p17 

要求された URL に一致するエントリが存在しない場合、プロキシとして p17 が使用されます。

ヒント –

「ドメインとサブドメインのプロキシ」リストでは、プロキシエントリを「|」記号で区切らずに、個々のエントリをリスト内の各行に配置できます。たとえば、次のように表記されるエントリがあるとします。


sesta.com p1 | red p2 | * p3

この情報は次のように指定できます。


sesta.com p1
red.sesta.com p2
*.sesta.com p3

このようなリスト形式にすると、反復されたエントリやその他のあいまいなエントリを追跡しやすくなります。

ドメインとサブドメインのプロキシリストに基づく書き換え

リライタも、「ドメインとサブドメインのプロキシ」リストのエントリを使用します。リライタは、ドメインが「ドメインとサブドメインのプロキシ」リストのドメインに一致するすべての URL を書き換えます。

注意 – 注意 –

「ドメインとサブドメインのプロキシ」リストのエントリ * は、書き換えの対象と見なされません。たとえば、エントリ 24 は書き換えの対象になりません。

リライタについては、第 4 章「リライタの操作」を参照してください。

デフォルトのドメインとサブドメイン

URL の最終ホストが完全修飾名になっていない場合、完全修飾名に到達するためにデフォルトのドメインおよびサブドメインが使用されます。

管理コンソールの「デフォルトのドメイン」フィールドに、次のエントリが設定されていると仮定します。


red.sesta.com
注 –

「ドメインとサブドメインのプロキシ」リストには、対応するエントリが必要です。

前述した例では、sesta.com がデフォルトのドメイン、デフォルトのサブドメインは red です。

要求された URL が host1 の場合、このエントリはデフォルトのドメインとサブドメインを使用して host1.red.sesta.com として解決されます。「ドメインとサブドメインのプロキシ」リストに host1.red.sesta.com があるかどうかが確認されます。

自動プロキシ設定の使用

「ドメインとサブドメインのプロキシ」リストの情報を無視するには、自動プロキシ設定機能を有効にします。

プロキシ自動設定 (PAC) ファイルを使用するときは、次の点に注意してください。

サンプル PAC ファイルの使用

次の例は、「ドメインとサブドメインのプロキシ」リストに含まれる URL と、それに対応する PAC ファイルを示しています。

DIRECT または NULL のいずれかが返される例

次のプロキシをドメインとサブドメインに使用する場合を考えます。

*intranet1.com proxy.intranet.com:8080

intranet2.com proxy.intranet1.com:8080

対応する PAC ファイルは次のようになります。


// Start of the PAC File
function FindProxyForURL(url, host) {
         if (dnsDomainIs(host, ".intranet1.com")) {
             return "DIRECT";
         }
          if (dnsDomainIs(host, ".intranet2.com")) {
              return "PROXY proxy.intranet1.com:8080";
          }
          return "NULL";
}
//End of the PAC File

STARPROXY が返される例

次のプロキシをドメインとサブドメインに使用する場合を考えます。

intranet1.com

intranet2.com.proxy.intranet1.com:8080

internetproxy.intranet1.com:80

対応する PAC ファイルは次のようになります。


// Start of the PAC File
function FindProxyForURL(url, host) {
          if (dnsDomainIs(host, ".intranet1.com")) {
              return "DIRECT";
          }
          if (dnsDomainIs(host, ".intranet2.com")) {
              return "PROXY proxy.intranet1.com:8080;" +
                  "PROXY proxy1.intranet1.com:8080";
          }
          return "STARPROXY internetproxy.intranet1.com:80";
}
//End of the PAC File

この場合、要求が .intranet2.com ドメイン内のホストに対するものであれば、ゲートウェイは proxy.intranet1.com:8080 にアクセスします。proxy.intranet1.com:8080 がダウンしている場合、要求は失敗します。ゲートウェイは、フェイルオーバーを行わず、proxy1.intranet1.com:8080 にアクセスします。

PAC ファイルの場所の指定

PAC ファイルの場所を指定するための形式は、その場所により次のようになります。

個別のセッションにおけるサービスの追加

個別のセッションで Portal Server サービスを追加する場合は、次の操作を行います。

ネットレットプロキシの使用

ネットレットパケットはゲートウェイで解読され、宛先サーバーに送られます。ただし、ゲートウェイはすべてのネットレット接続先ホストにアクセスする場合、非武装ゾーン (DMZ) とイントラネット間のファイアウォールを経由する必要があります。このように設定するには、ファイアウォールで多くのポートを開かなければなりません。ネットレットプロキシを使用することで、ファイアウォールで開かれるポートの数を最小化することができます。

ネットレットプロキシは、ゲートウェイを経由してクライアントからのセキュリティー保護されたトンネルをイントラネット内のネットレットプロキシまで拡張することで、ゲートウェイとイントラネット間のセキュリティーを補強します。プロキシを使用すると、ネットレットパケットがネットレットプロキシにより解読され、送信先に送られます。

ネットレットプロキシを使用する利点を次に示します。

次の作業を実行できます。

ネットレットプロキシをインストールした場合とインストールしない場合のゲートウェイと Portal Server の 3 つの実装例を示します。クライアント、2 つのファイアウォール、2 つのファイアウォールの間にあるゲートウェイ、Portal Server、およびネットレット宛先サーバーから構成されます。

最初の例では、ネットレットプロキシをインストールしていないゲートウェイと Portal Server を示しています。データの暗号化はクライアントとゲートウェイの間だけで行われます。ネットレット接続の要求があるたびに、2 番目のファイアウォールでポートが開かれます。

2 番目の例では、ゲートウェイと、ネットレットプロキシがインストールされている Portal Server を示しています。データの暗号化はクライアントから Portal Server までのすべての区間に拡張されています。すべてのネットレットがネットレットプロキシを通じてルーティングされているため、ネットレット要求に対して 2 番目のファイアウォールで開く必要があるのは 1 つのポートのみです。

3 番目の例では、ネットレットプロキシが別のノードにインストールされている Portal Server とゲートウェイを示しています。別のノードにネットレットプロキシをインストールすると、Portal Server ノードの負荷が減少します。この場合も、2 番目のファイアウォールで開く必要があるのは 2 つのポートのみです。1 つのポートは Portal Server への要求を処理し、もう 1 つのポートはネットレットの要求をネットレットプロキシサーバーにルーティングします。

図 2–1 ネットレットプロキシの実装

ネットレットプロキシの実装

ネットレットプロキシの有効化

ネットレットプロキシは、Portal Server 管理コンソールを使用して、ゲートウェイサービスから有効にします。

ネットレットプロキシの再起動

プロキシが何らかの理由で強制終了した場合に再起動するように、ネットレットプロキシを設定することができます。ネットレットプロキシを監視し、ネットレットプロキシが停止したときに再起動するように ウォッチドッグプロセスをスケジューリングできます。

ネットレットプロキシは手動で再起動することもできます。手順については、「ネットレットプロキシを再起動する」を参照してください。

ネットレットプロキシのウォッチドッグを設定する

ウォッチドッグがネットレットプロキシの状態を監視する間隔を設定することができます。この間隔は、デフォルトでは 60 秒に設定されています。この間隔を変更するには、crontab ファイルに次の行を追加します。

0-59 * * * * netlet-install-dir/bin/checkgw /var/opt/SUNWportal/.gw 5 > /dev/null 2>&1

注 –

ウオッチドッグを開始または停止するには、次のコマンドを実行します。./psadmin sra-watchdog -u amadmin -f <password-file> -t <type> on|off

リライタプロキシの使用

リライタプロキシは、イントラネット上にインストールされます。ゲートウェイは、コンテンツを直接取得せずにすべての要求をリライタプロキシに送信し、リライタプロキシはコンテンツを取得してゲートウェイに返します。

リライタプロキシを使用する利点を次に示します

リライタプロキシを指定しない場合、いずれかのイントラネットコンピュータにアクセスしようとすると、ゲートウェイコンポーネントによりイントラネットコンピュータに直接つながります。

リライタプロキシをロードバランサとして使用する場合は、リライタの platform.conf.instance_name がロードバランサ URL をポイントしている必要があります。また、ロードバランサのホストを Portal Servers リストに指定してください。

ゲートウェイインスタンスごとに (Portal Server ノード上でなくてもかまわない) リライタプロキシの複数インスタンスがある場合は、platform.conf ファイルに、リライタプロキシに対して 1 つのポートエントリを指定するのではなく、host-name:port の形式でリライタプロキシごとに詳細を指定します。

リライタプロキシのインスタンスの作成

リライタプロキシの新しいインスタンスを Portal Server ノードに作成するときは、rwpmultiinstance スクリプトを使用します。このスクリプトは、ゲートウェイプロファイルが作成されたあとで実行します。

「リライタプロキシインスタンスを作成する」を参照してください。

リライタプロキシの有効化

リライタプロキシを有効化するときは、Access Manager 管理コンソールの「SRA 設定」の下にある「ゲートウェイ」サービスを使用します。

リライタプロキシの再起動

プロキシが何らかの理由で強制終了した場合に、リライタプロキシが再起動するように設定することができます。リライタプロキシを監視し、リライタプロキシが強制終了したときに再起動するように ウォッチドッグプロセスをスケジューリングできます。

リライタプロキシは手動で再起動することもできます。

「リライタプロキシを再起動する」を参照してください。

リライタプロキシのウォッチドッグの設定

ウォッチドッグがリライタプロキシの状態を監視する間隔を設定することができます。この間隔は、デフォルトでは 60 秒に設定されています。この間隔を変更するには、crontab ファイルに次の行を追加します。

0-59 * * * * rewriter-proxy-install-root /bin/checkgw /var/opt/SUNWportal/.gw 5 > /dev/null 2>&1

注 –

ウオッチドッグを開始または停止するには、次のコマンドを実行します。./psadmin sra-watchdog -u amadmin -f <password-file> -t <type> on|off

ゲートウェイでの逆プロキシの使用

プロキシサーバーがインターネットのコンテンツをイントラネットに配信するのに対して、逆プロキシサーバーはイントラネットのコンテンツをインターネットに配信します。逆プロキシを配備するときに、負荷分散およびキャッシングが行われるように設定できます。

ゲートウェイの前にサードパーティーの逆プロキシがある配備の場合、応答は、ゲートウェイの URL ではなく逆プロキシの URL で書き換えられる必要があります。このためには、逆プロキシを有効化する必要があります。

「逆プロキシを有効化する」を参照してください。

クライアント情報の取得

ゲートウェイがいずれかの内部サーバーにクライアント要求を転送するときに、HTTP 要求に HTTP ヘッダーが追加されます。それらのヘッダーを使用して追加のクライアント情報を取得し、ゲートウェイの存在を検出することができます。

HTTP 要求ヘッダーを表示するには、platform.conf ファイル内のエントリを gateway.error=message に設定します。次に、サーブレット API から request.getHeader() を使用します。次の表は、HTTP ヘッダー内の情報を示しています。

表 2–3 HTTP ヘッダーの情報

ヘッダー 

構文 

説明 

PS-GW-PDC 

X-PS-GW- PDC: true/false

ゲートウェイで PDC が有効であるかどうかを示します。 

PS-Netlet 

X-PS-Netlet:enabled=true/false

ゲートウェイでネットレットが有効化されているか、それとも無効化されているかを示します。 

ネットレットが有効化されている場合は、暗号化オプションが生成され、ゲートウェイが HTTPS モード (encryption=ssl) または HTTP モード (encryption=plain) のどちらで実行されているかが示されます。

次に例を示します。 

  • PS-Netlet: enabled=false

    ネットレットは無効化されています。

  • PS-Netlet: enabled=true; encryption=ssl

    ネットレットは有効で、ゲートウェイは SSL モードで稼動しています。

    ネットレットが有効でない場合は、encryption=ssl または encryption=plain は生成されません。

PS-GW-URL 

X-PS-GW-URL: http(s)://gatewayURL(:port)

クライアントが接続している URL を示します。 

ポートが標準ポートでない場合 (ゲートウェイが HTTP/HTTPS モードで稼動し、ポートが 80/443 でない場合など) は、:port が追加されます。

PS-GW-Rewriting-URL 

X-PS-GW-URL: http(s)://gatewayURL(:port)/[SessionInfo]

ゲートウェイがすべてのページを書き換える URL を示します。 

  1. ブラウザが Cookie をサポートする場合、このヘッダーの値は PS-GW-URL ヘッダーと同じです。

  2. ブラウザが Cookie をサポートしない場合は、次のようになります。

    • 接続先ホストが「ユーザーセッション Cookie を転送する URL」フィールドに含まれる場合は、ゲートウェイがページを書き換える実際の URL (符号化されたセッション ID 情報が含まれる)

    • 接続先ホストが「ユーザーセッション Cookie を転送する URL」フィールドに含まれない場合は、SessionInfo 文字列は $SessionID となる

      注 –

      認証ページからの応答のように、応答の過程でユーザーの Access Manager のセッション ID が変更された場合、ページは、それまでヘッダーに指定されていた値ではなくその値で書き換えられます。

      次に例を示します。

    • ブラウザが Cookie をサポートする場合は、次のようになります。

PS-GW-Rewriting-URL: https://siroe.india.sun.com:10443/ 

  • ブラウザが Cookie をサポートせず、エンドサーバーが「ユーザーセッション Cookie を転送する URL」フィールドに含まれる場合は、次のようになります。

PS-GW-Rewriting-URL: https://siroe.india.sun.com:10443/SessIDValCustomEncodedValue/ 

  • ブラウザが Cookie をサポートしないが、エンドサーバーが「ユーザーセッション Cookie を転送する URL」フィールドに含まれない場合は、次のようになります。

PS-GW-Rewriting-URL: https://siroe.india.sun.com:10443/$SessionID 

PS-GW-CLientIP 

X-PS-GW-CLientIP: IP

ゲートウェイが recievedSocket.getInetAddress().getHostAddress() から取得した IP を示します。

クライアントがゲートウェイに直接接続する場合、この値によって IP が特定されます。 

認証連鎖の使用

認証連鎖することにより、通常の認証メカニズムより高いレベルのセキュリティーがもたらされます。ユーザーを複数の認証メカニズムで認証することができます。

ここでは、PDC (Personal Digital Certificate) 認証によってゲートウェイで認証連鎖を有効化する手順だけを説明します。PDC 認証を使用しない場合のゲートウェイでの認証連鎖については、『Access Manager 管理ガイド』を参照してください。

たとえば、PDC と Radius 認証モジュールを連鎖させると、ユーザーは標準のポータルデスクトップにアクセスするために 3 つのモジュールすべてについて認証が必要になります。

手順については、「既存の PDC インスタンスに認証モジュールを追加する」を参照してください。

注 –

PDC が有効になっていると、PDC が常に最初の認証モジュールとしてユーザーに提示されます。

ワイルドカード証明書の使用

ワイルドカード証明書は、ホストの完全修飾 DNS 名にワイルドカード文字を含む単一の証明書を受け付けます。

この証明書によって、同じドメイン内の複数のホストがセキュリティーで保護されます。たとえば、*.domain.com の証明書は abc.domain.com と abc1.domain.com に使用できます。この証明書は domain.com ドメイン内のすべてのホストに有効です。

ブラウザキャッシングの無効化

ゲートウェイコンポーネントは Web ブラウザのみを使用して任意の場所からバックエンド企業データへのセキュリティー保護されたアクセスを提供するため、クライアントが情報をローカルにキャッシュする必要はありません。

ゲートウェイを通じてリダイレクトされるページのキャッシングを無効にするには、そのゲートウェイの platform.conf ファイルの属性を修正します。

このオプションを無効にすると、ゲートウェイのパフォーマンスに影響する場合があります。標準のポータルデスクトップが再表示されるたびに、ブラウザがすでにキャッシュしているイメージを含めページが参照するすべてのデータをゲートウェイで取り出す必要があるためです。ただし、この機能を有効にしても、リモートアクセスされたセキュリティー保護されたコンテンツの足跡は、クライアントサイトでキャッシュとして残りません。この要因がパフォーマンスへの影響よりも重要な意味を持つのは、企業 IT の管理下にないインターネットカフェやその類のリモートロケーションから企業ネットワークにアクセスしている場合です。

「ブラウザキャッシングを無効にする」を参照してください。

ゲートウェイサービスのユーザーインタフェースのカスタマイズ

ここでは、編集可能な各種のゲートウェイプロパティーファイルについて説明します。

srapGateway.properties ファイルの編集

このファイルは、次の目的のために編集できます。

srapgwadminmsg.properties ファイルの編集

このファイルは、次の目的のために編集できます。

LDAP ディレクトリの共有

Portal Server と Access Manager サーバーの 2 つのインスタンスが同じ LDAP ディレクトリを共有している場合、それ以後のすべての Portal Server インスタンス、Access Manager インスタンス、およびゲートウェイインスタンスで LDAP ディレクトリが共有されます。「LDAP ディレクトリを共有する」を参照してください。

第 3 章 プロキシレットの操作

この章では、Web ページを解析せずにゲートウェイ経由でイントラネット Web ページにアクセスできるようにするプロキシレットについて説明します。

プロキシレットの操作

プロキシレットの概要

プロキシレットとは、それ自体でクライアントマシンのプロキシサーバーを設定する Java アプレットです。プロキシレットは、プロキシ設定がローカルのプロキシサーバー (プロキシレット) をポイントするように、クライアントマシンのプロキシ自動設定 (PAC) ファイルを読み取り、変更します。

プロキシレットはゲートウェイからのトランスポートモードを継承します。ゲートウェイが SSL に基づいて動作するように設定されている場合には、クライアントマシンとゲートウェイまたは宛先サーバーの間でチャネルのセキュリティーが確保されます。暗号化する場合、プロキシレットは、クライアントの JVM が 1.4 以降の場合または必要な jar ファイルがクライアントマシン上にある場合に JSSE API を使用します。それ以外の場合には、KSSL API が使用されます。復号化は、クライアントマシン上で行われます。

ゲートウェイにリダイレクトされる URL のドメインとサブドメインは、ゲートウェイプロファイルに指定されています。ゲートウェイプロファイルに指定されていないドメインが URL に含まれる場合、その要求はインターネットにリダイレクトされます。特定の URL ドメインがゲートウェイプロファイルに指定されている場合、プロキシレットはクライアントのプロキシ設定を、そのゲートウェイをポイントするように再設定します。

ゲートウェイで PDC (Personal Digital Certificate) が有効の場合、プロキシレットはクライアント側の認証をサポートします。PDC が有効化どうかを確認する方法については、「クライアント情報の取得」を参照してください。

プロキシレットは、クライアントの IP アドレスまたはプロキシのホスト名とポートが指定されている Portal Server 管理コンソールから有効にします。プロキシレットが有効になると、クライアントマシンが次の点を満たしているかどうかが確認されます。

これらの要件をすべて満たしている場合は、アプレットがダウンロードされ、クライアントマシン上で起動されます。クライアントに JRE 1.4.2 以降がインストールされていない場合、ユーザーがインターネット接続と管理者権限の両方を持っていれば、プロキシレットによって JRE が自動的にダウンロードされます。

プロキシレットが使用される場合、PAC (Proxy Auto Configuration) ファイルまたはプロキシ設定リストからプロキシ設定が取得されます。

注 –

プロキシレットアプレットを使用する場合は、ブラウザのポップアップブロッカを無効にするようにユーザーに通知してください。

HTTPS のサポート

プロキシレットによる HTTPS のサポートは、次のようになっています。

プロキシレットを使用する利点

リライタと異なり、プロキシレットはインストール後の変更をほとんど、またはまったく必要としません。Microsoft Exchange Server などのサードパーティーソフトウェアとの統合も簡単に行うことができます。プロキシレットは Web コンテンツを扱わないので、ゲートウェイのパフォーマンスも向上します。プロキシレットはコンテンツまたはデータを変更しないので、ユーザーは tar および gzip ファイルなど任意のコンテンツをダウンロードできます。

プロキシレットの設定

プロキシレットの有効化と設定については、第 13 章「プロキシレットの設定」を参照してください。

注 –

プロキシレットを実行する適切な Java 仮想マシン (JVM) がない場合、ブラウザは Sun の Web サイトに接続して Java Runtime Environment (JRE) をダウンロードします。ユーザーのブラウザ設定に正しい値が設定されていない場合、またはユーザーがインターネットにアクセスしないで直接プロキシ設定を使用している場合、プロキシレットはダウンロードできません。

第 4 章 リライタの操作

Secure Remote Access のリライタコンポーネントは、Web ページを解析して、ユーザーがゲートウェイ経由でイントラネット Web ページにアクセスできるようにします。

この章の内容は次のとおりです。

リライタの概要

Secure Remote Access のリライタコンポーネントを使用すると、エンドユーザーは Web ページの URI (Uniform Resource Identifier) 参照をゲートウェイをポイントするように変更することによって、イントラネットをブラウズすることができます。URI は、登録されている名前空間にネームをカプセル化し、それに名前空間のラベルを付ける方法を定義します。もっとも一般的な URI は URL (Uniform Resource Locator) です。リライタは HTTP または HTTPS だけをサポートします。このサポートは、プロトコルでの大文字の使用に影響されません。リライタは、相対 URL の一部として使用される場合にだけバックスラッシュをサポートします。

例 4–1 URL の書き換え

http://abc.sesta.com\\index.html は書き換えられます。

書き換えられない URL は http:\\\\abc.sesta.com、http:/abc.com などです。

文字セットのエンコーディング

HTTP の規格では、HTTP ヘッダーまたは HTML メタタグに Web ページの文字セットを指定する必要があります。ただし、この情報が指定されていないこともあります。文字セットがわからない場合には、データのエンコーディングが設定されず、作成者が意図したようにデータが表示されません。

文字セットを検出するには、Java Enterprise System アクセサリ CD から SUNWjchdt パッケージをインストールします。この製品は、インストールするとリライタによって検出され、必要に応じて使用されます。

注 –

この製品を使用すると、パフォーマンスに影響することがあるため、必要な場合にだけインストールしてください。インストール、設定、および使用法については、jcharset_readme.txt を参照してください。

リライタの使用例

ユーザーがゲートウェイを通じてイントラネット Web ページにアクセスしようとするときに、Web ページはリライタによって使用可能となります。リライタは、URL スクレーパーとゲートウェイによって使用されます。

URL スクレーパー

URL スクレーパープロバイダは、設定されている URI からコンテンツを取得します。それらの URI をブラウザに送信する前に、すべての相対 URI を絶対 URI に展開します。

たとえば、ユーザーが次のサイトにアクセスするとします。

<a href="../mypage.html">

リライタはこれを次のように変換します。

<a href="http://yahoo.com/mypage.html">

http://yahoo.com/test/ はページのベース URL です。

URL スクレーパープロバイダの詳細については、『Sun Java System Portal Server 管理ガイド』を参照してください。

ゲートウェイ

ゲートウェイは、インターネットポータルからコンテンツを取得します。そのコンテンツをブラウザに送信する前に、既存の URI の前にゲートウェイ URI プレフィックスを追加します。これにより、そのブラウザからの以後の URI 要求はゲートウェイに向けられます。

たとえば、インターネット上のマシンにある次の HTML ページにユーザーがアクセスするとします。

<a href="http://mymachine.intranet.com/mypage.html>"

リライタは、次のようにゲートウェイを参照するプレフィックスを URL に追加します。

<a href="https://gateway.company.com/http://mymachine.intranet.com/ mypage.html>"

ユーザーがこのアンカーに関連するリンクをクリックすると、ブラウザはゲートウェイにアクセスします。ゲートウェイは、mymachine.intranet.com から mypage.html のコンテンツを取得します。

ゲートウェイはいくつかのルールを使用して、取得された Web ページの書き換える要素を判断します。

ルールセットの記述

ルールセットの定義の詳細については、『Portal Server 管理ガイド』を参照してください。新しいルールセットを作成したら、必要なルールを定義する必要があります。

この節の内容は、次のとおりです。

パブリックインタフェース (ルールセット DTD)

ルールセット DTD の例を示します。

<?xml version="1.0" encoding="UTF-8"?>
<!--
The following constraints are not represented in DTD, but taken care of programmatically
    1. In a Rule, All Mandatory attributes cannot be "*".
    2. Only one instance of the below elements is allowed, but in any order.
    1)HTMLRules
    2)JSRules
    3)XMLRules
    3. ID should always be in lower case.
-->
<!ENTITY % eURL ’URL’>
<!ENTITY % eEXPRESSION ’EXPRESSION’>
<!ENTITY % eDHTML ’DHTML’>
<!ENTITY % eDJS ’DJS’>
<!ENTITY % eSYSTEM ’SYSTEM’>

<!ENTITY % ruleSetElements ’(HTMLRules | JSRules | XMLRules)?’>
<!ENTITY % htmlElements ’(Form | Applet | Attribute)*’>
<!ENTITY % jsElements ’(Variable | Function)*’>
<!ENTITY % xmlElements ’(Attribute | TagText)*’>

<!ELEMENT RuleSet (%ruleSetElements;,%ruleSetElements;,%ruleSetElements;)>
<!ATTLIST RuleSet
    id ID #REQUIRED
    extends CDATA "none"
>

<!-- Rules for identifying rules in HTML content -->
<!ELEMENT HTMLRules (%htmlElements;)>
<!ELEMENT Form EMPTY>
<!ATTLIST Form
    name CDATA #REQUIRED
    field CDATA #REQUIRED
    valuePatterns CDATA ""
    source CDATA "*"
>

<!ELEMENT Applet EMPTY>
<!ATTLIST Applet
    code CDATA #REQUIRED
    param CDATA "*"
    valuePatterns CDATA ""
    source CDATA "*"
>

<!-- Rules for identifying rules in JS content -->
<!ELEMENT JSRules (%jsElements;)>
<!ELEMENT Variable EMPTY>
<!ATTLIST Variable
    name CDATA #REQUIRED
    type (%eURL; | %eEXPRESSION; | %eDHTML; | %eDJS; | %eSYSTEM;) "EXPRESSION"
    source CDATA "*"
>

<!ELEMENT Function EMPTY>
<!ATTLIST Function
    name CDATA #REQUIRED
    paramPatterns CDATA #REQUIRED
    type (%eURL; | %eEXPRESSION; | %eDHTML; | %eDJS;) "EXPRESSION"
    source CDATA "*"
>

<!-- Rules for identifying rules in XML content -->
<!ELEMENT XMLRules (%xmlElements;)>
<!ELEMENT TagText EMPTY>
<!ATTLIST TagText
    tag CDATA #REQUIRED
    attributePatterns CDATA ""
    source CDATA "*"
>

<!ELEMENT Attribute EMPTY>
<!ATTLIST Attribute
    name CDATA #REQUIRED
    tag CDATA "*"
    valuePatterns CDATA ""
    type (%eURL; | %eDHTML; | %eDJS; ) "URL"
    source CDATA "*"
>
注 –

ルールの値の一部としてアスタリスク (*) を使用できます。ただし、必須属性の値を * だけにすることはできません。このようなルールは無視されますが、メッセージは RuleSetInfo ログファイルに記録されます。このログファイルについては、「デバッグファイル名」を参照してください。

XML DTD の例

ここでは、ルールセットの例を示します。リライタがこれらのルールをどのように解釈するかについては、135 ページの「ケーススタディー」を参照してください。

<?xml version="1.0" encoding="ISO-8859-1"?>
<!--
Rules for integrating a mail client with the gateway.
-->
<!DOCTYPE RuleSet SYSTEM "jar://rewriter.jar/resources/RuleSet.dtd">
<RuleSet type="GROUPED" id="owa">
<HTMLRules>
<Attribute name="action" />
<Attribute name="background" />
<Attribute name="codebase" />
<Attribute name="href" />
<Attribute name="src" />
<Attribute name="lowsrc" />
<Attribute name="imagePath" />
<Attribute name="viewClass" />
<Attribute name="emptyURL" />
<Attribute name="draftsURL" />
<Attribute name="folderURL" />
<Attribute name="prevMonthImage" />
<Attribute name="nextMonthImage" />
<Attribute name="style" />
<Attribute name="content" tag="meta" />
</HTMLRules>
<JSRules>
<!-- Rules for Rewriting JavaScript variables in URLs -->
<Variable name="URL"> _fr.location </Variable>
<Variable name="URL"> g_szUserBase </Variable>
<Variable name="URL"> g_szPublicFolderUrl </Variable>
<Variable name="URL"> g_szExWebDir </Variable>
<Variable name="URL"> g_szViewClassURL </Variable>
<Variable name="URL"> g_szVirtualRoot </Variable>
<Variable name="URL"> g_szBaseURL </Variable>
<Variable name="URL"> g_szURL </Variable>
<Function name="EXPRESSION" name="NavigateTo" paramPatterns="y"/>
</JSRules>
<XMLRules>
<Attribute name="xmlns"/>
<Attribute name="href" tag="a"/>
<TagText tag="baseroot" />
<TagText tag="prop2" />
<TagText tag="prop1" />
<TagText tag="img" />
<TagText tag="xsl:attribute"
attributePatterns="name=src" />
</XMLRules>
</RuleSet>

ルールの記述手順

次に、ルールを記述するための一般的な手順を示します。

ルールセットのガイドライン

ルールセットを作成する場合は、次の点に注意してください。

ルールセットのルート要素の定義

ルールセットのルート要素には、次の 2 つの属性があります。

再帰機能の使用

リライタは、再帰機能を使用して、一致する文字列パターンの最後まで同じパターンを検索します。

たとえば、リライタが次の文字列を解析する場合を考えます。

<a href="src=abc.jpg,src=bcd.jpg,src=xyz.jpg>

次のルールがあるとします。

<Attribute name="href" valuePatterns="*src=**"/>

このルールは、最初に見つかったパターンだけを次のように書き換えます。

<a href="src=http://jane.sun.com/abc.jpg>

次のように再帰オプションを使用した場合を考えます。

<Attribute name="href" valuePatterns="REC:*src=**"/>;

リライタは再帰機能を使用して、一致する文字列パターンの最後まで同じパターンを検索します。この出力は次のようになります。

<a href="src=http://jane.sun.com/abc.jpg,src=http://jane.sun.com/bcd.jpg,src=http://jane.sun.com/xyz.jpg>

言語ベースのルールの定義

ルールは、次の言語に基づきます。

HTML コンテンツのルール

Web ページの HTML コンテンツは、さらに属性、フォーム、およびアプレットに分類されます。これに従って、HTML コンテンツのルールは次のように分類されます。

HTML コンテンツの属性ルール

このルールは値を書き換える必要のあるタグの属性を特定します。属性値には、簡易 URL、JavaScript、DHTML コンテンツがあります。次に例を示します。

この節では、次の項目について説明します。

属性ルールの構文

<Attribute name="attributeName" [tag="*" valuePatterns="" source="*" type="URL|DHTML|DJS"]/>

各表記の意味は次のとおりです。

attributeName は属性名です (必須)。

tag は、この属性が属するタグです (省略可能、デフォルト * は任意のタグを意味する)。

valuePatterns については、「ルールでのパターンマッチングの使用」を参照してください。

source は、この属性が定義されているページの URI を指定します (省略可能、デフォルト * は任意のページを意味する)。

type は関数のタイプを指定します (省略可能)。これには次の値があります。

URL : 簡易 URL (デフォルト値)

DHMTL : DHTML コンテンツ。この種類のコンテンツは、標準の HTML コンテンツに見られ、Microsoft の HTC 形式のファイルで使用されます。

DJS : JavaScript コンテンツ。onClick や onMouseover など、すべての HTML イベントハンドラには、HTML 属性に JavaScript が組み込まれています。

属性ルールの例

ページのベース URL が次の URL であると仮定します。

http://mymachine.intranet.com/mypage.html

ページコンテンツ:

<a href="http://mymachine.intranet.com/mypage.html">

ルール

<Attribute name="href"/>
または
<Attribute name="href" tag="a"/>

出力

<a href=gateway-URL/http://mymachine.intranet.com/myhome.html>

説明

書き換えられる URL はすでに絶対 URL であるため、ゲートウェイ URL だけがこの URL にプレフィックスとして追加されます。

DJS 属性の例

ページのベース URL が次の URL であると仮定します。

http://abc.sesta.com/focus.html

ページコンテンツ:

<Form>

<input TYPE=TEXT SIZE=20 value=focus onClick="Check(\q/focus.html\q,\qfocus\q);return;">

</Form>

ルール

<Attribute name="onClick" type="DJS"/>
<Function type="URL" name="Check" paramPatterns="y,"/>

出力

<Form> 

<INPUT TYPE=TEXT SIZE=20 value=focus onClick="Check(\q
gateway-URL
/http://abc.sesta.com/focus.html\q,\qfocus\q);return;">

</Form>

説明

指定されたページコンテンツを書き換えるには、2 つのルールが必要です。最初のルールは onClick JavaScript トークンを特定します。2 番目のルールは、書き換えが必要な check 関数のパラメータを特定します。この場合、paramPatterns に値 y が指定されているため、最初のパラメータだけが書き換えられます。

ゲートウェイ URL と JavaScript トークンが表示されるベース URL が、必要なパラメータの前に指定されます。

HTML コンテンツのフォームルール

ユーザーが参照する HTML ページにはフォームが含まれていることがあります。一部のフォーム要素は、値として URL をとることがあります。

この節は、次の項目から構成されています。

フォームルールの構文

<Form name="form1" field="visit" [valuePatterns="" source="*"]/>

各表記の意味は次のとおりです。

name はフォーム名です (必須)。

field は値を書き換える必要があるフォームのフィールドです (必須)。

valuePatterns については、「ルールでのパターンマッチングの使用」を参照してください。

source は、このフォーム定義が存在するページの URL です (省略可能、デフォルト * は任意のページを意味する)。

フォームルールの例

ページのベース URL が次の URL であると仮定します。

http://test.siroe.com/testcases/html/form.html

ページコンテンツ

ページ URI が form.html で、サーバーの root ディレクトリに格納されていると仮定します。

<form name=form1  method=POST action=
"http://test.siroe.com/testcases/html/form.html">
<input type=hidden name=abc1 value="0|1234|/test.html">
</form>

form1 の一部である abc1 という隠しフィールドの値に含まれる /text.html を書き換えるとします。この場合、次のルールが必要です。

ルール

<Form source="*/form.html" name="form1" 
field="abc1" valuePatterns="0|1234|"/>
<Attribute name="action"/>

出力

<FORM name="form1" 
method="POST" action="gateway-URL/
http://test.siroe.com/testcases/html/form.html">
<input type=hidden name=abc1 
value="0|1234|gateway-URL/
http://test.siroe.com/test.html">
</FORM>

説明

action タグは定義済みのいくつかの HTML 属性ルールを使用して書き換えられます。

入力タグ属性値の value は、出力に示されるように書き換えられます。指定された valuePatterns が検索され、一致した valuePatterns に続くすべてのコンテンツは、先頭にゲートウェイ URL とページのベース URL を追加する方法で書き換えられます。「ルールでのパターンマッチングの使用」を参照してください。

HTML コンテンツのアプレットルール

単一の Web ページに複数のアプレットが含まれていたり、各アプレットに多くのパラメータが指定されていることがあります。リライタは、ルールに指定されている値とアプレットの HTML 定義を一致させ、アプレットのパラメータ定義の一部として含まれる URL の値を変更します。この置換はサーバーで実行され、ユーザーが特定の Web ページを参照しているときには行われません。このルールは、HTML コンテンツのアプレットタグとオブジェクトタグの両方のパラメータを識別し、それを書き換えます。

この節は、次の項目から構成されています。

アプレットルールの構文

<Applet code="ApplicationClassName/ObjectID
" param="parametername" [valuePatterns="" source="*"] />

各表記の意味は次のとおりです。

code はアプレットクラスまたはオブジェクトクラスの名前です (必須)。

param は値を書き換える必要のあるパラメータの名前です (必須)。

valuePatterns については、「ルールでのパターンマッチングの使用」を参照してください。

source は、アプレット定義が存在するページの URL です (省略可能、デフォルト * は任意のページを意味する)。

アプレットルールの例

ページのベース URL が次の URL であると仮定します。

http://abc.siroe.com/casestudy/test/HTML/applet/rule1.html

ページコンテンツ:

<applet codebase="appletcode" code="
RewriteURLinApplet.class" archive="/test.jar">
<param name=Test1 value="/index.html">
</applet>

ルール

<Applet source="*/rule1.html" code=
"RewriteURLin*.class" param="Test*"/>

出力

<APPLET codebase="gateway-URL
/http://abc.siroe.com/casestudy/test/HTML/
applet/appletcode" code="RewriteURLinApplet.class"
 archive="/test.jar"><param name="Test1" value="
gateway-URL/http:
//abc.siroe.com/index.html">
</APPLET>

説明

default_gateway_ruleset に <Attribute name="codebase"/> が定義されているため、codebase attribute は書き換えられます。

名前が Test で始まるすべてのパラメータが書き換えられます。アプレットコードが表示されるページのベース URL、およびゲートウェイ URL が、param タグの value 属性の値の前に追加されます。

ルールでのパターンマッチングの使用

valuePatterns フィールドを使用してパターンマッチングを実行し、書き換えが必要な文の特定部分を識別することができます。

ルールの一部として valuePatterns を指定すると、一致したパターンに続くすべてのコンテンツが書き換えられます。

次のフォーム例のルールを考えます。

<Form source="*/source.html
" name="form1" field="visit
" [valuePatterns="0|1234|"]/>

各表記の意味は次のとおりです。

source は、フォームが表示される HTML ページの URL です。

name はフォーム名です。

field は値を書き換える必要があるフォームのフィールドです。

valuePatterns は、書き換えが必要な部分文字列を示します。valuePatterns のあとに表示されるすべてのコンテンツは書き換えられます (省略可能、デフォルト "" は値全体の書き換えが必要であることを示す)。

valuePatterns への特殊文字の指定

\ (円記号) でエスケープすることにより、特殊文字を指定できます。次に例を示します。

<Form source="*/source.html " name="form1" field=" visit" [valuePatterns="0|1234| \\;original text|changed text"]/>

valuePatterns でのワイルドカードの使用

ワイルドカードのアスタリスク (*) を使用して、書き換えのパターンマッチングを実行できます。

valuePatterns フィールドに * だけを指定することはできません。* はすべてのテキストとの一致を示すため、valuePattern に続くテキストがなくなります。したがって、リライタが書き換えるテキストもなくなります。* は *abc のように、ほかの文字列と組み合わせて使用する必要があります。この場合、*abc に続くすべてのコンテンツが書き換えられます。

注 –

アスタリスク (*) はルールのどのフィールドでも、ワイルドカードとして使用できます。ただし、ルールのすべてのフィールドに * を使用することはできません。すべてのフィールドに * が含まれている場合、ルールは無視されます。エラーメッセージは表示されません。

* や ** は、セミコロンやコンマなどの区切り文字と一緒に使用できます。区切り文字は、元の文に含まれる複数のフィールドを区切ります。1 個のアスタリスク (*) は書き換えられないフィールドと一致し、2 個のアスタリスク (**) は書き換えが必要なフィールドと一致します。

「valuePatterns でのワイルドカードの使用」は、* ワイルドカードの使用例を示しています。

表 4–1 * ワイルドカードの使用例

URL 

valuePatterns 

説明 

url1, url2, url3, url4

valuePatterns = "**, *, **, *"

** が書き換えられる部分を表すため、url1 と url3 が書き換えられます。

XYZABChttp://host1.sesta.com/dir1.html

valuePatterns = "*ABC"

http://host1.sesta.com/dir1.html の部分だけが書き換えられます。*ABC のあとのすべてを書き換える必要があります。

"0|dir1|dir2|dir3|dir4|test|url1

valuePatterns = "*|*|**|*|**|*|"

dir2、dir4、および url1 が書き換えられます。書き換えが必要な最後のフィールドは、** を使用して指定する必要はありません。

JavaScript コンテンツのルール

JavaScript はさまざまな場所に URL を含んでいます。リライタは JavaScript を直接解析できないため、URL 部分を特定できません。JavaScript プロセッサで URL を識別、解釈できるようにするために、特別なルールセットを記述する必要があります。

URL を含む JavaScript 要素は次のように分類されます。

変数

変数の汎用構文は次のとおりです。

<Variable name="variableName" [type="URL|EXPRESSION|DHTML|DJS|SYSTEM" source="*"]>

JavaScript の変数は、その値の種類に応じてさらに次の 5 つのカテゴリに分類されます。

URL 変数

この変数の値は、URL として扱うことができる単純文字列です。

この節は、次の項目から構成されています。

URL 変数の構文

<Variable name="variableName" type="URL" [source="*"]>

各表記の意味は次のとおりです。

variableName は変数名です。variableName の値が書き換えられます (必須)。

type は URL 変数です (必須、値は URL でなければならない)。

source は、この JavaScript 変数が含まれるページの URI です (省略可能、デフォルト * は任意のページを意味する)。

URL 変数の例

ベース URL が次の URL であると仮定します。

http://abc.siroe.com/tmp/page.html

ページコンテンツ

<script LANGUAGE="Javascript">
<!--
//URL Variables
var imgsrc1="/tmp/tmp.jpg";
var imgsrc2="http://srap.sesta.com/tmp/tmp.jpg";
var imgsrc3=imgsrc2;
//-->
</SCRIPT>

ルール

<Variable name="imgsrc*" type="URL"/>

出力

<script LANGUAGE="Javascript">
<!--
//URL Variables
var imgsrc="gateway-URL/http://abc.siroe.com/tmp/tmp.jpg";
var imgsrc="gateway-URL/http://srap.sesta.com/tmp/tmp.jpg";
var imgsrc3=imgsrc2;
//-->
</SCRIPT>

説明

タイプが URL で、名前が imgsrc から始まるすべての変数が書き換えられます。出力の最初の行では、ゲートウェイ URL と変数が表示されるページのベース URL が先頭に指定されます。2 行目にはすでに絶対パスが指定されているため、ゲートウェイ URL のみがプレフィックスとして追加されます。3 番目の変数 imagsrc2 は、値が文字列ではなく別の JavaScript 値であるため書き換えられません。

EXPRESSION 変数

EXPRESSION 変数の右側には式が指定されます。この式の結果は URL です。リライタは、このような式をサーバーで評価できないため、HTML ページに JavaScript 関数 (psSRAPRewriter_convert_expression) を追加します。この関数はパラメータとして式をとり、クライアントブラウザで要求される URL に対して式を評価します。

文に含まれる URL が単一の URL であるか EXPRESSION URL であるかが明らかでないときは、どちらの場合にも適用できる EXPRESSION ルールを使用してください。

この節は、次の項目から構成されています。

EXPRESSION 変数の構文

<Variable name="variableName" [type="EXPRESSION" source="*"]/>

各表記の意味は次のとおりです。

variableName は、値として式を持つ JavaScript 変数の名前です (必須)。

type は JavaScript 変数のタイプです (省略可能、デフォルト値は EXPRESSION)。

source はページの URI です (省略可能、デフォルト * は任意のソースを意味する)。

EXPRESSION 変数の例

ページのベース URL が次の URL であると仮定します。

http://abc.siroe.com/dir1/dir2/page.html

ページコンテンツ

<script LANGUAGE="Javascript">
<!--
//Expression variables
var expvar= getURIPreFix() + "../../images/graphics"+".gif";
document.write("<A HREF="+expvar+">Link to XYZ content</A><P>")
var expvar="../../images/graphics"+".gif";
//-->
</SCRIPT>

ルール

<Variable name="expvar" type="EXPRESSION"/>
または
<Variable name="expvar"/>

出力

var expvar=psSRAPRewriter_convert_expression(getURIPreFix()
 + "../../images/graphics"+".gif");document.write("<a href="+expvar+">>
Link to XYZ content</A><P>")var expvar="gateway-URL/http://abc.siroe.com/images/graphics"+".gif";

説明

関数 psSRAPRewriter_convert_expression が、式変数 expvar の最初の行の右側の部分に先行して指定されます。この関数は、実行時に式を処理し、コンテンツを書き換えます。3 行目では、値が簡易 URL に書き換えられます。

DHTML (ダイナミック HTML) 変数

これは HTML コンテンツを含む JavaScript 変数です。

この節は、次の項目から構成されています。

DHTML 変数の構文

<Variable name="variableName" type="DHTML" [source="*"]/>

各表記の意味は次のとおりです。

variableName は DHTML コンテンツを持つ JavaScript 変数の名前です (必須)。

type は変数のタイプです (必須、値は DHTML である必要がある)。

source はページの URL です (省略可能、デフォルト * は任意のページを意味する)。

DHTML 変数の例

ページのベース URL が次の URL であると仮定します。

http://abc.sesta.com/graphics/set1/
graphics/jsscript/JSVAR/page.html

ページコンテンツ

<script LANGUAGE="Javascript">
<!--
//DHTML Var
var dhtmlVar="<a href=../../images/test.html>"
var dhtmlVar="<a href=/images/test.html>"
var dhtmlVar="<a href=images/test.html>"
//-->
</SCRIPT>

ルール

<Variable name="dhtmlVar" type="DHTML"/>
<Attribute name="href"/>
または
<Attribute name="href" tag="a"/>

出力

<script LANGUAGE="Javascript">
<!--
//DHTML Var
var dhtmlVar="<a href=gateway-URL
/http://abc.sesta.com/graphics/
set1/graphics/images/test.html>"
var dhtmlVar="<a href=gateway-URL/
http
://abc.sesta.com/images/test.html>"
var dhtmlVar="<a href=gateway-URL/
http://abc.sesta.com/graphics/set1/
graphics/jscript/JSVAR/images/test.html>"
//--></SCRIPT>

説明

JavaScript パーサーは dhtmlVar の値を HTML コンテンツとして読み取り、HTML パーサー経由でそのコンテンツを送信します。HTML パーサーは HTML ルールを適用するため、href 属性ルールとの一致によって URL が書き換えられます。

DJS (ダイナミック JavaScript) 変数

これは JavaScript コンテンツを含む JavaScript 変数です。

この節は、次の項目から構成されています。

DJS 変数の構文

<Variable name="variableName" type="DJS" [source="*"]/>

各表記の意味は次のとおりです。

variable は JavaScript を値として持つ JavaScript 変数の名前です。

DJS 変数の例

ページのベース URL が次の URL であると仮定します。

http://abc.sesta.com/dir1/dir2/dir3/jscript/dir4/page.html

ページコンテンツ

//DJS Var
var dJSVar="var dJSimgsrc=\q/tmp/tmp.jpg\q;"
var dJSVar="var dJSimgsrc=\q../tmp/tmp.jpg\q;"
var dJSVar="var dJSimgsrc=
\qhttp://abc.sesta.com/tmp/tmp.jpg\q;"

ルール

<Variable name="DJS">dJSVar/>
<Variable name="URL">dJSimgsrc/>

出力

//DJS Var - need 2 rules
var dJSVar="var dJSimgsrc=\qgateway-URL
/http://abc.sesta.com/tmp/tmp.jpg\q;"var dJSVar="var dJSimgsrc=\q
gateway-URL/http
://abc.sesta.com/dir1/dir2/dir3/jscript/tmp/tmp.jpg\q;"
var dJSVar="var dJSimgsrc=\qgateway-URL/
http://abc.sesta.com/tmp/tmp.jpg\q;"

説明

ここでは、2 つのルールが必要です。最初のルールはダイナミック JavaScript 変数 dJSVar を検索します。この変数の値は、同じくタイプが URL の JavaScript になります。次に 2 番目のルールが適用され、この JavaScript 変数の値が書き換えられます。

SYSTEM 変数

これらは、使用によって宣言されない変数であり、サポートは限定されます。これらの変数は JavaScript 標準の一部として利用可能です。たとえば、window.location.pathname などがあります。

この節は、次の項目から構成されています。

SYSTEM 変数の構文

<Variable name="variableName" type="SYSTEM" [source="*"]/>

各表記の意味は次のとおりです。

variableName は、JavaScript のシステム変数です (必須)。値は document.URL、document.domain、location、doument.location、location.pathname、location.href、location.protocol、location.hostname、location.host、および location.port のいずれかのパターンと一致する必要があります。これは、すべて generic_ruleset に含まれます。これらのシステム var ルールを変更しないでください。

type には、システムタイプの値を指定します (必須、値は DJS)。

source はそのページの URL です (省略可能、デフォルト * は任意のページを意味する)。

SYSTEM 変数の例

ページのベース URL が次の URL であると仮定します。

http://abc.siroe.com/dir1/page.html

ページコンテンツ

<script LANGUAGE="Javascript">
<!--
//SYSTEM Var
alert(window.location.pathname);
//-->
</SCRIPT>

ルール

<Variable name="window.location.pathname" type="SYSTEM"/>

出力

</SCRIPT>
<SCRIPT LANGUAGE="Javascript">
<!--
//SYSTEM Var
alert(psSRAPRewriter_convert_pathname(window.location.pathname));
//-->
</SCRIPT>

説明

リライタは、ルールと一致するシステム変数を検索し、プレフィックスとして psSRAPRewriter_convert_system 関数を追加します。この関数は、実行時にシステム変数を処理し、処理後の URL を書き換えます。

関数の引数

値の書き換えが必要な関数パラメータは、次の 4 つのカテゴリに分類されます。

汎用構文

<Function name="functionName " paramPatterns="y,y," [type="URL|EXPRESSION|DHTML|DJS" source="*"]/>

各表記の意味は次のとおりです。

name は JavaScript 関数の名前です (必須)。

paramPatterns は、書き換えが必要なパラメータを指定します (必須)。

y によって指定される位置は、書き換えが必要なパラメータを示します。たとえば、構文の最初のパラメータは書き換えるが、2 番目のパラメータは書き換えない、という指定が可能です。

type はこのパラメータが必要とする値の種類を指定します (省略可能、デフォルトは EXPRESSION タイプ)。

source はページのソース URI です (省略可能、デフォルト * は任意のページを意味する)。

URL パラメータ

関数は、このパラメータを文字列としてとり、この文字列は URL として扱うことができます。

この節は、次の項目から構成されています。

URL パラメータの構文

<Function name="functionName" paramPatterns="y,," type="URL" [source="*"]/>

各表記の意味は次のとおりです。

name は、パラメータのタイプが URL である関数の名前です (必須)。

paramPatterns は、書き換えが必要なパラメータを指定します (必須)。

y によって指定される位置は、書き換えが必要なパラメータを示します。たとえば、構文の最初のパラメータは書き換えるが、2 番目のパラメータは書き換えない、という指定が可能です。

type は関数のタイプです (必須、値は URL である必要がある)。

source は、この関数の呼び出しが含まれるページの URL です (省略可能、デフォルト * は任意の URL を意味する)。

URL パラメータの例

ページのベース URL が次の URL であると仮定します。

http://abc.sesta.com/test/rewriter/test1/jscript/test2/page.html

ページコンテンツ

<script language="JavaScript">
<!--
function test(one,two,three){
alert(one + "##" + two + "##" +three);
}
test("/test.html","../test.html","123");
window.open("/index.html","gen",width=500,height=500);
//-->
</SCRIPT>

ルール

<Function name="URL" name="test" paramPatterns="y,y,"/>
<Function name="URL" name="window.open" paramPatterns="y,,,"/>

出力

<SCRIPT language="JavaScript">
<!--
function test(one,two,three) {
alert(one + "##" + two + "##" +three);
}
test("gateway-URL/http://abc.sesta.com/test.html","
gateway-URL/http://abc.sesta.com/test/rewriter/
test1/jscript/test.html","123");window.open("gateway-URL/
http://abc.sesta.com/index.html","gen",width=500,height=500);
//-->
</SCRIPT>

説明

最初のルールは、関数 test の最初の 2 つのパラメータを書き換える必要があることを示します。したがって、test 関数の最初の 2 つのパラメータが書き換えられます。2 番目のルールは、window.open 関数の最初のパラメータを書き換える必要があることを示します。window.open 関数内の URL の先頭に、ゲートウェイ URL と、関数パラメータが含まれるページのベース URL が追加されます。

EXPRESSION パラメータ

このパラメータは、値として式をとり、この式の評価結果が URL となります。

この節は、次の項目から構成されています。

EXPRESSION パラメータの構文

<Function name="functionName" paramPatterns="y" [type="EXPRESSION" source="*"]/>

各表記の意味は次のとおりです。

name は関数名です (必須)。

paramPatterns は、書き換えが必要なパラメータを指定します (必須)。

y によって指定される位置は、書き換えが必要な関数パラメータを示します。上の構文では、最初のパラメータだけが書き換えられます。

type は、式の値のタイプを指定します (省略可能)。

source は、この関数を呼び出すページの URI です。

EXPRESSION パラメータの例

ページのベース URL が次の URL であると仮定します。

http://abc.sesta.com/dir1/dir2/page.html

ページコンテンツ

<script language="JavaScript">
<!--
function jstest2(){
return ".html";
}
function jstest1(one){
return one;
}
var dir="/images/test"
var test1=jstest1(dir+"/test"+jstest2());
document.write("<a HREF="+test1+">TEST</a>");
alert(test1);
//-->
</SCRIPT>

ルール

<Function type="EXPRESSION" name="jstest1" paramPatterns="y"/>
または
<Function name="jstest1" paramPatterns="y"/>

出力

<script language="JavaScript">
<!--
function jstest2(){
return ".html";
}
function jstest1(one){
return one;
}
var dir="/images/test"
var test1=jstest1(psSRAPRewriter_convert_expression(dir+"/test"+jstest2()));
document.write("<a HREF="+test1+">TEST</a>");
alert(test1);
//-->
</SCRIPT>

説明

このルールは、これが EXPRESSION 関数のパラメータであると見なすことによって、jstest1 関数の最初のパラメータを書き換える必要があることを示します。ページコンテンツの例では、最初のパラメータは実行時にだけ評価される式です。リライタはこの式の先頭に psSRAPRewriter_convert_expression 関数を追加します。式が評価され、psSRAPRewriter_convert_expression 関数は実行時に出力を書き換えます。

注 –

上の例では、JavaScript 変数ルールの一部として、変数 test1 は必要ありません。書き換えは、jstest1 の関数ルールによって行われます。

DHTML パラメータ

これは、値が HTML の関数パラメータです。

HTML ページをダイナミックに生成する document.write() などのネイティブ JavaScript メソッドは、このカテゴリに分類されます。

この節は、次の項目から構成されています。

DHTML パラメータの構文

<Function name="functionName" paramPatterns="y" type="DHTML" [source="*"]/>

各表記の意味は次のとおりです。

name は関数名です。

paramPatterns は、書き換えが必要なパラメータを指定します (必須)。

y によって指定される位置は、書き換えが必要な関数パラメータを示します。上の構文では、最初のパラメータだけが書き換えられます。

DHTML パラメータの例

ページのベース URL が次の URL であると仮定します。

http://xyz.siroe.com/test/rewriter/test1/jscript/JSFUNC/page.html

ページコンテンツ

<script>
<!--
document.write(\q<a href="/index.html">write</a><BR>\q)
document.writeln(\q<a href="index.html">writeln</a><BR>\q)
document.write("http://abc.sesta.com/index.html<BR>")
document.writeln("http://abc.sesta.com/index.html<BR>")
//-->
</SCRIPT>

ルール

<Function name="DHTML" name="document.write" paramPatterns="y"/>
<Function name="DHTML" name="document.writeln" paramPatterns="y"/>
<Attribute name="href"/>

出力

<SCRIPT>
<!--
document.write(\q<a href="gateway-URL/
http://xyz.siroe.com/index.html">write</a><BR>\q)
document.writeln(\q<a href="gateway-URL/
http://xyz.siroe.com/test/rewriter/test1/
jscript/JSFUNC/index.html">writeln</a><BR>\q)
document.write("http://abc.sesta.com/index.html<BR>")
document.writeln("http://abc.sesta.com/index.html<BR>")
//-->
</SCRIPT>

説明

最初のルールは、関数 document.write の最初のパラメータを書き換える必要があることを示します。2 番目のルールは、関数 document.writeln の最初のパラメータを書き換える必要があることを指定します。3 番目のルールは、名前に href を含むすべての属性を書き換える必要があることを指定する簡単な HTML ルールです。この例では、DHTML パラメータルールは関数内の書き換えの必要があるパラメータを特定します。この場合、HTML 属性ルールが適用され、特定されたパラメータが実際に書き換えられます。

DJS パラメータ

これは、値が JavaScript の関数パラメータです。

この節は、次の項目から構成されています。

DJS パラメータの構文

<Function name="functionName" paramPatterns="y" type="DJS" [source="*"]/>

各表記の意味は次のとおりです。

name は、1 つのパラメータが DJS である関数の名前です (必須)。

paramPatterns は、上の関数のどのパラメータが DJS であるかを指定します (必須)。

y によって指定される位置は、書き換えが必要な関数パラメータを示します。上の構文では、最初のパラメータだけが書き換えられます。

type は DJS です (必須)。

source はページの URI です (省略可能、デフォルト * は任意の URI を意味する)。

DJS パラメータの例

ページのベース URL が次の URL であると仮定します。

http://abc.sesta.com/page.html

ページコンテンツ

<script>
menu.addItem(new NavBarMenuItem("All Available Information","JavaScript:top.location=\qhttp://abc.sesta.co
m\q"));
</script>

ルール

<Function name="DJS" name="NavBarMenuItem" paramPatterns=",y"/>
<Variable name="URL">top.location</Variable>

出力

<script>
menu.addItem(new NavBarMenuItem("All Available Information",
"JavaScript:top.location=\qgateway-URL/
http://abc.sesta.com\q"));
</script>

説明

最初のルールは、JavaScript を含む関数 NavBarMenuItem の 2 番目のパラメータを書き換える必要があることを指定します。JavaScript 内で、変数 top.location も書き換える必要があります。この変数は 2 番目のルールを使用して書き換えられます。

XML コンテンツのルール

Web ページには、URL を含む XML コンテンツが含まれていることがあります。書き換えが必要な XML コンテンツは、2 つのカテゴリに分類されます。

タグテキスト

このルールは、タグ要素の PCDATA または CDATA を書き換えるためのものです。

この節は、次の項目から構成されています。

タグテキストの構文

<TagText tag="tagName" 
[attributePatterns="attribute_patterns_for_ this_tag" source="*"]/>

各表記の意味は次のとおりです。

tag はタグ名です。

attributePatterns はこのタグの属性と属性値パターンです (省略可能、省略した場合はこのタグは属性を一切持たない)。

source はこの XML ファイルの URI です (省略可能、デフォルト * は任意の XML ページを意味する)。

タグテキストの例

ページのベース URL が次の URL であると仮定します。

http://abc.sesta.com/test/rewriter/test1/xml/page.html

ページコンテンツ

<xml>
<Attribute name="src">test.html</attribute>
<attribute>abc.html</attribute>
</xml>

ルール

<TagText tag="attribute" attributePatterns="name=src"/>

出力

<xml>
<Attribute name="src">gateway-URL/
http://abc.sesta.com/test/rewriter/test1/
xml/test.html</attribute><attribute>abc.html</attribute>
</xml>

説明

ページコンテンツの最初の行には 「属性の例」が含まれます。ページコンテンツの 2 行目には、名前が name で値が src の属性が含まれず、書き換えは行われません。これを書き換えるには、<TagText tag="attribute"/> も必要です。

属性

XML 属性のルールは、HTML の属性ルールに似ています。違いは、XML の属性ルールでは大文字と小文字が区別され、HTML の属性ルールでは区別されないことです。これは、XML では大文字と小文字が区別され、HTML では区別されないためです。

リライタは、属性名に基づいて属性値を変換します。

この節は、次の項目から構成されています。

属性の構文

<Attribute name="attributeName " [tag="*" type="URL" valuePatterns="*" source="*"]/>

各表記の意味は次のとおりです。

attributeName は属性名です (必須)。

tag は、この属性が含まれるタグの名前です (省略可能、デフォルト * は任意のタグを意味する)。

valuePatterns については、「ルールでのパターンマッチングの使用」を参照してください。

source は XML ページの URI です (省略可能、デフォルト * は任意の XML ページを意味する)。

属性の例

ページのベース URL が次の URL であると仮定します。

http://abc.sesta.com/test/rewriter/test1/xml/page.html

ページコンテンツ

<xml>
<baseroot href="/root.html"/>
<img href="image.html"/>
<string href="1234|substring.html"/>
<check href="1234|string.html"/>
</xml>

ルール

<Attribute name="href"tag="check" valuePatterns="1234|"/>

出力

<xml>
<baseroot href="/root.html"/><img href="image.html"/>
<string href="1234|substring.html"/><check href="1234|
gateway-URL
/http://abc.sesta.com/test/rewriter/test1/xml/string.html"/></xml>

説明

前述した例では、4 行目だけがルールに指定されたすべての条件と一致するため、書き換えられます。「ルールでのパターンマッチングの使用」を参照してください。

カスケードスタイルシートのルール

HTML ページのカスケードスタイルシート (CSS2 も含まれる) も変換されます。この変換のために定義されるルールはありません。これは、URL が CSS の url() 関数とインポート構文にだけ表示されるためです。

WML のルール

WML は HTML に似ているため、WML コンテンツには HTML ルールが適用されま す。WML コンテンツの汎用ルールセットを使用してください。「HTML コンテンツのルール」を参照してください。

再帰機能の使用

リライタは、再帰機能を使用して、一致する文字列パターンの最後まで同じパターンを検索します。

たとえば、リライタが次の文字列を解析する場合を考えます。

<a href="src=abc.jpg,src=bcd.jpg,src=xyz.jpg>

次のルールがあるとします。

<Attribute name="href" valuePatterns="*src=**"/>

このルールは、最初に見つかったパターンだけを次のように書き換えます。

<a href="src=http://jane.sun.com/abc.jpg>

一方、次のように再帰オプションを使用した場合を考えます。

<Attribute name="href" valuePatterns="REC:*src=**"/>;

リライタは再帰機能を使用して、一致する文字列パターンの最後まで同じパターンを検索します。この出力は次のようになります。

<a href="src=http://jane.sun.com/abc.jpg,src= http://jane.sun.com/bcd.jpg,src=http://jane.sun.com/xyz.jpg>

デバッグログを使用したトラブルシューティング

リライタに関する問題の原因を特定するには、デバッグログを有効にする必要があります。

デバッグメッセージは、次のように分類されます。

リライタのデバッグレベルの設定

Procedureリライタのデバッグレベルを設定する

  1. ゲートウェイマシンに root としてログインし、次のファイルを編集します。


    gateway-install-root/SUNWam/config/AMConfig-instance-name.properties

  2. デバッグレベルを設定します。


    com.iplanet.services.debug.level=

    次のデバッグレベルがあります。

    error : 重要なエラーだけがログとしてデバッグファイルに記録されます。このようなエラーが発生すると、通常、リライタは機能を停止します。

    warning : 警告メッセージがログに記録されます。

    message : すべてのデバッグメッセージがログに記録されます。

    off : デバッグメッセージはログに記録されません。

  3. AMConfig-instance-name.properties ファイルの次のプロパティーに、デバッグファイルのディレクトリを指定します。


    com.iplanet.services.debug.directory=/var/opt/SUNWam/debug

    この /var/opt/SUNWam/debug は、デフォルトのデバッグディレクトリです。

  4. 端末ウィンドウからゲートウェイを再起動します。


    ./psadmin start-sra-instance –u amadmin – f  <password file> –N <profile name>– t  <gateway>

デバッグファイル名

デバッグレベルを「message」に設定すると、複数のファイルが生成されます。「デバッグファイル名」はリライタのデバッグファイルとその内容を示しています。

表 4–2 リライタのデバッグファイル

ファイル名 

説明 

RuleSetInfo 

書き換えに使用されたすべてのルールは、このファイルに記録されます。 

Original Pages 

ページの URI、解決された URI (ページ URI と異なる場合)、コンテンツの MIME、ページに適用されたルールセット、パーサー MIME、および元のコンテンツが記録されます。 

このファイルには、解析に関連する具体的な error/warning/message も記録されます。 

message モードでは、すべてのコンテンツが記録されます。warning モードと error モードでは、書き換え時に発生した例外だけが記録されます。 

Rewritten Pages 

ページの URI、解決された URI (ページ URI と異なる場合)、コンテンツの MIME、ページに適用されたルールセット、パーサー MIME、および書き換えられたコンテンツが記録されます。 

この情報は、デバッグモードを message に設定した場合にだけ記録されます。 

Unaffected Pages 

このファイルには、変更されなかったページのリストが含まれます。 

URIInfo Pages 

検出され、変換された URL が記録されます。コンテンツが元のデータと同じ状態で残された、すべてのページの詳細が記録されます。 

記録される詳細情報はページの URI、MIME、符号化データ、書き換え時に適用されたルールセットの ID、およびパーサー MIME です。 

これらのファイルのほかに、リライタはこれらのファイルに記録されないデバッグメッセージを記録するファイルを生成します。このファイルの名前は 2 つの部分から構成されます。最初の部分は pwRewriter または psSRARewriter で、2 番目の部分は portal または gateway-profile-name を使用した拡張子です。

デバッグファイルは、ポータルまたはゲートウェイに表示されます。これらのファイルは、AMConfig-instance-name.properties ファイルに指定されているディレクトリに格納されます。

リライタコンポーネントは、デバッグ用に次のファイルを生成します。

prefix_RuleSetInfo.extension

prefix_OrginalPages.extension

prefix_RewrittenPages.extension

prefix_UnaffectedPages.extension

prefix_URIInfo.extension

各表記の意味は次のとおりです。

prefix は、URL スクレーパーを使用した場合は psRewriter、ゲートウェイを使用した場合は psSRAPRewriter です。

extension は、URL スクレーパーを使用した場合は portal、ゲートウェイを使用した場合は gateway-profile-name です。

たとえば、ページの変換にゲートウェイ上のリライタとデフォルトのゲートウェイプロファイルを使用した場合は、次のデバッグファイルが生成されます。

psSRAPRewriter_RuleSetInfo.default

psSRAPRewriter_OriginalPages.default

psSRAPRewriter_RewrittenPages.default

psSRAPRewriter_UnaffectedPages.default

psSRAPRewriter_URIInfo.default

psSRAPRewriter.default

サンプルの操作

この節では、次の点を説明します。

これらのサンプルページは、portal-server-URL/rewriter ディレクトリ内にあります。ルールを適用する前にページの内容を参照し、その後、書き換えられてゲートウェイを通じて出力されたファイルを参照することで、ルールがどのように機能しているかを理解することができます。一部のサンプルでは、ルールはすでに default_gateway_ruleset の一部として含まれています。一部のサンプルでは、ルールを default_gateway_ruleset に含めなければならない場合があります。これについては、該当箇所で説明します。

注 –

太字で表示されている文は、書き換えられたことを示します。

次のサンプルが用意されています。

HTML

JavaScript

関数

XML

HTML コンテンツのサンプル

HTML 属性のサンプル

ProcedureHTML 属性のサンプルを使用する

  1. このサンプルには次の場所からアクセスできます。

    portal-server-URL/rewriter/HTML/attrib/attribute.html

  2. ゲートウェイサービスの「ドメインとサブドメインのプロキシ」リストに abc.sesta.com と host1.siroe.com が定義されていることを確認してください。

    これが定義されていないと、直接の接続が想定され、ゲートウェイ URL がプレフィックスとして追加されません。

    このサンプルに指定されているルールはすでに default_gateway_ruleset に定義されているので、追加の必要はありません。

書き換え前の HTML

<html>
Rewriting starts
<head>
<title>TEST PAGE () </title>
</head>
ID-htmlattr.1
<br><br>
1.a href <a href="http://abc.sesta.com/images/logo.gif">http://..</a>
<br><br>
2. href <a href="https://host1.siroe.com">https://..</a>
<br><br>
3. href <a href="../images/logo.gif">../images/</a>
<br><br>
4. href <a href="images/logo.gif">images/..</a> <br><br>
5. href <a href="../../images/logo.gif">../../images/</a> <br><br>
Rewriting ends
</html>

ルール

<Attribute name="href"/>

書き換え後の HTML

<html>
Rewriting starts
<head>
<title>TEST PAGE () </title>
</head>
ID-htmlattr.1
<br><br>
1. a href <a href="gateway-URL/http://abc.sesta.com/images/logo.gif">http://..</a> <br>

default_gateway_ruleset に <Attrib name="href"/> ルールがすでに定義されているので、この URL は書き換えられます。URL はすでに絶対 URL であるため、ゲートウェイ URL だけがプレフィックスとして追加されます。ゲートウェイサービスの「ドメインとサブドメインのプロキシ」リストに abc.sesta.com が定義されていることを確認してください。これが定義されていないと、直接接続が想定されるため、ゲートウェイ URL がプレフィックスとして追加されません。

2. href <a href="gateway-URL/https://host1.siroe.com">https://..</a>

// この場合も、ゲートウェイサービスの「ドメインとサブドメインのプロキシ」リストに host1.siroe.com が定義されていることを確認してください。これが定義されていないと、直接接続が想定されるため、ゲートウェイ URL がプレフィックスとして追加されません。

<br><br>
3. href <a href="gateway-URL/portal-server-URL/rewriter/HTML/images/logo.gif">../images/</a>

// 相対パスが指定されているため、必要なサブディレクトリとともにゲートウェイ URL と portal-server-URL がプレフィックスとして追加されます。用意されたサンプル構造で、HTML ディレクトリの下の images という名前のディレクトリが指定されないため、このリンクは機能しません。

<br><br>
4 href <a href="gateway-URL/portal-server-URL/rewriter/HTML/attrib/images/
logo.gif">images/..</a> <br><br>

// 相対パスが指定されているため、必要なサブディレクトリとともにゲートウェイ URL と Portal Server URL がプレフィックスとして追加されます。

5. href <a href="gateway-URL/portal-server-URL/rewriter/images/logo.gif">
../../images/</a> <br><br>

// 相対パスが指定されているため、必要なサブディレクトリとともにゲートウェイ URL と Portal Server URL がプレフィックスとして追加されます。用意されたサンプル構造で、Rewriter ディレクトリの下の images という名前のディレクトリが指定されないため、このリンクは機能しません。

Rewriting ends</html>

HTML ダイナミック JavaScript トークンのサンプル

ここでは、HTML JavaScript トークンのサンプルの使用について説明します。

ProcedureHTML JavaScript トークンのサンプルを使用するには

  1. このサンプルには次の場所からアクセスできます。

    portal-server-URL /rewriter/HTML/jstokens/JStokens.html

  2. このサンプルで指定されているルールを、default_gateway_ruleset の「JavaScript ソースを書き換えるためのルール (Rules for Rewriting JavaScript Source)」セクションに追加します。

  3. Portal Server 管理コンソールの「Portal Server 設定」のリライタサービスで default_gateway_ruleset を編集します。

  4. 端末ウィンドウからゲートウェイを再起動します。


    ./psadmin start-sra-instance –u amadmin – f  <password file> –N <profile name>– t  <gateway>

書き換え前の HTML

<html>
<head>
Rewriting starts
<script language="javascript">
function Check(test,ind){
if (ind == \qblur\q)
{alert("testing onBlur")}
if (ind == \qfocus\q)
{alert("testing onFocus")}
}
</SCRIPT>
</head>
<body>
<form>
<input TYPE=TEXT SIZE=20 value=blur onAbort="Check
(\q/indexblur.html\q,\qblur\q);return;">
<input TYPE=TEXT SIZE=20 value=blur onBlur="Check
(\q/indexblur.html\q,\qblur\q);return;">
<input TYPE=TEXT SIZE=20 value=focus onFocus="Check
(\q/focus.html\q,\qfocus\q);return;">
<input TYPE=TEXT SIZE=20 value=focus onChange="Check
(\q/focus.html\q,\qfocus\q);return;">
<input TYPE=TEXT SIZE=20 value=focus onClick="Check
(\q/focus.html\q,\qblur\q);return;">
<br><br>
</form>
</body>
Rewriting ends
</html>

ルール

<Attribute name="onClick" type="DJS"/>
<Function type="URL" name="Check" paramPatterns="y"/>
注 –

<Function name="URL" name="Check" paramPatterns="y"/> は JavaScript 関数ルールです。JavaScript 関数のサンプルで詳しく説明します。

書き換え後の HTML

<html>
<head>
Rewriting starts
<script language="javascript">
function Check(test,ind){
if (ind == \qblur\q)
{alert("testing onBlur")}
if (ind == \qfocus\q)
{alert("testing onFocus")}
}
</SCRIPT>
</head>
<body>
<form>
<input TYPE=TEXT SIZE=20 value=blur onAbort="Check
(\qgateway URL/portal-server-URL/indexblur.html\q,\qblur\q);return;">
<input TYPE=TEXT SIZE=20 value=blur onBlur="Check
(\qgateway URL/portal-server-URL/indexblur.html\q,\qblur\q);return;">
<input TYPE=TEXT SIZE=20 value=focus onFocus="Check
(\qgateway URL/portal-server-URL/focus.html\q,\qfocus\q);return;">
<input TYPE=TEXT SIZE=20 value=focus onChange="Check
(\qgateway URL/portal-server-URL/focus.html\q,\qfocus\q);return;">
<input TYPE=TEXT SIZE=20 value=focus onClick="Check
(\qgateway URL/portal-server-URL/focus.html\q,\qblur\q);return;">

// このサンプルではすべての文が書き換えられます。それぞれ、ゲートウェイと Portal Server の URL が先頭に追加されます。これは、default_gateway_ruleset ファイルに onAbort、onBlur、onFocus、onChange、および onClick のルールが定義されているためです。リライタは JavaScript トークンを検出し、あとの処理のために JavaScript 関数ルールに渡します。サンプルの 2 番目のルールは、書き換えるパラメータをリライタに伝えます。

</body>
<br>

Rewriting ends 

</html>

HTML フォームのサンプル

Procedureフォームのサンプルを使用する

  1. 次の場所にあるサンプルフォームにアクセスします。

    portal-server-URL/rewriter/HTML/forms/formrule.html

  2. ゲートウェイサービスの「ドメインとサブドメインのプロキシ」リストに abc.sesta.com が定義されていることを確認してください。

    これが定義されていないと、直接の接続が想定され、ゲートウェイ URL がプレフィックスとして追加されません。

  3. このサンプルで指定されているルールを、default_gateway_ruleset の「HTML 属性を書き換えるためのルール (Rules for Rewriting HTML Attributes)」セクションに追加します。

  4. Portal Server 管理コンソールの「Portal Server 設定」のリライタサービスで default_gateway_ruleset を編集します。

  5. 端末ウィンドウからゲートウェイを再起動します。


    ./psadmin start-sra-instance –u amadmin – f  <password file> –N <profile name>– t  <gateway>

書き換え前の HTML ページ

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body>
RW_START
<p>
<form name="form1" method="Post" action=
"http://abc.sesta.com/casestudy/html/form.html">
<input type="hidden" name="name1" value="0|1234|/test.html">
<input type="hidden" name="name3" value="../../html/test.html">
<form name="form2" method="Post" action="
http://abc.sesta.com/testcases/html/form.html"><br>
<input type="hidden" name="name1" value="0|1234|
../../html/test.html"></form>
RW_END </p>
</body>
</html>

ルール

<Form source="*" name="form1" field="name1" valuePatterns="0|1234|"/>

書き換え後の HTML ページ

<HTML>
<HEAD>
RW_START
</HEAD>
<BODY>
<P>
<FORM name=form1  method=POST action="gateway-URL/http://abc.sesta.com/casestudy/html/form.html">

default_gateway_ruleset 内の HTML ルールの一部として <Attribute name="action"/> が定義されているため、この URL は書き換えられます。この URL はすでに絶対 URL であるため、ゲートウェイ URL だけをプレフィックスとして追加する必要があります。ゲートウェイサービスの「ドメインとサブドメインのプロキシ」リストに abc.sesta.com が定義されていることを確認してください。これが定義されていないと、直接接続が想定されるため、ゲートウェイ URL がプレフィックスとして追加されません。

<input type=hidden name=name1 value=
"0|1234|gateway URL/portal-server-URL/test.html">

// ここではフォーム名は form1、フィールド名は name1 です。これはルールに指定されたフォーム名とフィールド名に一致します。ルールはこの文の value に一致する valuePatterns を 0|1234| と宣言します。したがって、valuePattern のあとの URL が書き換えられます。Portal Server の URL とゲートウェイの URL が先頭に追加されます。valuePatterns の詳細については、「ルールでのパターンマッチングの使用」を参照してください。

<input type=hidden name=name3 value="../../html/test.html">

name はルールに指定される field 名と一致しないため、この URL は書き換えられません。

</FORM>
<FORM name=form2 method=POST action=
"gateway-URL/http://abc.sesta.com/casestudy/html/form.html"><BR>

<Attribute name="action"/> はデフォルトルールセットの HTML ルールの一部として定義されているため、この URL は書き換えられます。この URL はすでに絶対 URL であるため、ゲートウェイ URL だけをプレフィックスとして追加する必要があります。

<input type=hidden name=name1 value="0|1234|../../html/test.html">

// フォーム名がルールに指定される名前と一致しないため、この URL は書き換えられません。

</FORM>
</BODY>
RW_END
</HTML>

HTML アプレットのサンプル

Procedureアプレットのサンプルを使用する

  1. アプレットの class ファイルを入手します。RewriteURLinApplet.class ファイルは、次の場所にあります。

    portal-server-URL/rewriter/HTML/applet/appletcode

    アプレットコードを参照するページのベース URL は次のとおりです。

    portal-server-URL/rewriter/HTML/applet/rule1.html

  2. このサンプルで指定されているルールを、default_gateway_ruleset の「HTML 属性を書き換えるためのルール (Rules for Rewriting HTML Attributes)」セクションに追加します。

  3. Portal Server 管理コンソールの「Portal Server 設定」のリライタサービスで default_gateway_ruleset を編集します。

  4. ゲートウェイを再起動します。


    ./psadmin start-sra-instance –u amadmin – f  <password file> –N <profile name>– t  <gateway>

書き換え前の HTML

<html>
Rewriting starts
<br>
<applet codebase=appletcode code=RewriteURLinApplet.class archive=/test>
<param name=Test1 value="/index.html">
<param name=Test2 value="../index.html">
<param name=Test3 value="../../index.html">
</applet>
Rewriting ends
</html>

ルール

<Applet source="*/rule1.html" code="RewriteURLinApplet.class" param="Test*" />

書き換え後の HTML

<HTML>
Rewriting starts
<BR>
<APPLET codebase=gateway-URL/portal-server-URL
/rewriter/HTML/applet/appletcode=RewriteURLinApplet.class archive=/test>

<Attribute name="codebase"/> ルールがすでに default_gateway_ruleset ファイルの一部として存在するため、この URL は書き換えられます。ゲートウェイと Portal Server の URL が appletcode ディレクトリのパスの前にプレフィックスとして追加されます。

<param name=Test1 value=
"gateway-URL/portal-server-URL/index.html">

// ページのベース URL が rule1.html で、パラメータ名がルールに指定されたパラメータ Test* と一致するため、この URL は書き換えられます。index.html は root レベルに指定されているため、ゲートウェイと Portal Server の URL がプレフィックスとして直接追加されます。

<param name=Test2 value="gateway-URL
/portal-server-URL/rewriter/HTML/index.html">

// ページのベース URL が rule1.html で、パラメータ名がルールに指定されたパラメータ Test* と一致するため、この URL は書き換えられます。必要に応じて、パスがプレフィックスとして追加されます。

<param name=Test3 value="gateway-URL
/portal-server-URL/rewriter/index.html">

// ページのベース URL が rule1.html で、パラメータ名がルールに指定されたパラメータ Test* と一致するため、この URL は書き換えられます。必要に応じて、パスがプレフィックスとして追加されます。

</APPLET>
Rewriting ends
</HTML>

JavaScript コンテンツのサンプル

JavaScript URL 変数のサンプル

ProcedureJavaScript の URL 変数のサンプルを使用する

  1. このサンプルには次の場所からアクセスできます。

    portal-server-URL /rewriter/JavaScript/variables/url/js_urls.html

  2. ゲートウェイサービスの「ドメインとサブドメインのプロキシ」リストに abc.sesta.com が定義されていることを確認してください。

    これが定義されていないと、直接の接続が想定され、ゲートウェイ URL がプレフィックスとして追加されません。

  3. このサンプルで指定されているルールを、default_gateway_ruleset の「JavaScript ソースを書き換えるためのルール (Rules for Rewriting JavaScript Source)」セクションに追加します。

  4. Portal Server 管理コンソールの「Portal Server 設定」のリライタサービスで default_gateway_ruleset を編集します。

  5. ルールを追加した場合は、次のコマンドでゲートウェイを再起動します。


    ./psadmin start-sra-instance –u amadmin – f  <password file> –N <profile name>– t  <gateway>

書き換え前の HTML ページ

<html>
Rewriting starts
<head>
<title>JavaScript Variable test page</title>
</head>
<body>
<script LANGUAGE="Javascript">
<!--
//URL Variables
var imgsrc="/tmp/tmp.jpg";
var imgsrc="./tmp/tmp.jpg";
var imgsrc="../tmp/tmp.jpg";
var imgsrc="../../tmp/tmp.jpg";
var imgsrc="http://abc.sesta.com/tmp/tmp.jpg";
var imgsrc="../../../tmp/tmp.jpg";
var imgsrc="tmp/tmp.jpg";
//-->
</SCRIPT>
<br>
Testing JavaScript variables!
<br>
<img src="images/logo.gif">
<br>
Image
</body>
<br>
Rewriting ends
</html>

ルール

<Variable name="imgsrc" type="URL"/>

書き換え後の HTML ページ

<html>
Rewriting starts
<head>
<title>JavaScript Variable test page</title>
</head>
<body>
<script LANGUAGE="Javascript">
<!--
//URL Variables
var imgsrc="gateway-URL/portal-server-URL/tmp/tmp.jpg";
var imgsrc="gateway-URL/portal-server-URL
/rewriter/JavaScript/variables/url/tmp/tmp.jpg";
var imgsrc="gateway-URL/portal-server-URL
/rewriter/JavaScript/variables/tmp/tmp.jpg";
var imgsrc="gateway-URL/portal-server-URL
/rewriter/JavaScript/tmp/tmp.jpg";
var imgsrc="gateway-URL/http://abc.sesta.com/tmp/tmp.jpg";
var imgsrc="gateway-URL/portal-server-URL/rewriter/tmp/tmp.jpg";
var imgsrc="gateway-URL/portal-server-URL
/rewriter/JavaScript/variables/url/tmp/tmp.jpg";

// 上記のすべての URL は、タイプが URL で、ルールで指定された imgsrc という名前を持つ JavaScript 変数です。したがってこれらの URL の先頭に、ゲートウェイと Portal Server の URL がプレフィックスとして追加されます。必要に応じて、Portal Server URL のあとにパスが追加されます。

//-->
</SCRIPT>
<br>
Testing JavaScript variables!
<br>
<img src="gateway URL/portal-server-URL/rewriter
/JavaScript/variables/url/images/logo.gif">

default_gateway_ruleset に <Attribute name="src"/> ルールが定義されているので、この行は書き換えられます。

<br>
Image
</body>
<br>
Rewriting ends
</html>

JavaScript EXPRESSION 変数のサンプル

ProcedureJavaScript の EXPRESSION 変数のサンプルを使用する

  1. このサンプルには次の場所からアクセスできます。

    portal-server-URL /rewriter/JavaScript/variables/expr/expr.html

  2. このサンプルで指定されているルールを、default_gateway_ruleset の「JavaScript ソースを書き換えるためのルール (Rules for Rewriting JavaScript Source)」セクションに追加します (まだ追加していない場合)。

  3. Portal Server 管理コンソールの「Portal Server 設定」のリライタサービスで default_gateway_ruleset を編集します。

  4. ルールを追加した場合は、次のコマンドでゲートウェイを再起動します。


    ./psadmin start-sra-instance –u amadmin – f  <password file> –N <profile name>– t  <gateway>

書き換え前の HTML ページ

<html>
<head>
<title>JavaScript EXPRESSION Variables Test Page</title>
</head>
<body>
<script LANGUAGE="Javascript">
<!--
//Expression 変数
var expvar1="images";
var expvar2="/logo.gif";
var expvar = expvar1 + expvar2;
document.write("<A HREF="+expvar+">EXPRESSION</A><P>")
var expvar="/images/logo"+".gif";
document.write("<A HREF="+expvar+">EXPRESSION</A><P>")
//-->
</SCRIPT>
Testing JavaScript EXPRESSION variables
</body>
</html>

ルール

<Variable type="EXPRESSION" name="expvar"/>

書き換え後の HTML ページ

<html>
<head>
<title>JavaScript EXPRESSION Variables Test Page</title>
</head>
<body>
<SCRIPT>
// リライタは、ラッパー関数 psSRAPRewriter_convert_expression をここに追加します。
</SCRIPT>
<script LANGUAGE="Javascript">
<!--
//Expression 変数
var expvar1="images";
var expvar2="/logo.gif";
var expvar =psSRAPRewriter_convert_expression( expvar1 + expvar2);

// リライタはこの文の右側を JavaScript EXPRESSION 変数として認識します。リライタはサーバー側でこの式の値を解決することができません。したがって psSRAPRewriter_convert_expression 関数が式の前に追加されます。式はクライアント側で評価され、必要に応じて書き換えられます。

document.write("<A HREF="+expvar+">EXPRESSION</A><P>")

// 前の文の書き換え後の値 expvar は、この式の値に到達するために使用されます。結果は有効な URL (サンプルのこの位置にグラフィックが配置される) であるため、リンクが機能します。

var expvar="gateway URL/portal-server-URL/images/logo"+".gif";

// リライタは expvar の右側を文字列式として認識します。これはサーバー側で解決できるため、直接書き換えられます。

document.write("<A HREF="+expvar+">EXPRESSION</A><P>")

// 前の文の書き換え後の値 expvar は、この式の値に到達するために使用されます。結果が有効な URL ではない (最終的な位置にグラフィックが配置されない) ため、リンクは機能しません。

//-->
</SCRIPT>
Testing JavaScript EXPRESSION variables
</body>
</html>

JavaScript DHTML 変数のサンプル

ProcedureJavaScript の DHTML 変数のサンプルを使用する

  1. このサンプルには次の場所からアクセスできます。

    portal-server-URL /rewriter/JavaScript/variables/dhtml/dhtml.html

  2. ゲートウェイサービスの「ドメインとサブドメインのプロキシ」リストに abc.sesta.com が定義されていることを確認してください。これが定義されていないと、直接の接続が想定され、ゲートウェイ URL がプレフィックスとして追加されません。

  3. このサンプルで指定されているルールを、default_gateway_ruleset の「JavaScript ソースを書き換えるためのルール (Rules for Rewriting JavaScript Source)」セクションに追加します (まだ追加していない場合)。Portal Server 管理コンソールの「Portal Server 設定」のリライタサービスで default_gateway_ruleset を編集します。

  4. ルールを追加した場合は、次のコマンドでゲートウェイを再起動します。


    ./psadmin start-sra-instance –u amadmin – f  <password file> –N <profile name>– t  <gateway>

書き換え前の HTML ページ

<html>
<head>
<title>JavaScript DHTML Variable Test Page</title>
</head>
<body>
<script LANGUAGE="Javascript">
<!--
//DHTML Var
var dhtmlVar="<a href=../../images/test.html>"
var dhtmlVar="<a href=/../images/test.html>"
var dhtmlVar="<a href=/images/test.html>"
var dhtmlVar="<a href=images/test.html>"
var dhtmlVar="<a href=http://abc.sesta.com/images/test.html>"
var dhtmlVar="<img src=http://abc.sesta.com/images/test.html>"
//-->
</SCRIPT>
<br><br>
Testing DHTML Variables
<br><br>
<img src="images/logo.gif">IMAGE
</body>
</html>

ルール

<Variable name="DHTML">dhtmlVar</Variable>

書き換え後の HTML ページ

<html>
<head>
<title>JavaScript DHTML Variable Test Page</title>
</head>
<body>
<script LANGUAGE="Javascript">
<!--
//DHTML Var
var dhtmlVar="<a href=gateway-URL/portal-server-URL
/rewriter/JavaScript/images/test.html>"

// JavaScript DHTML ルールは dhtmlVar の右側をダイナミック HTML コンテンツとして識別します。このため、default_gateway_ruleset ファイル内の HTML ルールが適用されます。ダイナミック HTML には href 属性が含まれています。default_gateway_ruleset には、<Attribute name="href"/> ルールが定義されています。したがって、href 属性の値が書き換えられます。ただし、URL は絶対 URL ではありません。このため、相対 URL はページのベース URL、および必要なサブディレクトリに置き換えられます。次に、ゲートウェイ URL が URL のプレフィックスとして追加され、最終的な書き換え出力となります。

var dhtmlVar="<a href=gateway-URL
/portal-server-URL/../images/test.html>"

// ページのベース URL が追加され、またゲートウェイ URL がプレフィックスとして追加されているため、最終的な URL は機能しません。これは最初の URL /../images/test.html が正確ではないためです。

var dhtmlVar="<a href=gateway-URL
/portal-server-URL/images/test.html>"

// ここでも、JavaScript DHTML ルールは右側をダイナミック HTML コンテンツとして識別し、それを HTML ルールに渡します。default_gateway_ruleset の HTML ルール <Attribute name="href"/> が適用され、文は次のように書き換えられます。ゲートウェイの URL と Portal Server の URL が先頭に追加されます。

var dhtmlVar="<a href=gateway URL/portal-server-URL/
rewriter/JavaScript/variables/dhtml/images/test.html>"
var dhtmlVar="<a href=gateway URL/http://abc.sesta.com/images/test.html>"
var dhtmlVar="<img src=gateway-URL/
http://abc.sesta.com/images/test.html>"

// JavaScript DHTML ルールは右側のダイナミック HTML コンテンツを識別し、文を HTML ルールに渡します。default_gateway_ruleset 内の <Attribute name="src"/> ルールが適用されます。URL はすでに絶対 URL であるため、ゲートウェイ URL だけをプレフィックスとして追加する必要があります。ゲートウェイサービスの「ドメインとサブドメインのプロキシ」リストに abc.sesta.com が定義され、この URL が書き換えられることを確認してください。

//-->
</SCRIPT>
<br><br>
Testing DHTML Variables
<br><br>
<img src="gateway-URL/portal-server-URL/
rewriter/JavaScript/variables/dhtml/images/logo.gif">

default_gateway_ruleset に <Attribute name="src"/> ルールが定義されているので、この行は書き換えられます。

<br><br>
Image
</body>
</html>

JavaScript DJS 変数のサンプル

ProcedureJavaScript の DJS 変数のサンプルを使用する

  1. このサンプルには次の場所からアクセスできます。

    portal-server-URL /rewriter/JavaScript/variables/djs/djs.html

  2. ゲートウェイサービスの「ドメインとサブドメインのプロキシ」リストに abc.sesta.com が定義されていることを確認してください。これが定義されていないと、直接の接続が想定され、ゲートウェイ URL がプレフィックスとして追加されません。

  3. このサンプルで指定される 2 つのルールを、default_gateway_ruleset の「JavaScript ソースを書き換えるためのルール (Rules for Rewriting JavaScript Source)」セクションに追加します (まだ追加していない場合)。Portal Server 管理コンソールの「Portal Server 設定」のリライタサービスで default_gateway_ruleset を編集します。

  4. ゲートウェイを再起動します。


    ./psadmin start-sra-instance –u amadmin – f  <password file> –N <profile name>– t  <gateway>

書き換え前の HTML ページ

<html>
<head>
<title>Dynamic JavaScript Variable Test Page</title>
</head>
<body>
<script LANGUAGE="Javascript">
<!--
var dJSVar="var dJSimgsrc=\q/tmp/tmp/jpg\q;"
var dJSVar="var dJSimgsrc=\q../../../tmp/tmp/jpg\q;"
var dJSVar="var dJSimgsrc=\qhttp://abc.sesta.com/tmp/tmp/jpg\q;"
//-->
</SCRIPT>
<br>
Testing Dynamic JavaScript Variables
<br>
<img src="images/logo.gif">
<br>
Image
</body>
</html>

ルール

<Variable name="dJSVar" type="DJS"/>
<Variable name="dJSimgsrc“ type=URL"/>

書き換え後の HTML ページ

<html>
<head>
<title>Dynamic JavaScript Variable Test Page</title>
</head>
<body>
<script LANGUAGE="Javascript">
<!--
var dJSVar="var dJSimgsrc=\qgateway-URL
/portal-server-URL/tmp/tmp/jpg\q;"
var dJSVar="var dJSimgsrc=\qgateway-URL
/portal-server-URL/rewriter/tmp/tmp/jpg\q;"
var dJSVar="var dJSimgsrc=\qgateway-URL
/http://abc.sesta.com/tmp/tmp/jpg\q;"

// 上のすべての文は、ゲートウェイ URL と Portal Server URL で書き換えられます。必要に応じて適切なパスがプレフィックスとして追加されます。最初のルールは、dJSVar の右側をダイナミック JavaScript 変数として識別します。これは 2 番目のルールに渡され、2 番目のルールは dJSimgsrc の右側をタイプ URL の JavaScript 変数として識別します。これにより、文は次のように書き換えられます。

//-->
</SCRIPT>
<br>
Testing Dynamic JavaScript Variables
<br>
<img src="gateway-URL/portal-server-URL
/rewriter/JavaScript/variables/djs/images/logo.gif">

default_gateway_ruleset に <Attribute name="src"/> ルールが定義されているので、この行は書き換えられます。

<br>
Image
</body>
</html>

JavaScript SYSTEM 変数のサンプル

ProcedureJavaScript の SYSTEM 変数のサンプルを使用する

  1. このサンプルには次の場所からアクセスできます。

    portal-server-URL /rewriter/JavaScript/variables/system/system.html

  2. このサンプルで指定されているルールを、default_gateway_ruleset の「JavaScript ソースを書き換えるためのルール (Rules for Rewriting JavaScript Source)」セクションに追加します (まだ追加していない場合)。

  3. Portal Server 管理コンソールの「Portal Server 設定」のリライタサービスで default_gateway_ruleset を編集します。

  4. ゲートウェイを再起動します。


    ./psadmin start-sra-instance –u amadmin – f  <password file> –N <profile name>– t  <gateway>

書き換え前の HTML ページ

<html>
<head>
<title>JavaScript SYSTEM Variables Test Page</title>
</head>
<body>
<script LANGUAGE="Javascript">
<!--
//SYSTEM 変数
alert(window.location.pathname);
//document.write
("<A HREF="+window.location.pathname+">SYSTEM</A><P>")
//-->
</SCRIPT>
Testing JavaScript SYSTEM Variables
<br>
This page displays the path where 
the current page is located when loaded.
</body>
</html>

ルール

<Variable name="window.location.pathname" type="SYSTEM"/>

書き換え後の HTML

<html>
<head>
<title>JavaScript SYSTEM Variables Test Page</title>
</head>
<body>
<SCRIPT>
convertsystem function definition...
</SCRIPT>
<script LANGUAGE="Javascript">
<!--
//SYSTEM 変数
alert(psSRAPRewriter_convert_system
(window.location, window.location.pathname,"window.location"));

// リライタは window.location.pathname を JavaScript の SYSTEM 変数として識別します。この変数の値はサーバー側で決定することができません。このため、リライタはこの変数の前に psSRAPRewriter_convert_pathname 関数を追加します。このラッパー関数は、クライアント側で変数の値を判断し、必要に応じて書き換えます。

//-->
</SCRIPT>
Testing JavaScript SYSTEM Variables
<br>
This page displays the path where
the current page is located when loaded.
</body>
</html>

JavaScript URL 関数のサンプル

ProcedureJavaScript の URL 関数のサンプルを使用する

  1. このサンプルには次の場所からアクセスできます。

    portal-server-URL /rewriter/JavaScript/functions/url/url.html

  2. このサンプルで指定されているルールを、default_gateway_ruleset の「JavaScript ソースを書き換えるためのルール (Rules for Rewriting JavaScript Source)」セクションに追加します (まだ追加していない場合)。Portal Server 管理コンソールの「Portal Server 設定」のリライタサービスで default_gateway_ruleset を編集します。

  3. ゲートウェイを再起動します。


    ./psadmin start-sra-instance –u amadmin – f  <password file> –N <profile name>– t  <gateway>

書き換え前の HTML ページ

<html>
<body>
JavaScript URL Function Test Page
<br>
<script language="JavaScript">
<!--
function test(one,two,three)
{
alert(one + "##" + two + "##" +three);
}
test("/test.html","../test.html","123");
window.open("/index.html","gen",width=500,height=500);
//-->
</SCRIPT>
</body>
</html>

ルール

<Function type="URL" name="test" paramPatterns="y,y"/>
<Function type="URL" name="window.open" paramPatterns="y"/>

書き換え後の HTML ページ

<html>
<body>
JavaScript URL Function Test Page
<br>
<script language="JavaScript">
<!--
function test(one,two,three)
{
alert(one + "##" + two + "##" +three);
}
test("/test.html","../test.html","123");
window.open("gateway-URL/portal-server-URL
/index.html","gen",width=500,height=500);
//-->
</SCRIPT>
</body>
</html>

JavaScript EXPRESSION 関数のサンプル

ProcedureJavaScript の EXPRESS 関数のサンプルを使用する

  1. このサンプルには次の場所からアクセスできます。

    <portal-install-location>/SUNWportal/samples/rewriter

  2. このサンプルで指定されているルールを、default_gateway_ruleset の「JavaScript ソースを書き換えるためのルール (Rules for Rewriting JavaScript Source)」セクションに追加します (まだ追加していない場合)。

  3. Portal Server 管理コンソールを使用して、リライタサービスの default_gateway_ruleset を編集します。

  4. ゲートウェイを再起動します。


    ./psadmin start-sra-instance –u amadmin – f  <password file> –N <profile name>– t  <gateway>

書き換え前の HTML ページ

<html>
<body>
JavaScript EXPRESSION Function Test Page
<br><br><br>
<script language="JavaScript">
<!--
function jstest2()
{
return ".html";
}
function jstest1(one)
{
return one;
}
var dir="/images/test"
var test1=jstest1(dir+"/test"+jstest2());
document.write("<a HREF="+test1+">Test</a>");
alert(test1);
//-->
</SCRIPT>
</body>
</html>

ルール

<Function type="EXPRESSION" name="jstest1" paramPatterns="y"/>

書き換え後の HTML ページ

<html>
<body>
JavaScript EXPRESSION Function Test Page
<br><br><br>
<script>
<!--
// ここには、psSRAPRewriter_convert_expression を含むさまざまな関数が表示されます。//-->
</SCRIPT>
<script language="JavaScript">
<!--
function jstest2()
{
return ".html";
}
function jstest1(one)
{
return one;
}
var dir="/images/test"
var test1=jstest1(psSRAPRewriter_convert_
expression(dir+"/test"+jstest2()));

// このルールは、関数 jstest1 のタイプ EXPRESSION の最初のパラメータを書き換える必要があることを指定します。この式の値は /test/images/test.html です。この値の前に、Portal Server URL とゲートウェイ URL がプレフィックスとして追加されます。

document.write("<a HREF="+test1+">Test</a>");
alert(test1);
//-->
</SCRIPT>
</body>
</html>

JavaScript DHTML 関数のサンプル

ProcedureJavaScript の DHTML 関数のサンプルを使用する

  1. このサンプルには次の場所からアクセスできます。

    portal-server-URL /rewriter/JavaScript/functions/dhtml/dhtml.html

  2. このサンプルで指定されているルールを、default_gateway_ruleset の「JavaScript ソースを書き換えるためのルール (Rules for Rewriting JavaScript Source)」セクションに追加します (まだ追加していない場合)。

  3. Portal Server 管理コンソールの「Portal Server 設定」のリライタサービスで default_gateway_ruleset を編集します。

  4. ゲートウェイを再起動します。


    ./psadmin start-sra-instance –u amadmin – f  <password file> –N <profile name>– t  <gateway>

書き換え前の HTML ページ

<html>
<head>
Testing JavaScript DHTML Functions
<br>
<br>
<script>
<!--
document.write(\q<a href="/index.html">write</a><BR>\q)
document.writeln(\q<a href="index.html">writeln</a><BR>\q)
document.write("http://abc.sesta.com/index.html<BR>")
document.writeln("http://abc.sesta.com/index.html<BR>")
//-->
</SCRIPT>
</head>
<body BGCOLOR=white>
<br><br>
Testing document.write and document.writeln
</body>
</html>

ルール

<Function type="DHTML" name=" document.write" paramPatterns="y"/>
<Function type="DHTML" name=" document.writeln" paramPatterns="y"/>

書き換え後の HTML ページ

<html>
<head>
Testing JavaScript DHTML Functions
<br>
<br>
<script>
<!--
document.write(\q<a href="gateway-URL
/portal-server-URL/index.html">write</a><BR>\q)

// 最初のルールは、DHTML JavaScript 関数 document.write の最初のパラメータを書き換える必要があることを示します。リライタは、最初のパラメータが単純な HTML 文であることを識別します。default_gateway_ruleset の HTML ルールのセクションには <Attribute name="href" /> ルールが定義されており、書き換えが必要な文はこのルールによって決定されます。

document.writeln(\q<a href="gateway-URL
/portal-server-URL/rewriter/JavaScript/functions/dhtml/index.html">writeln</a><BR>\q)

// 2 番目のルールは、DHTML JavaScript 関数 document.writeln の最初のパラメータを書き換える必要があることを示します。リライタは、最初のパラメータが単純な HTML 文であることを識別します。default_gateway_ruleset の HTML ルールのセクションには <Attribute name="href" /> ルールが定義されており、書き換えが必要な文はこのルールによって決定されます。

document.write("http://abc.sesta.com/index.html<BR>")
document.writeln("http://abc.sesta.com/index.html<BR>")

// DHTML ルールは関数 document.write と document.writeln を検出しますが、上の文は書き換えられません。これは最初のパラメータが HTML ではないためです。パラメータは任意の文字列となり、リライタはこれをどのように書き換えるかを指示されていません。

//-->
</SCRIPT>
</head>
<body BGCOLOR=white>
<br><br>
Testing document.write and document.writeln
</body>
</html>

JavaScript DJS 関数のサンプル

ProcedureJavaScript の DJS 関数のサンプルを使用する

  1. このサンプルには次の場所からアクセスできます。

    portal-server-URL /rewriter/JavaScript/functions/djs/djs.html

  2. ゲートウェイサービスの「ドメインとサブドメインのプロキシ」リストに abc.sesta.com が定義されていることを確認してください。

    これが定義されていないと、直接の接続が想定され、ゲートウェイ URL がプレフィックスとして追加されません。

  3. このサンプルで指定されているルールを、default_gateway_ruleset の「JavaScript ソースを書き換えるためのルール (Rules for Rewriting JavaScript Source)」セクションに追加します (まだ追加していない場合)。Portal Server 管理コンソールの「Portal Server 設定」のリライタサービスで default_gateway_ruleset を編集します。

  4. ゲートウェイを再起動します。


    ./psadmin start-sra-instance –u amadmin – f  <password file> –N <profile name>– t  <gateway>

書き換え前の HTML ページ

<html>
Test for JavaScript DJS Functions
<br>
<script>
menu.addItem(new NavBarMenuItem("All Available
Information","JavaScript:top.location=\qhttp://abc.sesta.com\q"));
//menu.addItem(new NavBarMenuItem("All Available Information","http://abc.sesta.com"));
</script>
</html>

ルール

<Function type="DJS" name="NavBarMenuItem" paramPatterns=",y"/>
<Variable type="URL" name="top.location"/>

書き換え後の HTML ページ

<html>
Testing JavaScript DJS Functions
<br>
<script>
menu.addItem(new NavBarMenuItem
("All Available Information","javaScript:top.location=
\qgateway-URL/http://abc.sesta.com\q"));

abc.sesta.com はゲートウェイサービスの「ドメインとサブドメインのプロキシ」リストのエントリです。したがって、リライタはこの URL を書き換える必要があります。ただし、これは絶対 URL であるため、Portal Server の URL をプレフィックスとして追加する必要はありません。DJS ルールは、DJS 関数 NavBarMenuItem の 2 番目のパラメータを書き換える必要があることを指定します。ただし、2 番目のパラメータは同じく JavaScript 変数です。2 番目のルールは、この変数の値を書き換える場合に必要となります。2 番目のルールは、JavaScript 変数 top.location の値を書き換える必要があることを指定します。これらのすべての条件に適合するため、URL が書き換えられます。

//menu.addItem(new NavBarMenuItem("All Available Information","http://abc.sesta.com"));

// DJS ルールは、関数 NavBarMenuItem の 2 番目のパラメータを書き換える必要があることを指定しますが、この文は書き換えられません。これはリライタが 2 番目のパラメータを HTML と認識しないためです。

</script>
</html>

XML 属性のサンプル

ProcedureXML 属性のサンプルを使用する

  1. このサンプルには次の場所からアクセスできます。

    portal-server-URL /rewriter/XML/attrib.html

  2. このサンプルで指定されているルールを、default_gateway_ruleset の「XML ソースを書き換えるためのルール (Rules for Rewriting XML Source)」セクションに追加します (まだ追加していない場合)。

  3. Portal Server 管理コンソールの「Portal Server 設定」のリライタサービスで default_gateway_ruleset を編集します。

  4. ゲートウェイを再起動します。


    ./psadmin start-sra-instance –u amadmin – f  <password file> –N <profile name>– t  <gateway>

書き換え前の XML

<html>
RW_START
<body>
<xml>
<baseroot href="/root.html"/>
</xml>
<xml>
<img href="image.html"/>
</xml>
<xml>
<string href="1234|substring.html"/>
</xml>
<xml>
<check href="1234|string.html"/>
</xml>
</body>
RW_END
</html>

ルール

<Attribute name="href" tag="check" valuePatterns="1234|"/>

書き換え後の HTML

<html>
Rewriting starts
<br>
<br>
<body>
<xml><baseroot href="/root.html"/></xml>
<xml><img href="image.html"/></xml>
<xml><string href="1234|substring.html"/></xml>
<xml><check href="1234|gateway-URL/portal-server-URL
/rewriter/XML/string.html"/></xml>

// この文はルールで指定された条件と一致するため、書き換えられます。Attribute name は href、tag は check、valuePatterns は 1234 です。valuePatterns よりもあとの文字列は書き換えられます。valuePatterns の詳細については、「ルールでのパターンマッチングの使用」を参照してください。

</body>
Rewriting ends
</html>

ケーススタディー

ここでは、メールクライアントのソース HTML ページの例について説明します。このケーススタディーでは、考えられるすべての例やルールについて説明することはできません。これはあくまでも、イントラネットページにルールを適用するために使用するルールセットの例です。

前提条件

このケーススタディーは、次のような前提で行います。

ページ例 1

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0053)http://abc.siroe.com/mailclient/destin/?Cmd=navbar -->
<HTML XMLNS:WM><HEAD>
<META http-equiv=Content-Type content="text/html; CHARSET=utf-8">
<META http-equiv=Pragma content=no-cache>
<META http-equiv=Expires content=0><!--Copyright (c) 2000 Microsoft Corporation.
All rights reserved.--><!--CURRENT FILE== "IE5" "WIN32" navbar -->
<STYLE>WM\\:DROPMENU {
BEHAVIOR: url(http://abc.siroe.com/mailweb/controls/dropmenu.htc)
}
</STYLE>
<LINK href="destin_files/navbar.css" type=text/css rel=stylesheet>
<SCRIPT language=javascript>
var g_szUserBase= "http://abc.siroe.com/mailclient/destin"+"/";
var g_szFolder= ".";
var g_szVirtualRoot= "http://abc.siroe.com/mailweb";
var g_szImagePath= g_szVirtualRoot + "/img/";
</SCRIPT>
<SCRIPT src="/destin_files/navbar.js"></SCRIPT>
<META content="MSHTML 6.00.2600.0" name=GENERATOR></HEAD>
<BODY oncontextmenu=return(event.ctrlKey); onselectstart=return(false);
id=outbar_mainbody style="BACKGROUND-COLOR: appworkspace" leftMargin=0
topMargin=0 scroll=no>
<TABLE class=nbTableMain id=nbTableMain style="HEIGHT: 100%" cellSpacing=0
cols=1 cellPadding=0 rows="2">
<TBODY>
<TR>
<TD class=treeBrand>
<DIV class=treeOFLOW><IMG
style="PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; PADDING-TOP: 0px"
src="/destin_files/logo-ie5.gif" border=0></DIV></TD></TR>
<TR height="100%">
<TD>
<TABLE class=nbTable cellSpacing=0 cols=1 cellPadding=0 rows="4">
<TBODY>
<TR>
<TD class=nbFlybar id=show_navbar onkeydown=flybar_keydown()
onclick=ToggleTab(this.id) tabIndex=0 noWrap>
<DIV class=treeOFLOW>Shortcuts</DIV></TD></TR>
<TR style="HEIGHT: 100%">
<TD id=idOutbarpane style="TEXT-ALIGN: center" vAlign=top><A
id=inbox
href="http://abc.siroe.com/mailclient/destin/Inbox/?Cmd=contents&amp;Page=1"
target=viewer alt="Go to inbox"><IMG class=nbImage alt="Go to inbox"
src="destin_files/navbar-inbox.gif"></A>
<DIV class=nbLabel>Inbox</DIV><BR><A id=calendar
href="http://abc.siroe.com/mailclient/destin/Calendar/?Cmd=contents"
target=viewer alt="Go to calendar"><IMG class=nbImage
alt="Go to calendar" src="destin_files/navbar-calendar.gif"></A>
<DIV class=nbLabel>Calendar</DIV><BR><A id=contacts
            href="http://abc.siroe.com/mailclient/destin/Contacts/?Cmd=contents"
target=viewer alt="Go to contacts"><IMG class=nbImage
alt="Go to contacts" src="destin_files/navbar-contacts.gif"></A>
<DIV class=nbLabel>Contacts</DIV><BR><A id=options
href="http://abc.siroe.com/mailclient/destin/?Cmd=options"
target=viewer alt="Go to options"><IMG class=nbImage
alt="Go to options" src="destin_files/navbar-options.gif"></A>
<DIV class=nbLabel>Options</DIV></TD></TR>
<TR style="HEIGHT: 1.5em">
<TD class=nbFlybar id=show_folders onkeydown=flybar_keydown()
onclick=ToggleTab(this.id) tabIndex=0 noWrap>
<DIV class=treeOFLOW>Folders</DIV></TD></TR>
<TR>
<TD class=nbTreeProgress id=treeProgress style="DISPLAY: none"
vAlign=top noWrap><SPAN id=idLoading
style="OVERFLOW: hidden">Loading...</SPAN>
</TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE>
</BODY></HTML>

説明

「説明」は、サンプルルールセットとケーススタディーの間のマッピングを示しています。

表 4–3 サンプルルールセットとケーススタディーのマッピング

ページコンテンツ 

適用されるルール 

リライタの出力 

説明 

 
var g_szVirtualRoot=
"http://abc.siroe.com/m
ailweb";

<Variable name="URL"> g_szVirtualRoot </Variable> 

 
var g_szVirtualRoot= 
"http://gateway.sesta.com
/http://abc.siroe.com/mai
lweb";

g_szVirtualRoot は単一の URL を値に持つ変数です。

このルールは、タイプ URL の変数 g_szVirtualRoot を検索するようにリライタに指示します。このような変数が Web ページに存在する場合、リライタはこれを絶対 URL に変換し、ゲートウェイ URL をプレフィックスとして追加します。

 
src="/destin_files/
logo-ie5.gif"

<Attribute name="src" /> 

 
src="http://gateway.sesta.
com/
http://abc.siroe.com/
destin_files/logo-ie5.gif

src は属性名であり、タグまたは valuePattern は付加されません。 

このルールは、src という名前の属性をすべて検索し、その属性の値を書き換えるようにリライタに指示します。

 
href="http://abc.siroe.
com

/mailclient/destin/Inbo
x/
?Cmd=contents&amp;Page=
1"

<Attribute name="href"/> 

href="http://gateway.sest
a.com/
http://abc.siroe.com
/mailclient/destin/
Inbox/?Cmd=contents&amp;P
age=1"

href は属性名であり、タグまたは valuePattern は付加されません。 

このルールは、href という名前の属性をすべて検索し、その属性の値を書き換えるようにリライタに指示します。

注 –

ルールセットを適用する優先順位は、ホスト名 - サブドメイン - ドメインです。

たとえば、「ドメインベースのルールセット」リストに次のエントリを指定していると仮定します。

sesta.com|ruleset1
eng.sesta.com|ruleset2
host1.eng.sesta.com|ruleset3

ruleset3 は host1 のすべてのページに適用されます。

ruleset2 は、host1 から取得されたページを除く eng サブドメインのすべてのページに適用されます。

ruleset1 は、eng サブドメインおよび host1 から取得されたページを除く、sesta.com ドメインのすべてのページに適用されます。

  1. 「保存」をクリックして終了します。

  2. 端末ウィンドウからゲートウェイを再起動します。


    ./psadmin start-sra-instance –u amadmin – f  <password file> –N <profile name>– t  <gateway>

Outlook Web Access 用のルールセット

Secure Remote Access サーバーでは、Sun Java System Web Server および IBM アプリケーションサーバー上で、Outlook Web Access (OWA) から MS Exchange 2000 SP3 インストールおよび MS Exchange 2003 にアクセスする機能がサポートされます。

ProcedureOWA のルールセットを設定する

  1. Portal Server 管理コンソールに管理者としてログインします。

  2. 「Secure Remote Access」タブを選択し、属性を設定するゲートウェイプロファイルを選択します。

  3. 「URI をルールセットにマップ」フィールドで、Exchange 2000 がインストールされているサーバー名を入力し、それに続けて Exchange 2000 Service Pack 4 OWA ルールセットを入力します。

    次に例を示します。


    exchange.domain.com|exchange_2000sp3_owa_ruleset.

パブリックフォルダの使用

Exchange 側では、パブリックフォルダは NTLM 認証を使用するように設定されています。これは、HTTP 基本認証を使用するように変更する必要があります。

この変更を行うには、Exchange サーバーで「コントロールパネル」 > 「管理ツール」の順に選択し、「インターネットインフォメーションサービス」を開きます。

「既定の Web サイト」の下に、パブリックフォルダに関する「パブリック」というタブがあります。タブを右クリックし、プロパティーを選択します。「ディレクトリセキュリティー」タブをクリックします。「匿名アクセスと認証」コントロールパネルで「編集」を選択します。「基本認証」チェックボックスのみを選択し、ほかのすべてのチェックボックスの選択を解除します。

6.x と 3.0 のルールセットのマッピング

次の表は、Secure Remote Access サーバーのリライタルールと従来のリリースの Portal Server 製品とのマッピングを示しています。

表 4–4 SP3 のルールのマッピング

リライタ 6.0 の DTD 要素 

リライタ 3.0 リストボックス名 

HTML コンテンツのルール

 

Attribute: URL 

HTML 属性の書き換え 

Attribute: DJS 

JavaScript を含む HTML 属性の書き換え 

Form 

フォーム入力タグリストの書き換え 

アプレット 

アプレット/オブジェクトパラメータ値リストの書き換え 

JavaScript コンテンツのルール

 

Variable: URL 

URL タイプの JavaScript 変数の書き換え 

Variable: EXPRESSION 

JavaScript 変数関数の書き換え 

Variable: DHTML 

HTML タイプの JavaScript 変数の書き換え 

Variable: DJS 

JavaScript タイプの JavaScript 変数の書き換え 

Variable: SYSTEM 

JavaScript システム変数の書き換え 

Function: URL 

JavaScript 関数パラメータの書き換え 

Function: EXPRESSION 

JavaScript 関数パラメータ関数の書き換え 

Function: DHTML 

HTML タイプの JavaScript 関数パラメータの書き換え 

Function: DJS 

JavaScript タイプの JavaScript 関数パラメータの書き換え 

XML コンテンツのルール

 

Attribute: URL 

XML ドキュメントの属性値の書き換え 

TagText 

XM1 ドキュメントのテキストデータの書き換え 

CSS コンテンツのルール

 

ルールは不要です。デフォルトでは、すべての URL が変換されます。 

 

WML コンテンツのルール

 

ルールは定義されていません。WML は HTML として処理され、HTML ルールが適用されます。 

 

WMLScript コンテンツのルール

 
   

WML スクリプトはサポートされていません。 

 

第 5 章 ネットファイルの操作

この章では、ネットファイルおよびその操作について説明します。ネットファイルの設定については、第 14 章「ネットファイルの設定」を参照してください。

ネットファイルの概要

ネットファイルは、ユーザーがリモートのファイルシステムとディレクトリにアクセスして操作できるようにするファイルマネージャーアプリケーションです。

Secure Remote Access のネットファイルコンポーネントは、Java2 アプレットとして使用できます。Java2 アプレットのインタフェースは改善され、より使いやすくなっています。

ネットファイルの主な機能は次のとおりです。

サポートされるファイルアクセスプロトコル

ネットファイルでは FTP、NFS、および jCIFS (Microsoft Windows) の各プロトコルを使用してリモートシステムにアクセスできます。ネットファイルには、次のファイルアクセスプロトコル機能が含まれています。

注 –

サーバーが標準以外のポートで稼動していると、接続に失敗します。

表 5–1 ファイルシステムとサポートされるプロトコル

ファイルシステム/プロトコル 

プラットフォーム 

FTP 

Novell Netware の Novell FTP 5.1 サーバー 

Windows NT 4.0 の MS FTP サーバー 4.0 

Windows 2000 の MS FTP サーバー 5.0 

Solaris FTP サーバー 

WU_FTP 2.6.1 

ProFTPD 1.2.8 

vsFTPd 1.2.0 

NFS 

Solaris 2.6 以降 

jCIFS 

Windows 95/98/NT/2000/ME/XP 

注 –

ネットファイルを使用して ProFTPD サーバーにファイルをアップロードするには、ProFTPD サーバーが稼動するホストの proftpd.conf ファイルで「AllowStoreRestart」を「on」に設定する必要があります。

Novell Netware は FTP サーバーを通じてのみサポートされ、ネイティブアクセスを通じてはサポートされません。

Microsoft Windows (SMB/CIFS) ファイルシステムにアクセスするには、Portal Server 上に jCIFS がインストールされている必要があります。jCIFS は、CIFS/SMB ネットワーキングプロトコルを実装するオープンソースのクライアントライブラリです。

Procedureネットファイルポリシーを作成する

  1. Portal Server 管理コンソールに管理者としてログインします。

  2. 「Secure Remote Access」タブを選択し、「ネットファイル」タブを選択します。

  3. 「DN を選択」ドロップダウンボックスで、「組織」、「ロール」、または「ユーザー」を選択します。

  4. ホストおよびサービスへのアクセスや拒否に関する権限を設定します。

  5. 「保存」をクリックします。

  6. ゲートウェイを再起動します。

第 6 章 ネットレットの操作

この章では、ユーザーのリモートデスクトップとイントラネット上のアプリケーションを実行しているサーバーとの間で、ネットレットを使用してアプリケーションを安全に実行する方法について説明します。ネットレットの設定については、第 11 章「ネットレットの設定」を参照してください。

この章で説明する内容は次のとおりです。

ネットレットの概要

Sun Java System Portal Server のユーザーが、一般的なアプリケーションや企業専用のアプリケーションをリモートデスクトップで安全に実行できると便利な場合があります。プラットフォームにネットレットを設定すると、このようなアプリケーションに安全にアクセスできるようになります。

ネットレットを使用することで、インターネットなどのセキュリティーの弱いネットワークで一般的な TCP/IP サービスを安全に実行できます。TCP/IP アプリケーション (Telnet や SMTP など)、HTTP アプリケーション、同じポートを使用するすべてのアプリケーションを実行できます。

アプリケーションが TCP/IP ベースであるか同じポートを使用する場合、ネットレットを介してアプリケーションを実行できます。

注 –

ダイナミックポートは、FTP を使用する場合にだけサポートされます。Microsoft Exchange を使用する場合は、OWA (Outlook Web Access) を使用します。

ネットレットアプレットを使用する場合は、ブラウザのポップアップブロッカを無効にするようにユーザーに通知してください。

ネットレットのコンポーネント

「ネットレットのコンポーネント」は、ネットレットで使用される各種コンポーネントを示しています。

図 6–1 ネットレットのコンポーネント

ネットレットのコンポーネント

localhost の待機ポート

これはネットレットアプレットが待機するクライアントマシン上のポートです。クライアントマシンは localhost です。

ネットレットアプレット

ネットレットアプレットは、リモートクライアントマシンと、Telnet、Graphon、Citrix などのイントラネットアプリケーションの間で、暗号化された TCP/IP トンネルの設定を担当します。アプレットはパケットを暗号化してゲートウェイに送信し、ゲートウェイからの応答パケットを解読してローカルアプリケーションに送信します。

スタティックルールの場合、ネットレットアプレットは、ユーザーがポータルにログインすると自動的にダウンロードされます。ダイナミックルールの場合、ダイナミックルールに対応するリンクをユーザーがクリックしたときにアプレットがダウンロードされます。スタティックルールとダイナミックルールの詳細については、「ルールのタイプ」を参照してください。

Sun Ray 環境でのネットレットの実行については、「Sun Ray 環境でのネットレットの実行」を参照してください。

ネットレットルール

ネットレットルールでは、クライアントマシンで実行する必要のあるアプリケーションが、対応する接続先ホストにマッピングされます。つまりネットレットは、ネットレットルールに定義されたポートに送信されたパケットに対してだけ動作します。これにより、セキュリティーが向上します。

管理者はネットレットの機能に対して特定のルールを設定する必要があります。これらのルールによって、使用される暗号化方式や、呼び出す URL、ダウンロードするアプレット、接続先ポート、接続先ホストなどの詳細が指定されます。クライアントマシン上のユーザーがネットレットを通じて要求を行う場合、これらのルールに基づいて接続の確立方法がすみやかに決定されます。詳細については、「ネットレットルールの定義」を参照してください。

ネットレットプロバイダ

これはネットレットの UI コンポーネントです。プロバイダを使用することで、Portal Server のデスクトップから必要なアプリケーションを設定できます。プロバイダにリンクが作成され、ユーザーはこのリンクをクリックして必要なアプリケーションを実行します。また、デスクトップネットレットプロバイダで、ダイナミックルールの接続先ホストを指定できます。「ネットレットルールの定義」を参照してください。

ネットレットプロキシ (オプション)

ゲートウェイは、リモートクライアントマシンとゲートウェイ間のセキュリティー保護されたトンネルを保証します。ネットレットプロキシの使用は任意です。インストール時にこのプロキシをインストールしない選択も可能です。ネットレットプロキシについては、「ネットレットプロキシの使用」を参照してください。

ネットレットの使用例

ネットレット使用時には、次の一連のイベントが行われます。

  1. リモートユーザーが Portal Server デスクトップにログインします。

  2. ユーザー、ロール、または組織にスタティックネットレットルールが定義されている場合は、リモートクライアントにネットレットアプレットが自動的にダウンロードされます。

    ユーザー、ロール、または組織にダイナミックルールが定義されている場合は、ネットレットプロバイダに必要なアプリケーションを手動で設定する必要があります。ネットレットアプレットは、ユーザーがネットレットプロバイダのアプリケーションリンクをクリックしたときにダウンロードされます。スタティックルールとダイナミックルールの詳細については、「ネットレットルールの定義」を参照してください。

  3. ネットレットはネットレットルールで定義されたローカルポートで待機します。

  4. ネットレットはリモートクライアントとホストの間で、ネットレットルールで指定されたポートを使用するチャネルを確立します。

ネットレットの操作

ネットレットが異なる組織間のさまざまなユーザーの要求に合わせて機能するには、次の手順を実行する必要があります。

  1. ユーザー要件に基づいて、スタティックルールとダイナミックルールのどちらを作成するかを決定します。「ルールのタイプ」を参照してください。

  2. Portal Server 管理コンソールから、ネットレットサービスのオプションを設定します。ネットレットの設定については、第 11 章「ネットレットの設定」を参照してください。

  3. ルールの基準を組織、ロール、ユーザーから選択し、各レベルで必要に応じて修正します。組織、ロール、およびユーザーの詳細については、『Portal Server 管理ガイド』を参照してください。

    注 –

    srapNetletServlet.properties ファイルのフレームセットパラメータの値に、英語以外の言語は使用しないでください。

リモートホストからのアプレットのダウンロード

URL から返されたページに、リモートマシンから取得する必要があるアプレットが埋め込まれていることがあります。ただし、Java のセキュリティーによって、アプレットがそのアプレットのダウンロード元以外のホストと通信することは許可されていません。アプレットがローカルネットワークポートを使用してゲートウェイと通信できるようにするには、Access Manager 管理コンソールの「アプレットのダウンロード」フィールドを確認し、次の構文を指定する必要があります。

local-port:server-host:server-port

各表記の意味は次のとおりです。

local-port はローカルポートです。ネットレットは、アプレットから送信されるトラフィックをここで待機します。

server-host は、アプレットのダウンロード元です。

server-port は、アプレットのダウンロードに使用されるポートです。

ネットレットルールの定義

ネットレットの設定はネットレットルールによって定義されます。このルールは、Portal Server 管理コンソールの「Secure Remote Access」設定タブを使用して設定されます。ネットレットルールは組織、ロール、またはユーザーのいずれかに対して設定できます。ネットレットルールをロールまたはユーザーに対して定義したときは、組織を選択してから目的のロールまたはユーザーを選択します。

注意 – 注意 –

ネットレットルールはマルチバイトエントリをサポートしません。ネットレットルールのどのフィールドにもマルチバイト文字を指定しないでください。

ネットレットルールには 64000 を超えるポート番号を指定できません。

「ネットレットルールの定義」は、ネットレットルールのフィールドを示しています。

表 6–1 ネットレットルールのフィールド

パラメータ 

説明 

値 

ルール名 

このネットレットルールの名前を指定します。各ルールに一意の名前を指定する必要があります。これは、特定のルールへのアクセスを定義する場合に便利です。 

 

暗号化方式 

暗号化方式を定義するか、ユーザーが選択できる方式のリストを指定します。 

選択した暗号化方式は、ネットレットプロバイダにリスト表示されます。ユーザーは必要な暗号化方式をリストから選択できます。 

デフォルト: ネットレット管理コンソールで指定するデフォルト VM ネイティブ暗号化方式と、デフォルト Java プラグイン暗号化方式。 

リモートアプリケーションの URL 

URL ユーザーがネットレットプロバイダのリンクをクリックしたときにブラウザで開かれる URL を指定します。ブラウザにはアプリケーションのウィンドウが表示され、ルールによって指定されたローカルポート番号で localhost に接続します。

相対 URL を指定する必要があります。 

ネットレットルールによって呼び出されるアプリケーションへの URL。たとえば、telnet://localhost:30000 などです。

アプリケーションの呼び出しにアプレットが必要な場合は、その URL を指定します。 

null : 指定した URL によってアプリケーションが起動されない、またはデスクトップで制御されない場合に設定する値。通常は Web ベース以外のアプリケーションで使用されます。

ダウンロードアプレットの有効化 

このルールでアプレットのダウンロードが必要であるかどうかを指定します。 

  • Client Port はクライアントの接続先ポートを表します。このポートは、デフォルトのループバックポートとは異なる必要があります。各ルールに一意の local port を指定します。

  • Server Host はアプレットのダウンロード元のサーバー名を表します。

  • Server Port はアプレットのダウンロードに使用されるサーバー上のポートを表します。

    アプレットがダウンロードされる場合にサーバーが指定されていないときは、アプレットは Portal Server のホストからダウンロードされます。

拡張セッションを有効 

ネットレットがアクティブの場合、Portal Server セッションのアイドル時間のタイムアウトを制御します。 

ネットレットだけがアクティブで、ほかのポータルアプリケーションがアイドル状態の場合にポータルセッションを持続する場合は、このチェックボックスにチェックマークを付けます。デフォルトでは、このオプションは選択されていません。 

ローカルポートと宛先サーバーポートのマップ 

ローカルポート 

ネットレットが待機するクライアントのポート。 

local-port の値は一意である必要があります。特定のポート番号を複数のルールに指定することはできません。

複数のローカルポートを指定するのは、複数の接続に複数のホストを指定している場合です。構文については、「複数ホスト接続のスタティックルール」を参照してください。

FTP ルールでは、ローカルポートは 30021 である必要があります。 

接続先ホスト 

ネットレットが待機するクライアントのポート。 

ネットレット接続の受信者。 

host : ネットレット接続を受信するホスト名。これはスタティックルールで使用されます。siroe などの簡易ホスト名、または siroe.mycompany.com などの完全修飾 DNS 形式のホスト名を指定します。次の場合に複数のホストを指定します。

local-port の値は一意である必要があります。特定のポート番号を複数のルールに指定することはできません。

複数のローカルポートを指定するのは、複数の接続に複数のホストを指定している場合です。構文については、「複数ホスト接続のスタティックルール」を参照してください。

FTP ルールでは、ローカルポートは 30021 である必要があります。 

指定された各ホストとの接続を確立する場合。指定された各ホストに対して、対応するクライアントと接続先ポートを指定する必要があります。構文については、「複数ホスト接続のスタティックルール」を参照してください。

指定されたホストのリストから、使用可能なホストへの接続を試みる場合。構文については、「複数ホストを選択するスタティックルール」を参照してください。

TARGET : 構文で TARGET を指定するルールはダイナミックルールです。TARGET は、デスクトップのネットレットプロバイダで、必要な接続先ホストをユーザーが 1 つ以上指定できることを示します。

1 つのルールでスタティックホストと TARGET を組み合わせることはできません。 

接続先ポート 

接続先ホスト上のポート。 

ホストと接続先ホストのほかに、接続先ポートを指定する必要があります。 

複数の接続先ホストがある場合は、複数の接続先ポートを指定できます。複数のポートは、port1+port2+port3-port4+port5 のように指定します。

ポート番号間のプラス (+) 記号は、単一の接続先ホストに対する代替ポートを表します。 

異なる接続先ホストのポート番号を区切るときは、区切り文字としてポート番号間にマイナス (-) 記号を挿入します。 

この例では、ネットレットは port1、port2、および port3 を順番に使用して、指定された最初の接続先ホストへの接続を試みます。これに失敗した場合、ネットレットは port4 と port5 をこの順序で使用して 2 番目のホストへの接続を試みます。

複数のポートは、スタティックルールでのみ設定できます。 

ゲートウェイが Portal Server からセッション通知を受け取るようにするには、次の情報を

com.iplanet.am.jassproxy.trustAllServerCerts=true

Portal Server 上の次のプロパティーファイルに追加します。

/etc/opt/SUNWam/config/AMConfig.instance-name .properties

ルールのタイプ

ルールで接続先ホストがどのように指定されているかにより、ネットレットルールは 2 つのタイプに分かれます。

スタティックルール

スタティックルールは、ルールの一部として接続先ホストを指定します。スタティックルールを作成する場合、ユーザーは必要な接続先ホストを指定することができません。次の例では、sesta は接続先ホストです。

ルール名 

暗号化方式 

URL 

ダウンロードアプレットの有効化 

拡張セッションを有効 

ローカルポートと宛先サーバーポートのマップ 

ftpstatic 

SSL_RSA_WITH_RC 4_128_MD5

null 

false 

true 

  • ローカルポート 30021

  • 接続先ホスト: sesta

  • 接続先ポート: 21

複数の接続先ホストおよびポートを設定できるのは、スタティックルールだけです。設定例については、「複数ホスト接続のスタティックルール」を参照してください。

ダイナミックルール

ダイナミックルールでは、接続先ホストはルールの一部として指定されません。ユーザーはネットレットプロバイダで必要な接続先ホストを指定できます。次の例では、TARGET は接続先ホストの可変部分です。

ルール名 

暗号化方式 

リモートアプリケーションの URL 

ダウンロードアプレットの有効化 

拡張セッションを有効 

ローカルポートと宛先サーバーポートのマップ 

ftpdynamic 

SSL_RSA_WIT H_RC4_128_MD5

null 

チェックボックスにチェックマークを付ける 

チェックボックスにチェックマークを付ける 

  • ローカルポート 30021

  • 接続先ホスト: TARGET

  • 接続先ポート: 21

暗号化方式

暗号化方式に基づいて、ネットレットルールはさらに次のように分類されます。

ルール名 

暗号化方式 

リモートアプリケーションの URL 

ダウンロードアプレットの有効化 

拡張セッションを有効 

ローカルポートと宛先サーバーポートのマップ 

Telnet 

SSL_RSA_WITH_RC4 _128_SHA

null 

チェックボックスにチェックマークを付ける 

チェックボックスにチェックマークを付ける 

  • ローカルポート 30000

  • 接続先ホスト: TARGET

  • 接続先ポート: 23
 

SSL_RSA_WITH_RC4 _128_MD5

       

注 –

Portal Server ではさまざまな暗号化方式が有効になっている場合がありますが、ユーザーが選択できる暗号化方式は、ネットレットルールの一部として設定されている方式だけです。

ネットレットでサポートされる暗号化方式のリストについては、「サポートされる暗号化方式」を参照してください。

ルール名 

暗号化方式 

リモートアプリケーションの URL 

ダウンロードアプレットの有効化 

拡張セッションを有効 

ローカルポートと宛先サーバーポートのマップ 

Telnet 

SSL_RSA_WITH_RC4_128_MD5

null 

チェックボックスにチェックマークを付ける 

チェックボックスにチェックマークを付ける 

  • ローカルポート 30000

  • 接続先ホスト: TARGET

  • 接続先ポート: 23

ネットレットでサポートされる暗号化方式のリストについては、「サポートされる暗号化方式」を参照してください。

サポートされる暗号化方式

「サポートされる暗号化方式」は、ネットレットでサポートされる暗号化方式のリストを示しています。

表 6–2 サポートされる暗号化方式のリスト

暗号化方式 

ネイティブ VM 暗号化方式

KSSL_SSL3_RSA_WITH_3DES_EDE_CBC_SHA 

KSSL_SSL3_RSA_WITH_RC4_128_MD5 

KSSL_SSL3_RSA_WITH_RC4_128_SHA 

KSSL_SSL3_RSA_EXPORT_WITH_RC4_40_MD5 

KSSL_SSL3_RSA_WITH_DES_CBC_SHA 

Java プラグイン暗号化方式

SSL_RSA_WITH_3DES_EDE_CBC_SHA 

SSL_RSA_WITH_RC4_128_MD5 

SSL_RSA_WITH_RC4_128_SHA 

SSL_RSA_EXPORT_WITH_RC4_40_MD5 

SSL_RSA_WITH_DES_CBC_SHA 

SSL_RSA_WITH_NULL_MD5 

TLS_RSA_WITH_AES_128_CBC_SHA 

TLS_RSA_WITH_AES_256_CBC_SHA 

下位互換性

旧バージョンの Portal Server は、ネットレットルールの一部として暗号化方式をサポートしていません。暗号化方式を使用せずに既存のルールと下位互換を行うには、ルールでデフォルトの暗号化方式を指定します。暗号化方式を使用しない既存のルールは、次のとおりです。

ルール名 

暗号化方式 

リモートアプリケーションの URL 

ダウンロードアプレットの有効化 

拡張セッションを有効 

ローカルポートと宛先サーバーポートのマップ 

Telnet 

 

telnet://localhost:30000

チェックボックスにチェックマークを付けない 

チェックボックスにチェックマークを付ける 

  • ローカルポート 30000

  • 接続先ホスト: TARGET

  • 接続先ポート: 23

これは次のように解釈されます。

ルール名 

暗号化方式 

リモートアプリケーションの URL 

ダウンロードアプレットの有効化 

拡張セッションを有効 

ローカルポートと宛先サーバーポートのマップ 

Telnet 

デフォルト暗号化方式 

telnet://localhost:30000

チェックボックスにチェックマークを付けない 

チェックボックスにチェックマークを付ける 

  • ローカルポート 30000

  • 接続先ホスト: TARGET

  • 接続先ポート: 23

これは、管理者設定ルールでデフォルトとして選択した「暗号化方式」フィールドと同じです。

注 –

ネットレットルールには 64000 を超えるポート番号を指定できません。

ネットレットルールの例

ここでは、ネットレットルールの例をいくつか示し、ネットレット構文がどのように機能するかについて説明します。

基本的なスタティックルール

このルールは、クライアントマシンから sesta への Telnet 接続をサポートします。

ルール名 

暗号化方式 

リモートアプリケーションの URL 

アプレットのダウンロード 

拡張セッション 

ローカルポートと宛先サーバーポートのマップ 

myrule 

SSL_RSA_WITH_RC4_128_MD5

null 

チェックボックスにチェックマークを付けない 

true 

  • ローカルポート 1111

  • 接続先ホスト: sesta

  • 接続先ポート: 23

各表記の意味は次のとおりです。

myrule はルール名です。

SSL_RSA_WITH_RC4_128_MD5 は、適用される暗号化方式を示します。

null は、このアプリケーションが URL で呼び出されない、またはデスクトップから実行できないことを示します。

false は、クライアントがこのアプリケーションを実行するためにアプレットをダウンロードしないことを示します。

true は、ネットレット接続がアクティブになっても、Portal Server がタイムアウトにならないことを示します。

1111 は、ネットレットが接続先ホストからの接続要求を待機するクライアント側のポートです。

sesta は Telnet 接続の受信側ホストの名前です。

23 は接続先ホストの接続用ポート番号です。この例では、既知の Telnet ポートです。

デスクトップネットレットプロバイダにはリンクが表示されませんが、ネットレットは指定されたポート (1111) で自動的に起動して待機します。クライアントソフトウェア、この場合はポート 1111 で localhost に接続した Telnet セッションを開始するようにユーザーに指示してください。

たとえば、Telnet セッションを開始するには、クライアントは端末の UNIX コマンド行で次のコマンドを入力する必要があります。


telnet localhost 1111

複数ホスト接続のスタティックルール

このルールは、クライアントマシンから 2 台のマシン sesta および siroe への Telnet 接続をサポートします。

ルール名 

暗号化方式 

リモートアプリケーションの URL 

ダウンロードアプレットの有効化 

拡張セッションを有効 

ローカルポートと宛先サーバーポートのマップ 

myrule 

SSL_RSA_WITH_RC4_128_MD5

null 

チェックボックスにチェックマークを付けない 

チェックボックスにチェックマークを付ける 

  • ローカルポート: 1111 〜 1234

  • 接続先ホスト: sesta-siroe

  • 接続先ポート: 23

各表記の意味は次のとおりです。

23 は接続先ホストの接続用ポート番号、つまり、Telnet の予約ポートです。

1111 は、ネットレットが最初の接続先ホスト siroe からの接続要求を待機するクライアント側のポートです。

1234 は、ネットレットが 2 番目の接続先ホスト siroe からの接続要求を待機するクライアント側のポートです。

このルールの最初の 6 つのフィールドは、「基本的なスタティックルール」と同じです。2 番目の接続先ホストを識別するためのフィールドが 3 つ追加されている点が異なります。

ルールにターゲットを追加するときは、新しい接続先ホストごとに、local port、destination host、destination port の 3 つのフィールドを追加する必要があります。

注 –

各接続先ホストへの接続を、3 つのフィールドのセットを使って記述することができます。2048 未満の待機ポート番号は、UNIX ベースのリモートクライアントでは使用できません。UNIX は下位数値のポートに制約され、root でリスナーを開始する必要があるためです。

このルールは前述のルールと同様に機能します。ネットレットプロバイダはリンクを表示しませんが、ネットレットは指定された 2 つのポート (1111 と 1234) で自動的に起動して待機します。ユーザーはクライアントソフトウェア、この場合は、ホストに接続するために localhost のポート 1111 に対して Telnet セッションを、2 番目のホストに接続するには、localhost のポート 1234 に対して Telnet セッションを開始する必要があります。

複数ホストを選択するスタティックルール

このルールは、複数の代替ホストを指定する場合に使用します。ルールの最初のホストへの接続に失敗した場合、ネットレットは 2 番目に指定されたホストへの接続を試み、成功するまで指定の順に代替ホストへの接続を試みます。

ルール名 

暗号化方式 

リモートアプリケーションの URL 

ダウンロードアプレットの有効化 

拡張セッションを有効 

ローカルポートと宛先サーバーポートのマップ 

gojoe 

SSL_RSA_WITH_RC4_128_MD5

/gojoe.html 

  • クライアントポート: 8000

  • サーバーホスト: gojoeserver

  • サーバーポート: 8080

チェックボックスにチェックマークを付ける 

  • ローカルポート 10491

  • 接続先ホスト: siroe+sesta

  • 接続先ポート: 35+26+491-35+491

各表記の意味は次のとおりです。

10491 は、ネットレットが接続先ホストからの接続要求を待機するクライアント側のポートです。

ネットレットはポート 35、ポート 26、ポート 491 の順に使用可能なポートにアクセスし、siroe との接続を確立しようと試みます。

siroe との接続が確立できない場合、ネットレットはポート 35、491 の順序で sesta への接続を試みます。

ホスト間のプラス (+) 記号は代替ホストを表します。

ポート番号間のプラス (+) 記号は、単一の接続先ホストに対する代替ポートを表します。

異なる接続先ホストのポート番号を区切るときは、区切り文字としてポート番号間にマイナス (-) 記号を挿入します。

注 –

指定された一連のホストへの接続が順次に試行されます。たとえば、siroe+sesta が指定されたルールの場合、最初に siroe への接続が試行されます。この接続に失敗すると、次に sesta への接続が試行されます。ルール内で最初にリストされたホストがアクティブネットワーク内で物理的に使用できない場合、ルール内の使用不能ホストの数が多いほど、次の使用可能ホストへの接続にかかる時間が長くなります。

URL を呼び出すダイナミックルール

このルールを使用することで、目的の接続先ホストを設定できるため、ネットレットを使用してさまざまなホストへの Telnet 接続を確立できます。

ルール名 

暗号化方式 

リモートアプリケーションの URL 

ダウンロードアプレットの有効化 

拡張セッションを有効 

ローカルポートと宛先サーバーポートのマップ 

myrule 

SSL_RSA_WITH_RC4_128_MD5

telnet://localhost:30000 

チェックボックスにチェックマークを付けない 

チェックボックスにチェックマークを付ける 

  • ローカルポート 30000

  • 接続先ホスト: TARGET

  • 接続先ポート: 23

各表記の意味は次のとおりです。

myrule はルール名です。

SSL_RSA_WITH_RC4_128_MD5 は、適用される暗号化方式を示します。

telnet://localhost:30000 はルールで呼び出される URL です。

false はアプレットがダウンロードされないことを示します。

true は、ネットレット接続がアクティブになっても、Portal Server がタイムアウトにならないことを示します。

30000 は、ネットレットがこのルールの接続要求を待機するクライアント上のポートです。

TARGET は、ユーザーがネットレットプロバイダを使用して接続先ホストを設定する必要があることを示します。

23 はネットレットで開かれる接続先ホストのポートです。この例では、既知の Telnet ポートです。

Procedureルールの追加後にネットレットを実行する

このルールを追加したあとに、ユーザーはネットレットを目的どおりに稼動させるためにいくつかの手順を実行しなければなりません。ユーザーはクライアント側で次の操作を実行する必要があります。

  1. 標準の Portal Server デスクトップのネットレットプロバイダセクションで、「編集」をクリックします。

    新しいネットレットルールが、「新しいターゲットの追加」セクションの「ルール名」に表示されます。

  2. ルール名を選択し、接続先ホスト名を入力します。

  3. 変更を保存します。

    デスクトップに戻ります。デスクトップのネットレットプロバイダセクションに新しいリンクが表示されます。

  4. 新しいリンクをクリックします。

    新しいブラウザが起動し、ネットレットルールで指定した URL が表示されます。

    注 –

    同じルールに複数の接続先ホストを追加する場合は、この手順を繰り返します。選択された最後のリンクのみがアクティブです。

アプレットをダウンロードするダイナミックルール

このルールは、ダイナミックに割り当てられたホストとクライアント間の接続を定義します。このルールにより、アプレットのあるサーバーからクライアントに GO-Joe アプレットがダウンロードされます。

ルール名 

暗号化方式 

リモートアプリケーションの URL 

ダウンロードアプレットの有効化 

拡張セッション 

ローカルポートと宛先サーバーポートのマップ 

gojoe 

SSL_RSA_WITH_RC4_128_MD5

/gojoe.html 

  • クライアントポート: 8000

  • サーバーホスト: gojoeserver

  • サーバーポート: 8080

チェックボックスにチェックマークを付ける 

  • ローカルポート 3399

  • 接続先ホスト: TARGET

  • 接続先ポート: 58

各表記の意味は次のとおりです。

gojoe はルール名です。

SSL_RSA_WITH_RC4_128_MD5 は、適用される暗号化方式を示します。

/gojoe.html は、たとえば、アプレットを含む HTML ページのパスや、ポータルが配備されている Web コンテナのドキュメントルートへの相対パスです。

8000:gojoeserver:8080 は、クライアントでアプレットを受け取る接続先ポートがポート 8000 であることを示します。gojoeserve はアプレットを送るサーバー名、8080 はアプレットのダウンロード元のサーバー上のポートです。

Extended Session (true) は、ネットレット接続がアクティブになっても、Portal Server がタイムアウトにならないことを示します。

3399 は、ネットレットがこのタイプの接続要求を待機するクライアント上のポートです。

TARGET は、ユーザーがネットレットプロバイダを使用して接続先ホストを設定する必要があることを示します。

58 はネットレットで開かれる接続先サーバーのポートです。この例では、GoJoe のポートです。ポート 58 は接続先ホストが自分のトラフィックを待機するポートです。ネットレットは新しいアプレットの情報をこのポートに渡します。

ネットレットルールの例

「ネットレットルールの例」は、いくつかの一般的なアプリケーションのネットレットルールの例を示しています。

この表には、ネットレットルールごとに 7 項目あり、それぞれ、「ルール名」、「リモートアプリケーションの URL」、「ダウンロードアプレットの有効化」、「ローカルポート」、「接続先ホスト」、「接続先ポート」の各フィールドに対応しています。最後の列は、ルールの説明を示します。

注 –

「ネットレットルールの例」には、ネットレットルールの暗号化方式および拡張セッションのフィールドは示されていません。それぞれが「SSL_RSA_WITH_RC4_128_MD5」および「true」に設定されていることを前提としています。

表 6–3 ネットレットルールの例

ルール名 

リモートアプリケーションの URL 

ダウンロードアプレットの有効化 

ローカルポートと宛先サーバーポートのマップ 

説明 

IMAP

null 

チェックボックスにチェックマークを付けない 

  • ローカルポート 10143

  • 接続先ホスト: imapserver

  • 接続先ポート: 143

クライアント側のネットレット local port はサーバー側の destination port と同じである必要はありません。標準の IMAP と SMTP ポート以外を使用する場合は、標準ポートと異なるポートにクライアントが設定されていることを確認します。

Solaris クライアントユーザーは、root で実行している場合を除き、1024 未満のポート番号には接続できません。 

SMTP

null 

チェックボックスにチェックマークを付けない 

  • ローカルポート 10025

  • 接続先ホスト: smtpserver

  • 接続先ポート: 25

 

Lotus Web クライアント

null 

チェックボックスにチェックマークを付けない 

  • ローカルポート 80

  • 接続先ホスト: lotus-server

  • 接続先ポート: 80

このルールでは、ネットレットがポート 80 でクライアントを待機し、ポート 80 でサーバー lotus-server に接続します。Lotus Web クライアント側で、待機するポートがサーバーポートと一致している必要があります。 

Lotus Notes 非 Web クライアント

null 

チェックボックスにチェックマークを付けない 

  • ローカルポート 1352

  • 接続先ホスト: lotus-domino

  • 接続先ポート: 1352

このルールを使用すると、Lotus Notes クライアントはネットレットを通じて Lotus Domino サーバーに接続できます。クライアントがサーバーに接続する場合、サーバー名に localhost が指定されていないことを確認してください。これは、Lotus Domino サーバーの実際のサーバー名を指定する必要があります。サーバー名は、サーバーのシステム名と同じでなければなりません。ネットレットを使用する場合、クライアントはその名前を 127.0.0.1 として解決する必要があります。その方法には次の 2 種類があります。

  • クライアントホストテーブルで、127.0.0.1 をポイントするようにサーバー名を設定します。

  • 127.0.0.1 をポイントするサーバー名の DNS エントリをエクスポートします。

    サーバー名は、設定時に Domino サーバーの設定に使用したサーバー名と同じ名前である必要があります。

Microsoft Outlook および Exchange Server

Windows NT、Windows 2000、および Windows XP では、この設定は機能しません。Windows NT、2000、および XP については、リライタ経由で Outlook Web Access を使用してください。

null 

チェックボックスにチェックマークを付けない 

  • ローカルポート 135

  • 接続先ホスト: exchange

  • 接続先ポート: 135

このルールでは、ネットレットがクライアントのポート 135 で待機し、ポート 135 のサーバー exchange に接続します。Outlook クライアントはこのポートを使用して、Exchange サーバーへの最初の接続試行を行い、失敗した場合は指定されている代替ポートを順に使用してサーバーと通信します。

クライアントマシン上で次の操作を行います。 

  • ユーザーは Outlook クライアントに設定されている Exchange サーバーのホスト名を localhost に変更する必要があります。このオプションの場所は、Outlook のバージョンによって異なります。

  • ユーザーはホストファイルを使用して、Exchange サーバーのホスト名 (単一の完全修飾名) を IP アドレス 127.0.0.1 にマップする必要があります。

  • Windows 95 または 98 では、このファイルは \\Windows\\Hosts に格納されています。

  • Windows NT4 では、このファイルは \\WinNT\\System32\\drivers\\etc\\Hosts に格納されています。

    エントリは次のようになります。

    127.0.0.1 exchange exchange.company.com

    Exchange サーバーは、それ自体の名前を Outlook クライアントに返します。このマッピングにより、Outlook クライアントはネットレットクライアントを使用して元のサーバーに接続できるようになります。

FTP

null 

チェックボックスにチェックマークを付けない 

  • ローカルポート 30021

  • 接続先ホスト: your-ftp_server.your-domain

  • 接続先ポート: 21

単一の FTP サーバーへの FTP サービスに、制御対象エンドユーザーアカウントを提供できます。これにより、エンドユーザーシステムから単一の場所へのセキュリティー保護されたリモート FTP 転送が保証されます。ユーザー名を使用しない場合、FTP の URL は匿名の FTP 接続として解釈されます。 

ネットレット FTP ルールのローカルポートとして、ポート 30021 を定義する必要があります。

ネットレット接続でダイナミック FTP を使用できます。 

Netscape 4.7 Mail Client

null 

チェックボックスにチェックマークを付けない 

  • ローカルポート 30143、30025

  • 接続先ホスト: TARGET

  • 接続先ポート: 10143

Netscape クライアントでは、ユーザーは次のコマンドを指定する必要があります。 

IMAP または受信メールについては localhost:30143

SMTP または発信メールについては localhost:30025

Graphon 

third_party/xsession_start.html 

チェックボックスにチェックマークを付ける 

  • ローカルポート 10491

  • 接続先ホスト: TARGET

  • 接続先ポート: 491

ネットレットを通じて Graphon にアクセスするためのルール。xsession_start.html は Graphon にバンドルされています。

Citrix 

third_party/citrix_start.html 

チェックボックスにチェックマークを付ける 

  • ローカルポート 1494

  • 接続先ホスト: TARGET

  • 接続先ポート: 1494

ネットレットを通じて Citrix にアクセスするためのルール。citrix_start.html は Citrix にバンドルされています。

Remote Control 

third_party/pca_start.html 

チェックボックスにチェックマークを付ける 

  • ローカルポート 5631

    5632

  • 接続先ホスト: TARGET

    TARGET

  • 接続先ポート: 5631

    5632

ネットレットを通じて Remote Control にアクセスするためのルール。pca_start.html は Remote Control にバンドルされています。

ネットレットのログ情報

ネットレットアプレットまたは jws のクライアント側ログは、クライアントの Java コンソールに表示されます。

ネットレットのサーバー側ログは、/var/opt/SUNWportal/portals/<portal_ID>/logs/<INSTANCE_ID> ディレクトリの下にある portal.0.0.log ファイルに表示されます。

Sun Ray 環境でのネットレットの実行

Sun Ray 環境のクライアントマシンでアプレットをダウンロードする必要があるアプリケーションを実行するときは、HTML ファイルを変更する必要があります。次に、必要な変更を加えたファイルの例を示します。

新しい HTML ファイル

<!-- @(#)citrix_start.html 2.1
98/08/17 Copyright (c) 1998 i-Planet, Inc., All rights reserved.-->
<html>
<script language="JavaScript">
var KEY_VALUES;  // KEY_VALUES[\qkey\q] = \qvalue\q;
function retrieveKeyValues() {
      KEY_VALUES = new Object();
      var queryString  = \q\q + this.location;
      queryString = unescape(queryString);
      queryString = queryString.substring((queryString.indexOf(\q?\q)) + 1);
      if (queryString.length < 1) {
          return false; }
      var keypairs = new Object();
      var numKP = 0;
      while (queryString.indexOf(\q&\q) > -1) {
        keypairs[numKP] = queryString.substring(0,queryString.indexOf(\q&\q));
        queryString = queryString.substring((queryString.indexOf(\q&\q)) + 1);
        numKP++;
      }
      // クエリー文字列に最後の keypairs[] データとして残されている内容を格納します。
      keypairs[numKP++] = queryString;
      var keyName;
      var keyValue;
      for (var i=0; i < numKP; ++i) {
        keyName = keypairs[i].substring(0,keypairs[i].indexOf(\q=\q));
        keyValue = keypairs[i].substring((keypairs[i].indexOf(\q=\q)) + 1);
        while (keyValue.indexOf(\q+\q) > -1) {
          keyValue = keyValue.substring(0,keyValue.indexOf(\q+\q)) + \q \q
           + keyValue.substring(keyValue.indexOf(\q+\q) + 1);

        }
        keyValue = unescape(keyValue);
          // 英数字以外のエスケープを解除します。
        KEY_VALUES[keyName] = keyValue;
      }
}
function getClientPort(serverPort) {
    var keyName = "clientPort[\q" + serverPort +"\q]";
    return KEY_VALUES[keyName];
}
function generateContent() {
    retrieveKeyValues();
    var newContent =
        "<html>\\n"
          + "<head></head>\\n"
          + "<body>\\n"
          + "<applet code=\\"com.citrix.JICA.class\\" archive=\\
               "JICAEngN.jar\\" width=800 height=600>\\n"
          + "<param name=\\"cabbase\\" value=\\"JICAEngM.cab\\">\\n"
          + "<param name=\\"address\\" value=\\"localhost\\">\\n"
          + "<param name=ICAPortNumber value="
          + getClientPort(\q1494\q)
          + ">\\n"
          + "</applet>\\n"
          + "</body>\\n"
          + "</html>\\n";
    document.write(newContent);
}
</script>
<body onLoad="generateContent();">
</body>
</html>

変更前の HTML ファイル

<html>
<body>
<applet code="com.citrix.JICA.class" archive=
   "JICAEngN.jar" width=800 height=600>
<param name="cabbase" value="JICAEngM.cab">
<param name="address" value="localhost">
<param name=ICAPortNumber value=1494>
</applet>
</body></html>