2 Webアプリケーション・テンプレートの
構成と診断

この章では、特定のサインオン・シナリオを解決するためにWebアプリケーション・テンプレートを構成する方法と理由の理解に必要な概念について説明し、この章の後で記述しているように、Windowsアプリケーション・フォームを構成およびテストする手順の推奨されるベスト・プラクティスについて、およびエージェントのWebフォームに対する検出や応答が不安定になる可能性がある最も一般的な問題の診断と解決手順についても説明します。

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

• サインオン・イベントの概要

• Webフォームの検出の理解

• フォームのレスポンスの理解

• フォームの最適な構成の確認

• フォームの構成

• フォームの構成のテスト

• リポジトリへのテンプレートの公開

• Webフォームの検出のトラブルシューティング

• コントロールIDを使用する場合のフォームのレスポンスのトラブルシューティング

• SendKeysを使用する場合のフォームのレスポンスのトラブルシューティング

• 検出マッチングのトラブルシューティング

• ログオン・ループのトラブルシューティング

• Javaアプリケーションの問題のトラブルシューティング

ヒント: この章の手順で問題を解決できない場合は、Logon Managerのアクティビティの追跡とロギングを行い、記録された情報を分析のためにOracleサポートに送信することによって、さらにトラブルシューティングを行うことができます。このために、Oracleではトレース・コントローラ・ユーティリティ(Oracleサポートから入手可能)を提供しています。ユーティリティの使用方法の詳細は、『Enterprise Single Sign-On Suite管理者ガイド』のトレース・コントローラ・ユーティリティの使用に関する説明を参照してください。

2.1 サインオン・イベントの概要

ログオン、パスワード変更およびその他の多様なサインオン・イベントを、Logon Managerで検出して応答するように構成することができ、様々なフォーム、フィールド、コントロールおよびイベント・フローがサポートされています。

Webフォームを認識するために、Logon Managerは実行中のWebブラウザを監視し、ブラウザにWebページのロードが完了したらすぐに検出します。

完全にロードされたページごとに、Logon Managerは次の手順を実行します。

1. ターゲットWebページおよびフォームを検出します。監視しているブラウザを介して新しいURLがアクセスされると、Logon Managerは次の手順を実行します。

   1. ページURLを調べて、使用可能なすべてのWebアプリケーション・テンプレート内に格納されているURLと比較します。

   2. 検出したURLと一致する最初のテンプレートをロードします。

   3. ページのDocument Object Model (DOM)を調べ、フォーム定義で構成されている各フィールドおよびコントロールを識別します。

   4. (オプション)ページのソース・コードを調べ、フォーム定義に追加のマッチングが構成されている場合はそれを実行します。

2. エージェントがフォームに応答し、ログオンを完了します。検出が完了してポジティブ・マッチが検索されると、エージェントはテンプレートに格納されている構成に従って、フォームのフィールドおよびコントロールとの対話方法を判断します。通常、エージェントは次の手順を実行します。

   1. ユーザーのストアから関連する資格証明(存在する場合)を取得し、該当するフィールドに注入します。(資格証明が存在しない場合、エージェントはユーザーに格納するよう求めます。)

   2. 資格証明をアプリケーションに送信して処理するために必要なアクションを実行します。

   3. (オプション)ログオンまたはパスワード変更の成功または失敗メッセージなど、補足情報のフォームを検出し、必要なアクションを実行します。

2.2 Webフォームの検出の理解

ブラウザに接続され、ブラウザにデータを問い合せる手段(ページURL、DOMおよびHTMLソースなど)をLogon Managerに提供し、また、資格証明をターゲット・フィールドに注入して検出の成功時にそれらを送信するヘルパー・オブジェクトを、Logon Managerは、インストール済Webブラウザと通信するために使用します。

ヘルパー・オブジェクトは、次のバックグラウンド・プロセスとして実行されます。

• Microsoft Internet Explorerの場合: SSOBHO.EXE

• Mozilla Firefoxの場合: SSOWEBHO.EXE

Webブラウザがページのロードを完了すると、それぞれのヘルパー・オブジェクトがこのイベントをLogon Managerに通知し、500ミリ秒の猶予期間タイマーが開始します。この猶予期間中、次のいずれかが発生します。

• 現在のページがリフレッシュされていない場合、または別のページがロードを開始していない場合、Logon Managerが検出を開始します。

• 現在のページがリフレッシュされている場合、または別のページがロードを開始している場合、Logon Managerはタイマーを再開し、ページがロードを終了するまで待機してから検出を開始します。

注意: 検出が開始された後に、ページがリフレッシュされている場合、または別のページがロードを開始している場合、Logon Managerは検出を中断し、そのページがロードを終了するのを待機してから、500ミリ秒の猶予期間タイマーを開始し、前述のように経過を待機します。

通常、ブラウザのステータス・バーは、ブラウザ・ウィンドウの下にあり、「Done」または「Finished」などの適切なメッセージを表示することによって、ページのロードが完了したことを示します。

検出が開始されると、Logon Managerは、使用可能なテンプレートと比較して、次のようなページの特性を調べます。

• URL

• ターゲット・フィールドおよびコントロール

• (オプション)ターゲット・フォームのテンプレートに構成されている、追加のマッチング基準(テキスト、HTMLコードおよび要素の属性など)。

  
  

  注意: アプリケーション・テンプレートは、ログオンを正常に完了させるために、Webアプリケーション・フォームの検出方法およびWebアプリケーション・フォームに対するレスポンス方法を、Logon Managerエージェントに指示するための一連の構成オプションです。 次に示す状況では、WebアプリケーションではなくWindowsアプリケーションとして、アプリケーションを構成する必要があることに注意してください。

  
  

• Internet Explorerを使用しており、ターゲット・フォームはActiveXコントロールとして実装されています。

• Mozilla Firefoxを使用しており、ターゲット・フォームはブラウザの組込み認証ダイアログを使用して表示されています。

詳細は、「構成と診断(Windowsアプリケーション・テンプレート)」を参照してください。

2.2.1 サポート対象のフォーム・タイプ

このドキュメントのリリース時点で、Logon Managerは次のタイプのフォームをWebアプリケーションでサポートします。

• ログオン

• ログオン成功(ログオンの成功を示すメッセージ)

• ログオン失敗(注入された資格証明が拒否されたことを示すメッセージ)

• パスワード変更

• パスワード変更の成功(パスワード変更の成功を示すメッセージ)

• パスワード変更の失敗(新しいパスワードが拒否されたことを示すメッセージ)

1つのテンプレートに、Webアプリケーションが表示できる複数のフォームの定義を含めることができます。ほとんどのアプリケーションの場合、定義する必要があるのは、Logon Managerで応答するフォームのみです。

注意: フォームを定義することで一意の識別基準ができ、そのフォームが検出されたときにとるアクションおよびそのアクションで実行する必要がある特定の動作(資格証明の注入など)が指定されます。

Logon Managerは、ユーザーの資格証明ストアから自動的に、資格証明を取得してそれをフォーム内の適切なフィールドに移入することができるだけでなく、フォームのコントロールを操作して、アプリケーションに資格証明を送信して処理することもできます。フォームのフィールドおよびコントロールとの対話方法をエージェントに指定する構成オプションは、テンプレートに格納されています。

2.2.2 URL検出の理解

Logon ManagerがWebフォームの検出中に考慮する最初の基準は、Webアドレス、つまりターゲット・ページのURLです。これは通常、ページのロードが終了したときにブラウザのアドレス・バーに表示されるアドレスですが、特定のシナリオでは、フォーム定義に指定する必要がある実際のURLは、ログオン・フィールドおよびコントロールが実際に含まれているコンテナまたはフォーム要素など(これらの用語については次の項で説明します)、ページの要素のURLである場合があります。

ページURLは、次のような構造です。

Webアプリケーションをデプロイした方法に応じて、URLは静的になることも部分的に動的になることもあります。たとえば、単純なWebアプリケーションは単一のWebサーバーにデプロイされ、前述の例のように静的なホスト名を持ち単一のHTMLページとして存在します。このような場合、このURLと一致するようにフォーム定義を構成し、作業用テンプレートを利用できます。

一方で、多くのエンタープライズWebアプリケーションは、ロード・バランシングまたはクラスタ化された複数のサーバーにデプロイされ、個別のインスタンスURLは単一のエントリURLの背後にマスキングされます。

たとえば、Webアプリケーションにアクセスするために使用するURLは単に次のようになります

ロード・バランシングされた個別のインスタンスへの実際のURLは次のようになります

ほとんどのエンタープライズWebアプリケーションでは、ブラウザとWebサーバーまたはデータベース(あるいはその両方)とのデータの受渡しに、JavaScriptやPHPなどのアクティブ・スクリプティング技術が採用されています。そのようなアプリケーションでは、一意のセッションIDなど、1つ以上の動的パラメータまたは変数がページURLに採用されます。

例:

一部のアプリケーションでは、変数区切り記号(通常はアンパサンド(&))で区切ってURL変数を並べます。

ほとんどのエンタープライズWebアプリケーションのシナリオでは、動的ホスト名と動的パラメータの組合せが使用されており、フォーム定義を正常に構成するにはそれらの両方を考慮する必要があります。Logon Managerでは、正規表現を使用した動的URLに対するマッチングだけでなく、すべてのWebアプリケーションに対してLogon Managerが使用するURL一致精度を決定する、グローバル・エージェント設定も使用できます。

2.2.2.1 URL一致精度の理解

URL一致精度によって、検出中にページURL内のホストURLが、右から左に数えていくつのセグメントまで考慮されるかが決まります。

たとえば、デフォルト精度レベル2で、ホスト名URLおよびアプリケーションURLが次の場合:

この場合、前述のホストURLだけでなく、次に示す個別にホストされるアプリケーションのインスタンスのURLがテンプレートのポジティブ・マッチになります。

これは、ホストURLの最後のセグメントを次のようにマスキングしたものと同等です。ワイルドカードを使用した場合:

または正規表現を使用した場合:

注意: URLのなかには、一般的な単一セグメントのTLD (.com、.netなど)ではなく、2つのセグメント(英国の.co.uk、オーストラリアの.co.auなど)からなるトップ・レベル・ドメイン(TLD)を含むものがあります。このような場合、URL一致精度やWebアプリケーション・テンプレートの構成時に、ホストURL内の追加のセグメントを考慮する必要があります。

URL一致精度を3に増やした場合、Logon ManagerはホストURLの3つの連続したセグメントに対して照合し、この例では、表示されているとおりのホスト名全体と照合します。

このためサーバー名のバリエーションは許可されず、テンプレート内に構成されている正確なホストURL以外は、検出中にLogon Managerに拒否されます。この例では、前述のWebアプリケーションの個別インスタンスのURLは、ポジティブ・マッチではありません。

ご使用の環境に最適なURL一致精度判断する場合は、次のガイドラインに従ってください。

• URL一致精度の設定が低すぎると、Logon Managerは、あるイントラネット・アプリケーションを別のものと間違えて、間違った資格証明で応答する可能性があります。

• URL一致精度の設定が高すぎると、一意のホスト名を持つ配布済インフラストラクチャを介して提供された1つのアプリケーションが、可変ホストURLのために別々のアプリケーションとして誤って認識される可能性があります。

• 通常は、URL一致精度を5(最大値)に設定します。これによって、ログオンをリクエストしているアプリケーションのURLがテンプレートに格納されたURLと厳密に一致する場合のみLogon Managerが応答することが保証されます。自動認識機能には、限定された機能が搭載される予定です。

• Logon ManagerのWebアプリケーション用自動認識機能のメリットを最大限に利用するには、URL一致精度をデフォルト値の2のままにします。ただし、イントラネット・アプリケーションへのレスポンスは低下する可能性があります。

Logon Managerでは、管理コンソールを介してURL一致精度レベルをグローバルに設定できます。オプションは、「Global Agent Settings」→「End-User Experience」 →「Response」→「Web Apps」の下にあります。エージェントの構成およびエンドユーザー・マシンへの変更の公開に関する詳細は、『Enterprise Single Sign-On Suite管理者ガイド』のLogon Managerの構成についての説明を参照してください。

2.2.2.2 ページ、要素またはポップアップのURLの取得

特定の状況では、ページのURLまたはページ内の要素のURLを容易に取得できない場合がありますが、テンプレート内のフォーム定義を完了するには必要です。たとえば、次のURLを取得する必要がある場合があります。

• WebページのURLとは異なるURLからロードする埋込みフォーム

• ブラウザとWebサーバーまたはデータベース(あるいはその両方)の間でデータを受け渡すログオン処理スクリプト

• イメージまたは埋込みマルチメディア・オブジェクト

• ポップアップ

このような場合、次の1つ以上の手順を実行して、目的のURLを取得します。

• ブラウザのアドレス・バーが表示されていない場合は、[F11]を押して表示します。

• オブジェクトまたはフォーム内を右クリックして、「Properties」を選択します。(「Properties」ダイアログでオブジェクトのURLがわかります)。

• ロードが完了したページのHTMLソース・コードを調べ、問題のオブジェクトを探します。

• 特にURLが部分的に動的な場合に、HTTPWatchやURL Getterなど第三者のツールを使用して、要素のURLを取得します。場合によっては、ページのソース・コードを表示すると、問題のオブジェクトの完全なURLを取得できます。

2.2.3 フィールド検出の理解

検出したURLがテンプレートに対して明確に一致した後、Logon Managerは、フォーム定義に構成されているフィールドを検出するためにページのDocument Object Model (DOM)を調べます。

各フィールドおよびコントロールについて、エージェントは次の名前または序数を確認します。

• 親フレーム要素

• 親フォーム要素

• ターゲット・フィールド要素

フィールドが正常に識別されるには、3つの値すべてがテンプレート内のフォーム定義に構成されている値と一致する必要があります。次の図および対応するコード例は、ログオン・フォームを含む単純なWebページの構造を示しています

注意: 今日のWebページの大多数では、コンテンツをさらに分割する際にフレームが使用されなくなりました。検出の目的で、Logon Managerは<html>コンテナをページ内のマスター・フレームとして処理し、序数値0で識別します。ほとんどの場合、この値を変更する必要はありません。

レンダリングされるページの要素の親子関係に対応する、階層的なネストされたコードの構造に注意してください。

注意: 前述の例の開始および終了タグの各ペアが要素であり、ページ内の機能エンティティ(たとえば、フレーム、フォーム、フィールドなど)を構成するコードの部分です。

テンプレート内でフォーム定義を手動で構成すると、Logon Managerへのフレーム、フォームおよびフィールド要素を次によって識別できます。

• 要素のname属性の値。または、これが指定されていない場合は、

• 序数。つまり、ページのDOMに表示される順序に応じて、サポート対象の各タイプの要素にLogon Managerによって割り当てられた索引番号。

2.2.3.1 HTML要素の理解

前の項で説明したように、HTMLの要素は、ページ内の機能エンティティ(たとえば、フレーム、フォーム、フィールドなど)を構成するコードの部分です。要素は、単一行のコード、つまり<input>などの単一タグの場合もあれば、<div>…</div>のように開始および終了タグとその2つのタグ間にあるすべてで構成されている場合があります。

たとえば、典型的な<input>要素は次のようになります。

要素の宣言(<input)の後のコードに注意してください(これらは要素の属性です)。各属性には、次の形式で名前および値があります。

二重引用符(インチ記号)は、属性値が認識されるために必要です。

2.2.3.2 フレーム要素の理解

フレームは、フレームセットを定義して、各フレームのサイズおよび表示するHTML文書を指定することによって、Webページを分割できるレガシー・コンテナです。今日の大多数のWebサイトでは、この技術が採用されなくなり、分割を達成するためのCSS形式と並行して<div>や<table>などのXHTML標準で定義された論理コンテナが使用されています。そのため、ほとんどのシナリオでLogon Managerは、<html>コンテナをフレーム0として識別し、ページ内のマスター(かつ唯一の)フレームとして処理します。

フィールドおよび検出マッチング・ルールを構成する際、フレーム識別子を変更する必要はありません。Webアプリケーションがレガシー・アプリケーションであり、明示的に要求される場合を除きます(たとえば、これが、スタンドアロンHTMLドキュメントとして存在し、親Webページ内のフレームに表示されるログオン・フォームを使用する場合)。このようなページは、DOMまたはソースを調べて、<frameset>タグで示されるフレームセット定義を探すことによって識別できます。フレームセット定義の例は、次のようになります。

フレームは、<frame>タグで識別できます。

2.2.3.3 フォーム要素の理解

<form>要素によってHTMLフォームが定義され、このフォームは1つ以上の入力フィールドを含む論理エンティティです(次の項で説明します)。

<form>要素の定義は、これらのフィールドに入力されてブラウザを介して送信される値を、受け入れて処理するスクリプトまたは別のリソースを参照します。

例:

この例では、logon_form.htmlページはユーザー認証を処理し、ユーザーがフォームを送信すると、logon_form.htmlはフォームの入力フィールドに入力された値を受け取り、適切な認証ロジックを実行します。

2.2.3.4 Logon Managerでサポートされる入力要素の理解

通常は、HTMLフォーム・フィールドが特定のクラスの入力要素として定義され、要素を定義するために使用されるタグとタイプ属性によって示されます。フォームの定義を構成する際に、Logon Managerは次の要素のタイプを識別します。

Logon Managerフィールド・タイプ	Logon Managerフィールド・タイプによって受け入れられる入力要素のタイプ
· User name/ID · Password · Third Field · Fourth Field	· テキスト – type="text"の<input>タグによって識別されるテキスト・フィールド。このフィールドに入力されるテキストはマスキングされません。 · パスワード - type="password"の<input>タグによって識別されるテキスト・フィールド。このフィールドに入力されるテキストはマスキングされます。 · 単一選択 - 値として単一のリスト項目の選択を許可する、<select>タグによって識別されるリスト・フィールド。 · 複数選択 - 値として1つ以上のリスト項目の選択を許可する、<select multiple … >タグによって識別されるリスト・フィールド。
· Submit	· 送信 - type="submit"の<input>タグによって識別されるボタン・コントロール。<form>タグのaction属性に指定されているコードを実行します(通常、アプリケーションのログオン・ロジックを含むHTMLドキュメントまたはスクリプトを呼び出します。) · ボタン - type="button"の<input>タグによって識別されるボタン・コントロール。機能的にはsubmitタイプの<input>要素と同一ですが、より柔軟にスタイル設定できます。 ·イメージ - type="image"の<input>タグによって識別されるハイパーリンクされたイメージであり、クリックすると参照先リンクを実行します。 · IMG - <img src=タグによって識別されるイメージであり、アンカー(<A HREF=)タグまたは、クリック時に送信URLを実行するJavaScriptのonClickアクション内にラップされています。 · アンカー - テキストのハイパーリンクの最も一般的な表示(デフォルトでは、ページに青の下線付きテキストとして表示されます)。<A HREF="…">タグによって識別されます。

2.2.4 推奨されるページ検査ツール

Webアプリケーションをプロビジョニングする際、オラクル社では、ページのDOM(およびオプションでソース・コードも)を簡単にナビゲートおよび検索できる方法で表示して、ページの構造をさらに簡単にすばやく理解できるようにする、ページ検査ツールを取得することを強くお薦めしています。

2.2.4.1 Mozilla FirefoxのDOM Inspector

このようなツールの例として、Mozilla FirefoxのアドオンDOM Inspectorがあります。例のページのDOMは、DOM Inspectorに次のように表示されます。

ページの階層構造は左側のペインにナビゲート可能なツリーとして表示され、要素をクリックするとブラウザ・ウィンドウでハイライトされ、右側のペインにその要素の属性および値が表示されて、ページのソース・コードを調べなくてもターゲット・ページ要素を容易に識別および理解できます。このツールは、大きくて複雑なページに特に便利です。

DOM Inspectorは、http://addons.mozilla.orgのMozilla Firefoxのアドオン・サイトで入手できます。

2.2.4.2 Mozilla FirefoxのFirebug

DOM Inspectorと同様のさらに拡張されて柔軟なツールは、Mozilla FirefoxのアドオンFirebugです。FirebugにはDOM inspectorのすべての機能が備わっており、マウスを置いた各コード要素の視覚的なハイライト表示を含め、DOMツリー内の完全なソース・コード表示が追加されています。ユーザーは、コードを変更してブラウザ・ウィンドウでその変更を確認することもできます。Firebugは主にWeb開発者用ですが、複雑なWebページを分析すると、Firebug自体が非常に有益であることがわかります。

Firebugは、http://addons.mozilla.orgのMozilla Firefoxのアドオン・サイトで入手できます。

2.2.5 検出マッチングの理解

前述のURLおよび要素が、ページ内のログオン・フォームを一意に識別するのに十分ではない場合、追加の検出基準を指定してマッチングによる検出範囲をさらに絞ることができます。マッチングという用語は、要素名や属性値などの特定のパラメータ値を、アプリケーションのテンプレートに格納されている値と照合することを指します。

たとえば、Webアプリケーションがメンテナンスのために停止している場合、ログオンしようとすると、ログオン失敗の理由を示すエラー・メッセージとともにログオン・フォームが再表示されます。そのようなシナリオでLogon Managerがログオンの試行を繰り返さないように、テンプレートに2つのログオン・フォームを定義し、定義の1つでエラー・メッセージ・テキストを照合するためのテキスト・マッチングを使用して、Logon Managerにエラーを表示するログオン・フォームを無視するように指示します。

注意: この項では、Webアプリケーション用のマッチングを正常に構成するために必要な、マッチング・メカニズムの背後にある原則について説明します。コンソールを使用してマッチングを構成する実際の手順は、「追加のフィールド検出基準の構成」を参照してください。

Logon Managerでは、次に対するマッチングを実行できます。

• ページに表示されるテキスト

• ページのソース・コード内のHTMLコード

• ページ要素の属性の名前および値

前述のマッチング・タイプを説明するために、ページ15から16の例を使用します。例はヘッダーにEnterprise Web Applicationを表示し、これは、そのような特定のテキストを簡単にインライン・スタイル設定できるように、<div>コンテナとして実装されています。

2.2.5.1 検出マッチング対オフセット・マッチング

Logon Managerでは、検出およびオフセットの2種類のマッチングが提供されています。ほとんどすべてのシナリオで常に検出マッチングを使用し、オフセット・マッチングを使用することはありません。後者は、フレームが名前属性によって識別されないフレームセットを使用するレガシー・ページに有用です。このような場合、Logon Managerは、ページのDOMにフレームが表示される順番で、フレームに序数を割り当てます。そのようなフレームセットの特定のフレーム内の要素で照合するには、フォーム定義ダイアログの「Matching」タブにある「Offset Start」パラメータ値としてその序数を指定します。

2.2.5.2 ページ上のテキストに対するマッチング

最も一般的に使用されるマッチング・モードであり、形式にかかわらず、ヘッダー・テキスト自体を照合できます。たとえば、次のようにマッチング・ルールを構成して、Enterprise Web Applicationを照合します。

• Tag: div

• Criteria: 「Text」

• Value: Enterprise Web Application

• Match whole value: 選択

• Use regular expression: 選択解除

この構成では、次が一致します。

2.2.5.3 ページのソース内のHTMLコードに対するマッチング

HTMLマッチング・モードでは、ページのソース・コードにある任意のコードを照合できます。このモードの最も一般的な用途は、マークアップを含めたレンダリングされるテキストの照合ですが、ページ特有の特定のコードの照合でも使用できます。

注意: HTML仕様の性質のため、Logon Managerは<span>タグについて照合できません。

たとえば、Enterprise Web Applicationを照合してEnterprise Web Applicationは照合しない場合、次のようにマッチング・ルールを設定します。

• Tag: div

• Criteria: 「HTML」

• Value: <b>Enterprise Web Application></b>

• Match whole value: 選択

• Use regular expression: 選択解除

この構成の結果として、次が一致します。

注意: 「Match Whole Value」オプションによって、Logon Managerは「Value」フィールドに入力された文字列全体を照合しますが、これはデフォルトで有効になっています。ページ上の部分一致(<b>Enterpriseなど)を許可するには、このオプションを無効化します。

前述の<div>コンテナの開始タグ全体を照合するには、基準値としてそれを指定し、その親要素をタグとして指定します。

• Tag: body

• Criteria: 「HTML」

• Value: <div id="page-header"…

• Match whole value: 選択

• Use regular expression: 選択解除

この結果として、次が一致します。

2.2.5.4 要素の属性の名前および値に対するマッチング

要素内の特定の属性またはその値を照合することもできます。たとえば、<div>要素のid属性の値を照合できます。

• Tag: div

• Criteria: 「Attribute」

• Attribute name: id

• Value: page-header

• Match whole value: 選択

• Use regular expression: 選択解除

この結果として、次が一致します。

ただし、「Value」フィールドを空白のままにすると、属性名が照合されます。

2.2.5.5 論理演算子を使用した複雑なルール連鎖の構築

Logon Managerでは、ブール論理演算子を使用して個別のマッチング・ルールを連鎖させ、特定な状況で必ずポジティブ・マッチになる複雑なルール連鎖を作成することができます。

たとえば、パスワードが正常に変更されたときに、パスワード変更フィールドおよびコントロールを表示しながら成功メッセージを表示するパスワード変更フォーム用に、一致ルール連鎖を作成する場合があります。この場合、成功メッセージが表示されたら、標準的なパスワード変更フォームへの適切なレスポンスを保持しながら、Logon Managerがパスワード変更ループに入らずにフォームを無視するようにします。

このようにするには、次のルールを作成します。

• Logon Managerがフォームを無視する、成功メッセージ・テキストに対するNOT一致ルール、および

• ポジティブ・マッチになり、成功メッセージが表示されない場合にLogon Managerが応答する、フォーム上の任意のテキストに対するAND一致ルール。

例に基づくと、前述のルールは次のように構成されます。

ルール1

• Tag: html

• Criteria: 「Text」

• Value: Logon error

• Match whole value: 選択

• Use regular expression: 選択解除

• Operation: NOT

ルール2

• Tag: html

• Criteria: 「Text」

• Value: Enterprise Web Application

• Match whole value: 選択

• Use regular expression: 選択解除

• Operation: AND

注意: NOT一致ルールを定義する際、ポジティブ・マッチになるANDルールをその後に続ける必要があります。そうしない場合、Logon Managerがフォームに応答しなくなります。

他の一般的なマッチング・ルール連鎖の例を次に示します。次でポジティブ・マッチを取得する手順:

• ルール1およびルール2 - AND演算子を使用して、両方のルールをその順序で構成します。

• ルール1またはルール2 - AND演算子を使用してルール1を構成し、次にOR演算子を使用してルール2を構成します。

• ルール1およびルール2、しかしルール3は除く - 上と同じです。連鎖の最初にNOTルールを置き、その後に2つのANDルールを続けます。

• ルール1またはルール2、しかしルール3は除く - ANDルールとしてルール1を構成し、ORルールとしてルール2を構成し、NOTルールとしてルール3を構成し、連鎖の最初にNOTルールを置き、その後にANDルールとORルールを続けます。

2.2.6 ワイルドカードを使用した検出基準の構成

? (1文字)や* (スペースを除く文字の任意の組合せ)などのワイルドカードは、最も一般的に使用される動的検出基準を構成する方法です。フォーム定義の基準を構成する際に「Wildcard」オプションを使用し、次のガイドラインに従ってください:

• Je???eは、JeanneとJessieの両方と一致します。ただし、Jeanineとは一致しません(文字列の長さも、文字の順序も一致しないためです)。

• Je*eは、Jeで始まり、eで終わるすべての語と一致し、前述の3つの例は、この場合はすべて一致します。

• webapp*.company.comは、webappで始まるホスト名を含むすべてのURLと一致します。この技術は、ロード・バランシングされて共通URLでマスキングされており、アクセスされるたびに異なる物理ホストからロードされてURLが変化するアプリケーションのURLの照合に有用です。

2.2.7 正規表現を使用した検出基準の構成

また、ATLフレームワークでサポートされる正規表現を使用すると、このガイドで前述した基準に対してLogon Managerが一致すると認識する必要があるテキスト・パターンを作成することもできます。(フォーム定義の基準を構成する際の「Regular expression」オプションの使用。)参照用に、最も一般的に使用される演算子およびメタ文字を次にリストします。

式	説明
[ ]	大カッコ内のいずれかの文字と一致する文字クラスを示します。 例:[abc]は、a、bおよびcと一致します。
( )	文字グループ化演算子を示します。 例:(\d+,)*\d+は、カンマで区切られた数字のリストと一致します(1や1,23,456など)。
{ }	一致クラスを示します。
|	2つの式を区切り、そのうちの1つが一致します。 例:T|theは、Theまたはtheと一致します。
.	任意の1文字を検索します。
^	文字クラスの先頭に^がある場合、その文字クラスは否定されます。否定された文字クラスは、大カッコ内の文字以外の任意の文字と一致します。 例:[^abc]は、a、bおよびc以外のすべての文字と一致します。 正規表現の先頭に^がある場合、入力の先頭と一致します。 例: ^[abc]は、a、bまたはcで始まる入力のみと一致します。
$	正規表現の末尾にある$は、入力の最後と一致します。 例:[0-9]$は、入力の最後にある数字と一致します。
-	文字クラスで、ハイフンは文字の範囲を示します。 例:[0-9]は、0から9の任意の数字と一致します。
!	後に続く式を否定します。
?	前にある式がオプションであることを示します。1回一致するか、またはまったく一致しません。 例: [0-9][0-9]?は、2および12と一致します。
+	前にある式が1回以上一致することを示します。 例:[0-9]+は、1、13、666などと一致します。
*	前にある式が0回以上一致することを示します。
??、+?、*?	?、+および*の最短マッチ。できるかぎり多く一致する最長マッチと異なり、これらの最短マッチではできるかぎり少なく一致します。 例: 入力を<abc><def>とすると、<.*?>は<abc>と一致し、<.*>は<abc><def>と一致します。
\	次の文字がリテラルに解釈されることを強制するエスケープ文字。 例:[0-9]+は1つ以上の数字と一致しますが、[0-9]\+は後にプラス文字が続く数字と一致します。 \の後に数字nが続く場合、n番目の一致グループ(0から開始)と一致します。 例: <{.*?}>.*?</\0>は<head>Contents</head>と一致します。 \はまた省略にも使用され、最も一般的なものを次に示します。

2.3 フォームのレスポンスの理解

Logon Managerは、Webフォームおよびその入力フィールドの識別に成功すると、適切なヘルパー・オブジェクトを使用してターゲット・フィールドに移入し、フォーム内のsubmitコントロールを作動させます。Webページのコード化方法に応じて、次のレスポンス方式のいずれかを使用します。

2.3.1 コントロールID

これは、ほとんどのWebアプリケーションでデフォルトかつ推奨されるフォームのレスポンス方式です。この方式によって、Logon Managerは、ブラウザのAPIを使用して適切な資格証明をターゲット・フィールドにプログラム的に注入し、submitコントロールを動作させることができます。

ただし、Webページが、フォームのフィールドおよびコントロールとプログラム的に対話するLogon Managerの機能を阻止または禁止するように作成されている場合や、サインオン・イベントを完了するために追加のアクションが必要な場合(チェック・ボックスの選択、手動による特定のフィールドのフォーカス設定など)は、そのフォームと対話するために、コントロールID方式とSendKeys方式を併用する必要がある場合もあります。

2.3.2 SendKeys

この方式では、キーストローク、マウス・クリックなどのユーザー入力をエミュレートすることで、エージェントはターゲット・フォームと対話することができます。この方法は、エージェントがフォームのフィールドおよびコントロールとプログラムで対話できない場合に使用します。たとえば、ログオン・フォームがAdobe Flashを使用して実装されている場合、マウスクリックを送信してターゲット・フィールドを選択し、キーストロークを送信してそれらに移入し、次に最後のマウスクリックを送信してsubmitコントロールを動作させる必要があります。

2.3.3 コントロールIDとSendKeys

これは、前述の2つの方式を組み合せて両方の長所を活かすもので、プログラムでは実行できないアクションを必要とするサインオン・シナリオの解決方法として望ましい方式です。可能な場合は常にコントロールIDを使用してフォームと対話する一方で、キーストロークおよびマウス・クリックを送信して、フィールドのフォーカス設定、チェック・ボックスの選択、エージェントがターゲット・アプリケーション内ではプログラムで実行できないその他のアクションなどのタスクを実行します。

たとえば、カスケード検証のために特定の順序でフィールドに移入する必要がある場合(つまり、ユーザー名フィールドにデータが移入されたときにかぎりパスワード・フィールドがアクティブになる場合)、コントロールIDを使用して資格証明をフィールドに注入しますが、各フィールドの注入の合間にSendKeysで[Tab]キーストロークを送信してフィールドのフォーカスを移動することになります。

注意: この混合モードを実装するには、最初にSendKeysレスポンス方式を使用するようにフォームを構成し、目的のSendKeysアクションを構成し、そのアクションの構成中に、プログラム的なコントロールIDレスポンス方式を保持するアクションに対して「Inject directly into control」オプションを有効にします。

2.4 フォームの最適な構成の確認

フォームの構成を行う際に、この項の情報を使用して、ターゲット・アプリケーションの要件および機能に基づいて最適な構成を確認します。

2.4.1 ログオン・フォームの最適な構成の確認

2.4.1.1 ターゲット・フィールドとコントロールが「Web Form」ウィザードで表示されますか

ほとんどの場合、Web「Form」ウィザードはターゲット・フォームに存在する資格証明フィールドおよびコントロールを正常に検出して表示します。フィールドやコントロールの一部またはすべてがない場合、次のいずれかの手順を実行します。

• 「Form」ウィザードにフィールドまたはコントロールがまったく表示されない場合、ログオン・フォームに別のURLがあるか、ポップアップ内にログオン・フォームがあります。「ページ、要素またはポップアップのURLの取得」の説明に従ってこのURLを取得して、これをページのメインURLのかわりにウィザードに指定します。

• submitコントロールが認識されない場合、「Show Anchor Tags」オプションを有効にして、アンカー(つまり、<A HREF=)タグとして実装されているコントロールを表示します。

• フィールドが表示されない場合、詳細についてはOracleサポートに連絡してください。

2.4.1.2 フィールド名は非一意または動的ですか

ターゲット・フィールドの要素の名前が非一意または動的である場合、要素の名前のかわりに序数を使用して、Logon Managerへのフィールドを識別します。ページのDOMまたはソース・コード(あるいはその両方)を調べて、これに該当するかどうかを確認してください。詳細は、「フィールド検出の理解」を参照してください。

2.4.1.3 動的ページまたは要素のURLですか

ページまたはフォーム要素のURLが動的である場合、ワイルドカードまたは正規表現を使用して、エージェントのレスポンスを目的のURLまたはURLの範囲に制限する必要があります。詳細は、「URL検出の理解」を参照してください。

2.4.1.4 ログオン・フォームはFlashアプレットですか

ログオン・フォームがAdobe Flashで実装されている場合、Logon Managerはそのフィールドおよびコントロールとプログラム的に対話できないため、このような場合は、SendKeys方式を使用してフォームと対話します。

2.4.1.5 Submitコントロールはイメージですか

submitコントロールがイメージであり、そのURLが動的である(つまり、イメージが分散環境でホストされており、URLのホスト名の部分が静的でない)場合、ワイルドカードまたは正規表現を使用してコントロールに対して有効な目的のURLの範囲を指定する必要があります(そうしない場合、Logon Managerは、コントロールURLがテンプレートの構成に使用された元の静的な値から外れるとすぐに、コントロールの検出を停止します)。詳細は、「URL検出の理解」を参照してください。

2.4.1.6 ページ上にターゲット・フィールドの他にフィールドがありますか

ページ上にターゲット・フィールドの他に入力フィールドおよびコントロールがある場合、マッチングを使用して、エージェントのレスポンスを目的のフィールドに制限します。詳細は、「追加のフィールド検出基準の構成」を参照してください。

2.4.1.7 アプリケーションでログオン成功または失敗のメッセージ(あるいはその両方)を表示しますか

アプリケーションによっては、ログオンの成功または失敗を示すメッセージを表示します。その場合は、アプリケーション・テンプレートでログオンの成功フォームまたはログオンの失敗フォーム(あるいはその両方)を定義します。

2.4.2 パスワード変更フォームの最適な構成の確認

2.4.2.1 ログオン・フォームとパスワード変更フォームは同一画面上にありますか

アプリケーションによっては、ユーザー名フィールドや「Change Password」ボタンなど、ログオン関連のフィールドまたはコントロールを含むパスワード変更フォームを表示する場合があり、これによってアプリケーションのパスワード変更(PWC)フォームが起動します。「Auto Submit」機能が有効で、エージェントがこのようなアプリケーションに応答する場合は、パスワードの変更オプションが表示されず、ユーザーは自動的にログインされます。

ユーザーが目的のアクションを選択できるようにするには、テンプレートでログオン・フォームおよびパスワード変更フォームを定義します。エージェントは、ログオン・フォームおよびパスワード変更フォームが統合されたアプリケーションに応答する場合は、ユーザーに目的のアクション(ログオンまたはパスワード変更)を選択するように求めます。

注意: アクション・チューザ機能に猶予期間を構成するオプションもあります(猶予期間の間は、推奨されるアクションがログオンであり、目的のアクションを選択することを求められずにユーザーがログオンすることをエージェントが自動的に想定します)。このオプションは「Action Chooser Grace Period」という名称で、アプリケーション・テンプレート・ダイアログの「Miscellaneous」タブで利用できます。

2.4.2.2 パスワード変更を開始するためにアクションは必要ですか

フォームでパスワード変更を開始するアクションが必要な場合(チェックボックスの選択など)に、Webアプリケーションの性質のためにLogon Managerがそのアクションをプログラム的に完了できないことがあります。そのような場合は、可能であればSendKeys方式を使用してターゲット・コントロールと対話します。そうしない場合は、ユーザーに手動で必要なアクションを実行するよう指示します。

2.4.2.3 ターゲット・フィールドとコントロールが「Web Form」ウィザードで表示されますか

ほとんどの場合、Web「Form」ウィザードはターゲット・フォームに存在する資格証明フィールドおよびコントロールを正常に検出して表示します。フィールドやコントロールの一部またはすべてがない場合、次のいずれかの手順を実行します。

• 「Form」ウィザードにフィールドまたはコントロールがまったく表示されない場合、ログオン・フォームに別のURLがあるか、ポップアップ内にログオン・フォームがあります。「ページ、要素またはポップアップのURLの取得」の説明に従ってこのURLを取得して、これをページのメインURLのかわりにウィザードに指定します。

• submitコントロールが認識されない場合、「Show Anchor Tags」オプションを有効にして、アンカー(つまり、<A HREF=)タグとして実装されているコントロールを表示します。

• フィールドが表示されない場合、詳細についてはOracleサポートに連絡してください。

2.4.2.4 アプリケーションで新しいパスワードの確認は必要ですか

アプリケーションによっては、パスワードの変更を実行する際に、ユーザーに新しいパスワードの確認を求めます。ターゲット・アプリケーションでこのようなフォームを表示する場合、テンプレートに2番目のログオン・フォームを定義し、パスワード確認フォームに応答するよう構成します。

2.4.2.5 複数のフィールドに同じデータを注入する必要がありますか

複数のフィールドに同じデータを注入する必要がある場合、たとえば、フォームに「Password」フィールドおよび「Confirm Password」フィールドが含まれており、エージェントでそれらの両方に新しいパスワードを注入する場合、「Web Form」ウィザードの「Allow Multiple Field Designation」オプションを有効にし、これに応じてフィールドを割り当てます。

2.4.2.6 アプリケーションでパスワード変更の成功または失敗のメッセージ(あるいはその両方)を表示しますか

アプリケーションによっては、パスワード変更の成功または失敗を示すメッセージを表示します。その場合は、アプリケーション・テンプレートでパスワード変更の成功フォーム、またはパスワード変更の失敗フォームを定義します。

2.4.2.7 フィールド名は非一意または動的ですか

ターゲット・フィールドの要素の名前が非一意または動的である場合、要素の名前のかわりに序数を使用して、Logon Managerへのフィールドを識別します。ページのDOMまたはソース・コード(あるいはその両方)を調べて、これに該当するかどうかを確認してください。詳細は、「フィールド検出の理解」を参照してください。

2.4.2.8 動的ページまたは要素のURLですか

ページまたはフォーム要素のURLが動的である場合、ワイルドカードまたは正規表現を使用して、エージェントのレスポンスを目的のURLまたはURLの範囲に制限する必要があります。詳細は、「URL検出の理解」を参照してください。

2.4.2.9 Submitコントロールはイメージですか

submitコントロールがイメージであり、そのURLが動的である(つまり、イメージが分散環境でホストされており、URLのホスト名の部分が静的でない)場合、ワイルドカードまたは正規表現を使用してコントロールに対して有効な目的のURLの範囲を指定する必要があります(そうしない場合、Logon Managerは、コントロールURLがテンプレートの構成に使用された元の静的な値から外れるとすぐに、コントロールの検出を停止します)。詳細は、「URL検出の理解」を参照してください。

2.4.2.10 ページ上にターゲット・フィールドの他にフィールドがありますか

ページ上にターゲット・フィールドの他に入力フィールドおよびコントロールがある場合、マッチングを使用して、レスポンスを目的のフィールドに制限します。詳細は、「追加のフィールド検出基準の構成」を参照してください。

2.5 フォームの構成

この項の手順は、このガイドの前の方で説明した概念および用語を使用して説明します。この項の手順を実行するときは、「フォームの最適な構成の確認」を参照して、ターゲット・アプリケーションに最も適した構成を決定してください。

2.5.1 基本構成

フォームの基本構成を完了するには、次の手順を実行します。

注意: ターゲット・アプリケーションのタイトル・バーにある「Logon Manager」ボタン(有効な場合)をクリックし、表示されたコンテキスト・メニューから「Create Template」を選択すると、構成プロセスをすぐに開始できます

1. Logon Manager管理コンソールを開きます。デフォルトでは、ショートカットは「Start」→「Programs」→「Oracle」→「Logon Manager Console」にあります。

2. 左側のツリーで、「Applications」ノードを選択し、次のいずれかを実行します。

   • 新規テンプレートを作成して最初のフォームを定義する場合、右側のペインで「Add」をクリックしてから、「New Application」ダイアログに、わかりやすいテンプレート名を入力し、「Finish」をクリックします。新しいテンプレートが、格納済テンプレートのリストに表示されます。

     
     

     注意: 2つ以上のアプリケーション・テンプレートに対して、テンプレートのいずれかの名前が別のテンプレートの名前の先頭部分と同じになるように名前を付けると、エージェントは誤って最も短い名前を持つテンプレートを使用して、すべての対象アプリケーションに応答します。この動作を回避するには、テンプレート名が同じテキスト文字列で始まらないようにします。

     
     

   • 
     

   • フォームの定義を既存のテンプレートに追加する場合、「Applications」ノードを拡張して目的のテンプレート(テンプレートは右側のペインに表示されます)を選択してから、ペイン下部の「Add」をクリックします。

3. 表示された「Web Form」ウィザードで、ターゲット・フォームへの応答時に、エージェントと対話させるフィールドおよびコントロールを構成します。

4. 「Form Type」画面で、目的のフォーム・タイプを選択して「Next」をクリックします。

   
   

5. 次の画面で、ターゲット・ページ、フォームまたは要素のURLを入力し、プレビュー・ペインのロードが完了するのを待機します。

   
   

   
   

   注意: 同じ名前を共有するフィールドが2つ以上表示される場合、構成の完了時にエージェントがフォームに誤って応答する可能性があります。そのような場合は名前オプションのかわりに「Use ordinals」を有効にし、序数(連続した索引番号)を介してエージェントへの入力フィールドを一意に識別します。詳細は、「Webフォームの検出の理解」を参照してください。

   
   

6. 画面の下にあるフィールド・リストで、次のようにリスト内のオブジェクトの中からターゲット・フィールドおよびコントロールを選択して構成します。

   
   

   注意: 1つ以上のフィールドまたはコントロールがリストにない場合、手動での構成が必要となる場合があります。そのような場合は、ウィザードの残りをそのまま完了し、影響のある入力フィールドごとに「フィールドまたはコントロールの手動構成」の手順に従います。 デフォルトでは、すべてのフィールドおよびコントロールはコントロールIDレスポンス方式を使用します。1つ以上のフィールドにSendKeysレスポンス方式を使用する場合、この手順の説明に従ってそれらを定義してから、「SendKeys方式を使用したフィールドまたはコントロールの構成」の手順に従います。

   
   

   1. (オプション)フォームの複数のフィールドに同じデータを注入する必要がある場合(たとえば、「Password」および「Confirm Password」フィールドへのパスワードの注入)、「Allow multiple field designation」オプションを有効にします。

   2. 目的の各フィールドまたはコントロールを右クリックし、コンテキスト・メニューからその機能を選択します。選択したフィールドは、ページ・プレビューでハイライト表示されます。

      
      

      
      

      注意: ほとんどの場合「Detect Fields」機能は正確ですが、正確性を保証するためにも、常にフィールドおよびコントロールを手動で構成することをお薦めします。

      
      
      
      

      注意: 送信ボタン(通常は「OK」、「Logon」などのラベルが付いているボタン)がリストに表示されない場合でも、Logon Managerは資格証明の注入後に、アプリケーションに送信アクションを送信します。このアクションは、ユーザーが手動で[Enter]キーを押すのと同等です。

      
      

   3. submitコントロールが欠落している場合、アンカー(つまり、<A HREF=)またはイメージ(つまり、<IMG SRC=)として実装されていることがあります。その場合は、「Show anchor tags」または「Show non-input fields」(あるいはその両方)のオプションをそれぞれ有効にして、そのようなコントロールを表示します。

   4. 表示できる入力フィールドをすべて構成したら、「OK」をクリックします。

7. コンソールに、構成したばかりのWebフォーム定義のプロパティ・ダイアログが表示されます。次のいずれかを行います。

   • 「Web Form」ウィザードを使用してターゲット入力フィールドのすべてを正常に完了し、追加の構成が必要ない場合、「OK」をクリックしてダイアログを終了し、「リポジトリへのテンプレートの公開」の説明に従って変更をリポジトリに公開します(該当する場合)。

   • 「Web Form」ウィザードを使用して1つ以上のターゲット・フィールドを構成できない場合、「フィールドまたはコントロールの手動構成」の手順3に進みます。

   • 既存のURL検出基準の変更または追加のURL検出基準の指定が必要な場合は、「URL検出基準の構成」に進みます。

     
     

     警告: フィッシング攻撃の発生を防ぐために、デフォルトのワイルドカード正規表現の接頭辞である.*?をURL定義から削除することを強くお薦めします。

     
     

   • 「Matching」タブを使用して追加のフィールド検出基準を構成する必要がある場合、「追加のフィールド検出基準の構成」に進みます。

     
     

     
     

     注意: ページのコンテンツが動的である場合、つまり、ページのロードが完了した後に変化する場合は、「Options」タブの「Dynamic Page」オプションを選択して、アクティブなページのポーリングを有効にします。このようにすると、エージェントがページの変更を監視できます。

     
     

2.5.2 フィールドまたはコントロールの手動構成

「Web Form」ウィザードを使用して入力フィールドを構成できなかった場合、またはフィールドの既存の構成を変更する場合、次の手順に従います。

2.5.2.1 コントロールID方式を使用したフィールドまたはコントロールの構成

1. コンソールで、「Applications」ノードを展開し、目的のテンプレートを選択します。

2. 「General」タブで、目的のフォーム定義を選択し、「Edit」をクリックします。

3. 表示されるフォーム・プロパティ・ダイアログで、「Fields」タブを選択します

   
   

4. 新しいフィールドを構成する場合は「Add」をクリックし、既存のフィールドの構成を変更する場合はリスト内のフィールドを選択して「Edit」をクリックします。

5. 表示された「Web Field」ダイアログで、次の手順を実行します。

   
   

   注意: ここで指定する必要がある値の詳細は、「フィールド検出の理解」を参照してください。

   
   

   1. 「Function」ドロップダウン・リストで、フィールドの目的を選択します。使用可能な値は、「Username/ID」、「Password」、「Third Field」および「Fourth Field」です。

   2. 「Frame」フィールドに、フィールドの親フレーム要素の名前または序数を入力します。

   3. 「Form」フィールドに、フィールドの親フォーム要素の名前または序数を入力します。

   4. 「Field Type」ドロップダウン・リストで、ターゲット入力フィールドのタイプを選択します。

      
      

   5. 「Field Identification」フィールドで「…」(省略記号)ボタンをクリックして、Logon Managerがフィールドを識別する方法(利用可能な方法は、フィールド名、序数、マッチング)を選択し、選択した識別方法に適切な値を入力して、OKをクリックして変更を保存して、ダイアログを終了します。

      マッチングの構成の詳細は、「検出マッチングの理解」を参照してください。

      
      

   6. 「OK」をクリックして、フィールド定義をテンプレートに保存します。

6. 構成する追加フィールドごとに、手順iからviを繰り返します。

7. フォーム・プロパティ・ダイアログの「OK」をクリックして、ダイアログを終了します。

8. 該当する場合、「リポジトリへのテンプレートの公開」の説明に従って、リポジトリに変更を公開します。

2.5.2.2 SendKeys方式を使用したフィールドまたはコントロールの構成

Logon Managerでは、フォームのレスポンス方式がSendKeysに変更された後で、SendKeysアクションを直接追加することはできません。SendKeysレスポンス方式に切り替えられたフォーム定義に新しいアクションを追加するには、まずフォームをコントロールID方式に戻して、「コントロールID方式を使用したフィールドまたはコントロールの構成」の説明に従って目的のアクションを追加してから、フォーム定義をSendKeys方式に戻す必要があります。この手順では、既存のコントロールIDアクションをSendKeysアクションに変換する方法、および変換されたSendKeysアクションを構成する方法が説明されています。

注意: SendKeysフォーム定義をコントロールIDに戻すと、「Inject directly into control」オプションが無効化されていたすべてのSendKeysアクションは、削除されます。構成手順を開始する前に、フォーム構成を十分に計画しておくことを強くお薦めします。

SendKeysアクションを構成するには、次の手順を実行します。

1. コンソールで、「Applications」ノードを展開し、目的のテンプレートを選択します。

2. 「General」タブで、目的のフォーム定義を選択し、「Edit」をクリックします。

3. 表示されるフォーム・プロパティ・ダイアログで、「Fields」タブを選択します。

4. (オプション) SendKeys方式への最初の切替えの場合、「Transfer Method」セレクタの「SendKeys」を選択します。

   
   

   注意: SendKeys方式を選択すると、「Fields」リスト内のすべてのアクションが「SendKeys」アクションに変換され、(アクションのプロパティ・ダイアログにある)「Inject directly into control」オプションは有効になります。つまり、それらのアクションは、SendKeys方式を使用して実行する各アクションの「Inject directly into control」オプションを無効化するまでは、プログラム的に保持されます。可能な場合は必ずプログラム的な注入を使用し、フィールドまたはコントロールとのプログラム的な対話が不可能な場合のみSendKeysを使用することをお薦めします。 「SendKeys using journal hook」オプションを使用するタイミングの詳細は、「SendKeysを使用する場合のフォームのレスポンスのトラブルシューティング」を参照してください。

   
   

   「Fields」タブの表示が変更されて、SendKeysレスポンス方式が反映されます。

   
   

5. SendKeysアクションが実行される順序を変更するには、位置を変更するアクションを選択し、上および下矢印のボタンを使用して移動します。

6. SendKeysアクションを構成するには、リストから選択して「Edit」をクリックし、表示された「SendKeys」ダイアログを使用してアクションを構成します。ダイアログに表示される各オプションの説明は、コンソールのヘルプを参照してください。

   
   

7. アクションをすべて構成したら、「OK」をクリックして変更を保存し、「SendKeys」ダイアログを終了します。

8. フォーム・プロパティ・ダイアログの「OK」をクリックして、ダイアログを終了します。

9. 該当する場合、「リポジトリへのテンプレートの公開」の説明に従って、リポジトリに変更を公開します。

2.5.3 URL検出基準の構成

「Web Form」ウィザードによって構成されたデフォルトのURL検出基準を変更する必要がある場合、または追加の基準を指定する必要がある場合、次の手順を実行します。

警告: フィッシング攻撃の発生を防ぐために、デフォルトのワイルドカード正規表現の接頭辞である.*?をURL定義から削除することを強くお薦めします。

1. コンソールで、「Applications」ノードを展開し、目的のテンプレートを選択します。

2. 「General」タブで、目的のフォーム定義を選択し、「Edit」をクリックします。

3. 表示されたフォーム・プロパティ・ダイアログで、「Identification」タブを選択します。

   
   

4. 新しいURL定義を構成する場合は「Add」をクリックし、URL定義の構成を変更する場合はリスト内の定義を選択して「Edit」をクリックします。

5. 表示されたURL定義プロパティ・ダイアログで、目的の一致タイプを選択して必要な一致基準を入力し、「OK」をクリックしてURL定義を保存します。

   
   

   注意: ここで指定する必要がある値の詳細は、「URL検出の理解」を参照してください。

   
   

   
   

6. 構成する追加のURL定義がある場合は、手順4から5を繰り返します。

7. フォーム・プロパティ・ダイアログの「OK」をクリックして、ダイアログを終了します。

8. 該当する場合、「リポジトリへのテンプレートの公開」の説明に従って、リポジトリに変更を公開します。

2.5.4 追加のフィールド検出基準の構成

追加のフィールド検出基準を標準マッチングまたはオフセット・マッチング・モードで構成する必要がある場合、次の手順を実行します。

1. コンソールで、「Applications」ノードを展開し、目的のテンプレートを選択します。

2. 「General」タブで、目的のフォーム定義を選択し、「Edit」をクリックします。フォーム・プロパティ・ダイアログが表示されます。

3. ダイアログで「Matching」タブを選択して目的のマッチング・タイプに応じて、「Detection Match」または「Form Offset Match」セクションのいずれかで次の手順を完了します(詳細は、「検出マッチング対オフセット・マッチング」を参照してください)。

   
   

   
   

   注意: オフセット・マッチングを実行する場合、「Offset Start」値を指定する必要があります。

   
   

4. 新しいマッチング・ルールを構成する場合は「Add」をクリックし、既存のルールを変更する場合はリスト内のルールを選択して「Edit」をクリックします。

5. 表示された「Match Criteria」ダイアログで、次の手順を実行します。

   
   

   注意: ここで指定する必要がある値の詳細は、「検出マッチングの理解」を参照してください。

   
   

   1. 「Tag」フィールドで、親要素の名前を指定します。

   2. (オプション)ページ内に親要素のインスタンスが複数ある場合は、序数を決定し、「Match tag instance」ボックスを選択して値フィールドに序数を入力します。

   3. 「Criteria」フィールドで、目的のマッチング・モードを選択します。

   4. 「Value」フィールドに、ターゲット基準値を入力します。

   5. ほとんどのシナリオで、「Match whole value」オプションを有効なままにします。これにより、Logon Managerは基準値に対して厳密に照合します。このオプションを無効化すると、Logon Managerは基準値に対する部分一致もポジティブ・マッチとみなします。

   6. 基準値の一部として正規表現を使用する場合、「Use regular expression」オプションを有効にします。

   7. (オプション)マッチング・ルール連鎖を作成して複雑なマッチング・ルールを作成する場合、「Operation」ドロップダウン・リストから目的のブール演算子を選択し、前にあるルールにこのルールを連鎖させる方法を示します。

      
      

   8. 「OK」をクリックしてマッチング・ルールを保存します。

6. 追加のマッチング・ルールごとに手順5を繰り返します。

7. フォーム・プロパティ・ダイアログの「OK」をクリックして、ダイアログを終了します。

8. 該当する場合、「リポジトリへのテンプレートの公開」の説明に従って、リポジトリに変更を公開します。

2.6 フォームの構成のテスト

フォームを作成して構成した後は、エンドユーザーのワークステーションにデプロイする前に構成をテストすることを強くお薦めします。これを行うには、管理コンソールにあるTemplate Test Manager機能を使用します。

注意: Template Test Managerによって、最も一般的な構成の問題に対する対話型トラブルシューティングおよび是正手順が提供されますが、可能性があるすべての問題のシナリオに対応するようには設計されていません。完全なトラブルシューティングを行うには、次のように、このガイドとともにTemplate Test Managerの手順に従います。

公開の前に、フォーム構成をテストする次の一連の手順を完了します。

1. 左側のツリーの「Applications」ノードを展開し、ターゲット・テンプレートにナビゲートします。

2. ターゲット・テンプレートを右クリックし、コンテキスト・メニューから「Test」を選択します。

3. 表示された「Logon Manager Template Test Manager」ウィンドウにおいて、「Forms」ペインでターゲット・フォームを選択し、「Interactions」ペインに表示された手順に従います。

   
   

4. 次のいずれかを行います。

   • エージェントが期待どおりにアプリケーションに応答し、テストが正常に完了した場合は、「Finish」をクリックします。

   • エージェントが期待どおりにアプリケーションに応答せず、Template Test Managerによって提供された手順で問題が解決されない場合は、「Close」をクリックし、このガイドの後にあるトラブルシューティング・フローチャートに従って問題を確認して修正します。終了したら、手順1から3を繰り返して修正後の構成をテストします。

2.6.1 ログオン・フォームの構成のテスト

2.6.1.1 エージェントはフォームを検出しますか

エージェントにテンプレートが提供されると、自動レスポンス機能が明示的に無効化されていないかぎり、ターゲット・フォームに自動的に応答します。エージェントがフォームへの応答に失敗した場合は、「Webフォームの検出のトラブルシューティング」を参照してください。

2.6.1.2 エージェントは資格証明を注入しますか

資格証明がユーザーのストア内のターゲット・アプリケーションに対して格納されている場合、エージェントはアプリケーションの検出に成功すると、資格証明を適切なフィールドに注入します。「Auto-Submit」機能が明示的に無効化されていないかぎり、エージェントは自動的に資格証明の送信も行います。資格証明の注入が失敗する場合、「コントロールIDを使用する場合のフォームのレスポンスのトラブルシューティング」を参照してください。

2.6.1.3 ログアウトでログオン・ループが発生しますか

アプリケーションによってはログアウト時にログオン画面を表示しますが、この場合、それによってエージェントがログオン・ループに入り、エージェントを停止しないかぎり、事実上ユーザーはアプリケーションからログアウトできなくなります。これが発生した場合は、「ログオン・ループのトラブルシューティング」を参照してください。

2.7 パスワード変更フォームの構成のテスト

2.7.1 エージェントはフォームを検出しますか

エージェントにテンプレートが提供されると、自動レスポンス機能が明示的に無効化されていないかぎり、ターゲット・フォームに自動的に応答します。エージェントがアプリケーションへの応答に失敗した場合は、「Webフォームの検出のトラブルシューティング」を参照してください。

2.7.2 エージェントは資格証明を注入および送信しますか

エージェントはパスワードの変更を検出すると、「Auto Submit」機能が明示的に無効化されていないかぎり、資格証明を適切なフィールドに注入し、アプリケーションに送信します。資格証明の注入が不安定になるか、まったく発生しない場合、「コントロールIDを使用する場合のフォームのレスポンスのトラブルシューティング」を参照してください。

2.7.3 新しいパスワードはアプリケーションのパスワード・ポリシーを満たしますか

Logon Managerで生成される新規パスワードがアプリケーション独自のパスワード・ポリシーを満たさない場合、パスワード変更は失敗します。これに該当するかどうかを確認する場合は、現在エージェントにデプロイされているパスワード生成ポリシーを、ターゲット・アプリケーションのパスワード・ポリシーと比較し、パスワード変更の失敗の原因となる可能性がある非一貫性をすべて修正します。

2.7.4 エージェントはパスワード変更フォームにログオンと同様に応答しますか

エージェントがパスワード変更フォームに対して、ログオン・フォームと同様に応答する場合(つまり、エージェントがユーザーの現在格納されている資格証明を注入および送信する場合)は、次の項目をチェックします。

• テンプレートの構成ミス(誤った要素またはフォーム・タイプ、入力フィールド定義など)。

• パスワード変更フォームに動的URLが含まれるかどうかを確認し、含まれる場合はそれに応じてテンプレートを更新します。

• 検出マッチングを使用している場合は、正しいマッチング・タイプを使用しているかどうかを確認し、マッチング文字列にエラーがないか検証します。

2.8 リポジトリへのテンプレートの公開

アプリケーション・テンプレートのテストが正常に終了したら、リポジトリ内の選択したターゲット・コンテナにディレクトリ形式の階層で(デフォルト)、またはフラット形式の構成ファイルとして公開することで、エンドユーザー・マシンに配付できます。

注意: Logon Managerをリポジトリとともにデプロイする方法およびリポジトリ・ツリー構築のベスト・プラクティスは、『ディレクトリ・ベースのリポジトリでのLogon Managerのデプロイ』ガイドを参照してください。 この手順を実行する前に、リポジトリの構造および構成を熟知していることを確認します。

目的のテンプレートおよびその他の構成オブジェクトを選択し、リポジトリに公開するには、次の手順を実行します。

1. Logon Manager管理コンソールを起動します。

2. 「Applications」ノードを右クリックし、コンテキスト・メニューから「Publish…」を選択します。「Publish to Repository」ダイアログが表示されます。
   

3. 「Available configuration objects」リストで、目的のオブジェクトにナビゲートして選択します。

   
   

   注意: オブジェクトが構成されているカテゴリのみが、このリストに表示されます。たとえば、パスワード生成ポリシーが存在しない場合、対応するカテゴリはこのリストに表示されません。

   
   

4. 「>>」をクリックして、選択したオブジェクトを「Selected objects to be published」リストに移動します。(このリストからオブジェクトを除去して公開しないようにするには、オブジェクトを選択して、「<<」をクリックします。)

   
   

5. 選択したオブジェクトを公開する対象のコンテナを選択します。

   以前、目的のコンテナに公開したことがある場合は、「Target Repository」ドロップダウン・リストからそれを選択します。

   以前、目的のコンテナに公開したことがない場合、または目的のコンテナ・パスが「Target Repository」ドロップダウン・リストに表示されない場合は、「Browse」機能を使用して目的のコンテナを検索して選択する必要があります。

   1. 「Browse」をクリックして、ディレクトリ・ツリーを参照します。

      
      

      注意: ディレクトリにまだ接続していない場合は、必要な接続情報を提供するようにコンソールから求められます。

      
      

   2. 表示された「Browse for Repository」ダイアログで、目的のコンテナにナビゲートして選択します。
      

   新しいコンテナを作成する場合は、目的の親コンテナを右クリックし、コンテキスト・メニューから「New Container」を選択し、新しいコンテナの目的の名前を入力し、「OK」をクリックしてプロセスを完了します。

6. (オプション)構成オブジェクトをフラット形式で格納する必要がある環境の場合は、個々のオブジェクトとしてでなく、構成ファイルで「Store selected items」チェック・ボックスを選択します。

   目的のコンテナに存在する場合、このオプションを選択することで、既存の構成ファイルに格納されているすべての項目が上書きされます。

7. (オプション)初回使用オブジェクト(FTUList)を作成する場合は、対応するチェック・ボックスを選択します。

   このオプションは、手順6で構成オブジェクトをフラット形式で格納することを選択した場合にのみアクティブになります。

8. 「Publish」をクリックします。コンソールは、選択したオブジェクトをターゲット・リポジトリに公開します。

   
   

   注意: 公開プロセスが完了するまで、ダイアログを終了したり、コンソールを閉じようとしないでください。オブジェクトが公開されると、ダイアログは自動的に閉じます。

   
   

   公開プロセスの詳細は、Logon Manager管理コンソールのヘルプを参照してください。

2.9 Webフォームの検出のトラブルシューティング

不安定なフォーム検出を診断するには、次の手順を使用します。

2.9.1 「Logon Using Logon Manager」トレイ・アイコン・オプションで検出に成功しますか

エージェントはフォームを検出しないが、エージェントのシステム・トレイ・アイコンからの「Logon Using Logon Manager」オプションの呼出しでは検出に成功する場合、次の手順を実行します。

• フォーム定義の「Options」タブにある「Auto-recognize」オプションが有効になっていることを確認します。

• 誤ったまたは不明確なURLおよび入力フィールド定義、マッチング・ルールなど、テンプレートにエラーがないか確認します。

2.9.2 ページのロードは完了しましたか

ページのロードが完了したことがブラウザによって示されるまでは、エージェントは検出を開始しません。ページのロードが遅い場合、完全にロードされるまで待ってから、検出が適切に行われているかどうかを判断する必要があります。通常、ブラウザのステータス・バーは、ブラウザ・ウィンドウの下にあり、「Done」または「Finished」などの適切なメッセージを表示することによって、ページのロードが完了したことを示します。

2.9.3 適切なヘルパー・オブジェクトが実行されていますか

ブラウザに接続され、ブラウザとデータを送受信する手段をLogon Managerに提供するヘルパー・オブジェクトを、エージェントは、インストール済Webブラウザと通信するために使用します。ヘルパー・オブジェクトがバックグラウンドで実行されていない場合、Logon Managerはブラウザと通信できません。詳細は、「Webフォームの検出の理解」を参照してください。

2.9.4 検出およびオフセット・マッチング・ルールをすべて削除すると検出に成功しますか

ターゲットWebフォームの正常な検出を妨げるように1つ以上のマッチング・ルールを構成している可能性があります。すべてのマッチング・ルールを削除し、問題を発生させているルールがわかるまで検出をテストしながら、1つずつ追加し直します。

2.9.5 URL定義をhost.domainフォームに切り捨てると検出に成功しますか

エージェントがフォームを一貫して検出することを妨げる動的セグメントが、URLに含まれている可能性があります。URL定義をhost.domainフォームに単純化し、テンプレートをテストします(検出が成功する場合、問題を発生させているセグメントがわかるまで一度に1セグメントずつURL定義を再作成してから、正規表現を使用して動的セグメントに対応します)。詳細は、「URL検出の理解」を参照してください。

前述の手順で問題が解決されない場合は、Oracleサポートに連絡して指示を受けてください。

2.10 コントロールIDを使用する場合のフォームのレスポンスのトラブルシューティング

2.10.1 エージェントはフォームを検出しますか

エージェントがフォームをまったく検出せず、レスポンスを試行しない場合、「WEbフォームの検出の理解」を参照して、検出を阻止している可能性があるテンプレート構成の問題を識別します。

2.10.2 エージェントは資格証明を注入しますが、送信はしませんか

エージェントがフィールドを正常に検出して正しい資格証明を注入するが、それらを処理のためにアプリケーションに自動的に送信することができない場合、[Enter]を押して、資格証明が送信されるかを確認し、次のいずれかを実行します。

• [Enter]を押すと資格証明が送信される場合、テンプレートからsubmit入力フィールド定義を削除します。submitフィールド定義が欠けている場合、エージェントは、デフォルトの送信アクションである[Enter]キーストロークを送信します。

• [Enter]を押しても資格証明が送信されない場合、手動で送信するようにユーザーに指示します。

2.10.3 フィールドへの移入が不安定ですか

エージェントによるフィールドへの移入が不安定(誤った値、切り捨てられた値、文字化けした値または空白の値を取り込むなど)なときは、1つ以上のターゲットの要素名が非一意または動的である場合があります。このような場合、要素名のかわりに序数を使用して、Logon Managerへの要素を一意に識別します。

前述の手順で問題が解決されない場合は、Oracleサポートに連絡して指示を受けてください。

2.11 SendKeysを使用する場合のフォームのレスポンスのトラブルシューティング

2.11.1 事前入力されたフィールドによって誤ったログオンが発生しますか

アプリケーションによっては、ログオン・フォームの表示時にログオン・フィールドの事前入力を行うことがあります(たとえば、ユーザー名のフィールドに、最後に正常にログオンしたユーザーの名前が事前入力されているなど)。1つ以上の[Backspace]または[Delete]キーストロークを送信して、資格証明を注入する前に、事前入力されたフィールドをクリアする必要がある場合があります。

2.11.2 カーソルは常に同じフィールドで開始して、フォーカスを保持しますか

カーソルが必ずしも同じフィールドで開始せず、エージェントによる移入前にフィールドがフォーカスを失う場合は、特定のホットキーの組合せ([Alt]+[U]など)または標準のWindowsキー([Tab]、矢印など)によるフィールドへのナビゲートがアプリケーションで許可されるかどうかを確認します。フィールドへのナビゲートにキーストロークを使用できない場合、目的のフィールドまたはコントロールをターゲット指定するマウス・クリック・アクションを使用します。

2.11.3 単一のフィールドに複数の値が注入されますか

エージェントが単一のフィールドに複数の値(ユーザー名とパスワードなど)を挿入する場合は、エージェントによるSendKeysアクションの起動が非常に早いため、アプリケーションが適切に応答できていない可能性があります。このような場合は、資格証明の注入の信頼性が高まるまで、アクションの起動速度を低下させます。これを行うには、他のアクションとの間に遅延アクションを挿入するか、「End-User Experience」→「Response」の下にある「SendKeys event interval」グローバル・エージェント設定を「Use for slow system」または「Use for very slow system」に設定します。

2.11.4 ジャーナル・フックを使用するSendKeysに切り替えると、注入の信頼性が回復しますか

前述の手順の提案を試した後もエージェントが引き続き単一のフィールドに複数の値を注入する場合は、フォームの対話方法を「SendKeys with journal hook」に切り替えます。これを行うには、アプリケーション・テンプレートで「General」タブを選択して目的のフォームを選択し、「Edit」をクリックして「Fields」タブを選択し、「Transfer Method」オプションを「SendKeys using journal hook」に設定します。

注意: 「SendKeys using journal hook」方式を使用すると、エージェントが代替APIを使用してキーストロークおよびマウス・クリックをブラウザに送信するため、これは通常、Citrix環境で最も効果的です。

2.11.5 注入された値から文字が欠落していますか

注入されたフィールド値から個々の文字が欠落している場合は、エージェントによるSendKeysアクションの起動が非常に早いため、アプリケーションが適切に受け入れることができていない可能性があります。このような場合は、資格証明の注入の信頼性が高まるまで、アクションの起動速度を低下させます。これを行うには、他のアクションとの間に遅延アクションを挿入するか、「End-User Experience」→「Response」の下にある「SendKeys event interval」グローバル・エージェント設定を「Use for slow system」または「Use for very slow system」に設定します。

2.11.6 マウス・クリック・アクションを使用してフィールドにフォーカスすると、ログオンに成功しますか

ログオンに引き続き失敗する場合は、マウス・クリック・アクションを使用してフォーム内のすべてのフィールドおよびコントロールに対してフォーカスを設定することを検討します。

前述のどの手順でも問題を解決できない場合は、Oracleサポートに連絡してください。

2.12 検出マッチングのトラブルシューティング

2.12.1 すべてのマッチング・ルールを削除すると、フォームの検出が回復しますか

テンプレートのフォーム定義からすべてのマッチング・ルールを削除すると、適切なフォーム検出が回復する場合、問題を発生させているルールがわかるまでルールを1つずつ追加し直します。次に、問題のルールの範囲を広げる(たとえば、サイトのDOM階層で現在指定しているものよりも1つ上にあるHTMLコンテナを指定する)か、問題のルールを完全に削除して、検出が回復するか確認します。マッチングを完全に無効化しても検出が回復しない場合、問題はどこか別の場所にあります。「Webフォームの検出のトラブルシューティング」を参照して問題を解決してください。

前述の手順で問題が解決されない場合は、Oracleサポートに連絡して指示を受けてください。

2.13 ログオン・ループのトラブルシューティング

一部のアプリケーションではログアウト時にログオン・フォームが表示されるため、Logon Managerがログオン・フォームを認識してアプリケーションへの再ログインを自動的に行う原因となります。これによって無限ログオン・ループが作成され、アプリケーションからログアウトできません。管理者は、このループの発生を防ぐために最後のログオン以降、設定された期間内はLogon Managerがアプリケーションにログオンするのを禁止するログオン猶予期間機能を有効にすることを選択できます。

2.13.1 ログアウト後のフォームのURLは、標準ログオン・フォームのURLと異なりますか

ログアウト時に表示されるログオン・フォームのURLが、標準ログオン・フォームのURLと異なる場合、テンプレートでURL定義を変更して、ログオン後のフォームのURLがポジティブ・マッチにならないようにします。手順は、「URL検出基準の構成」を参照してください。

2.13.2 ログアウト後のフォームは、標準ログオン・フォームと異なりますか

ログアウト時に表示されるログオン・フォームがアプリケーションの標準ログオン・フォームと十分に異なる場合、マッチングを使用して2つのログオン・フォームを一意に区別します。手順は、「追加のフィールド検出基準の構成」を参照してください。

2.13.3 「Logon Loop Grace Period」オプションを構成すると、ログオン・ループは解決されますか

ログアウト後のフォームを標準ログオン・フォームと一意に区別できない場合は、指定された猶予期間が完全には経過していない場合にエージェントが同じアプリケーションに自動的にログオンするのを防ぐ猶予期間を構成します。

ログオン・ループ猶予期間タイマーを構成するには、次の手順を実行します。

1. Logon Manager管理コンソールで目的のテンプレートを開き、「Miscellaneous」タブを選択します。

2. 「Logon Loop Grace Period」フィールドで、ドロップダウン・リストから目的の操作モードを選択します。

   • 「Prompt」 - エージェントは、猶予期間が有効なときにアプリケーションのログオン・フォームを検出した場合、ログオンを完了するか、アプリケーションを無視するかを尋ねるプロンプトを表示します。

   • 「Silent」 - エージェントは、猶予期間が有効なときにアプリケーションのログオン・フォームを検出した場合、アプリケーションを無視し、ユーザーのログオンを行いません。

   • 「None」 - 猶予期間タイマーを非アクティブ化します。エージェントは、アプリケーションのログオン・フォームを検出するたびにアプリケーションに応答します。

3. 猶予期間が有効なときにエージェントに実行させる内容に応じて、次のいずれかを実行します。

   • アプリケーションの実行可能ファイルの起動が検出されるたびにエージェントがユーザーのログオンを行うようにするには、「Reset for each process」チェック・ボックスを選択します。

   • 猶予期間が経過するまでエージェントがアプリケーションを無視するようにするは、「Reset for each process」チェック・ボックスを空白のままにします。

4. 変更を保存してリポジトリにコミットします(該当する場合)。

   
   

   注意: ログオン猶予期間タイマーを構成しても、ログオン・ループが特定のフォーム定義で発生する場合は、フォーム定義の「Options」タブの「Adhere to logon loop grace period」オプションが有効になっていることを確認します。

   
   

前述の手順で問題が解決されない場合は、Oracleサポートに連絡して指示を受けてください。

2.14 Javaアプリケーションの問題のトラブルシューティング

Javaアプリケーション固有の問題を診断し解決するには、次のステップを使用します。

2.14.1 インストールしたJREはサポートされているブランドおよびバージョンですか

サポートされるJREのリストについては、ご使用のバージョンのLogon Managerのリリース・ノートを参照してください。インストールしたJREがサポートされていない場合は、Logon Managerを現在のJREがサポートされるリリースにアップグレードするか、現在のJREをご使用のリリースのLogon Managerでサポートされるバージョンに置き換える必要があります。

2.14.2 Oracle JInitiator、あるいは開発元がOracleまたはIBM以外の別のJREを使用していますか

Logon Managerを、Oracle JInitiatorまたはOracle/IBM以外のJREとともにデプロイした場合の問題は報告されていませんが、このようなJREを使用した場合のLogon Managerの適切な動作についてはサポートおよび保証されません。

2.14.3 JHOはロードされていますか

場合によっては、Javaアプリケーション使用時に構成上の問題によってJHOがロードされない場合があります。JHOがインストールされ実行されていることを確認するには、Microsoft Spy++ (Microsoft Visual Studioに付属)、またはSysInternals Process Explorer (http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx)などのプロセス・ビューア・ツールを使用して、JVM実行可能ファイルがssojho.dll子スレッドを生成したことを確認してください。

次に示す例は、Process ExplorerでのSun JVM実行可能ファイルjavaw.exeのプロパティ・ボックスを示しており、ssojho.dll子スレッドが実行中であることがわかります。

JHOがターゲットJREに対してロードされていない場合は、(ホーム・ディレクトリにある)ユーザーの.java.policyファイルで、JHOが必要とする権限が付与されているかどうかを確認します(次の項で説明します)。

2.14.4 JHOで必要な権限の検証および修復

JHOは、ターゲットJREのコンテキストで適切に動作できるように、ユーザーの.java.policyファイルを通じて付与される特定の権限のセットを必要とします。これらの権限が有効でない場合、Logon ManagerはJavaアプリケーションを検出することも、それに応答することもできません。

2.14.4.1 必要な権限が付与されているかどうかの確認

Logon Managerが起動するたびに、権限はテンプレート.java.policyファイル(%INSTALLDIR%\v-GO SSO\Helper\Java)から、ユーザーの.java.policyファイル(ユーザーのホーム・ディレクトリ)にコピーされます。これらの権限は、Javaアプリケーションが起動されるたびにJHOに自動的に付与されます。

必要な権限がJHOに付与されていない疑いがある場合は、Logon Managerの起動後に、JHOを参照している例外のうち欠落する権限に関する例外がないか、JREのログを確認してください。そのような例外が存在する場合、必要な権限は付与されていません。次のいずれかの原因が考えられます。

• ユーザーの.java.policyファイルに、JHOで必要な権限が含まれていない。

• ターゲットJREのセキュリティ設定が(通常はJREのjava.securityファイルに保存される)、ユーザーの.java.policyファイルを参照しない。

2.14.4.2 欠落したJHO権限の修復

必要なJHO権限がユーザーの.java.policyファイルに含まれていない場合、そのファイルのACLによってLogon Managerがそのファイルに権限を書き込めない可能性があるため、ファイルのACLを調べて書込み権限が拒否されていないかを確認してください。

ACLが適切で、必要な権限がユーザーの.java.policyファイルに存在しない場合は、次のいずれかを実行します。

• ユーザーの.java.policyファイルに、保持する必要がある他の権限または構成情報が含まれている場合は、このファイルを編集して欠落しているJHO権限を手動で追加します。

• ユーザーの.java.policyファイルに、保持する必要がある他の権限または構成情報が含まれていない場合は、このファイルを削除してからLogon Managerを再起動すると、ファイルが再作成されて必要な権限が自動的に挿入されます。

注意: JREがそのベンダーによって更新され、将来のリリースで1つ以上の新しい権限が導入される場合がありますが、JHOでそれが必要になったとしても、Logon Managerのリリース時点ではそれが考慮されていない可能性があります。その場合は、Logon ManagerおよびターゲットJavaアプリケーションの起動後に、欠落する権限に関する例外がないかJREのエラー・ログを確認し、その権限をLogon Managerの.java.policyテンプレート・ファイルに追加して、次回Logon Managerを起動したときにユーザーの.java.policyファイルを通じてその権限が付与されるようにします。

2.14.5 Java Helper Object (JHO)の動作の構成

Logon Managerは、JHOの次の側面の動作を制御できる、グローバルなエージェント設定を提供します。

• 特定のJREバージョンを除外

• 特定のJREベンダーを除外

• Javaアプレットのロードを考慮したレスポンス遅延を定義

• JREの初期化を考慮したレスポンス遅延を定義

• レスポンス再試行間の遅延を定義

• レスポンス再試行の最大数を定義

• JHOが認識または無視する特定の階層、ウィンドウ、コンポーネントおよび注入タイプのイベントを定義する

これらの設定は、Logon Manager管理コンソールのツリーの次の場所にあります。

「Global Agent Settings」→「Live」→「User Experience」→「Application Response」→「Java Applications」

これらの設定および構成方法の詳細は、コンソールのヘルプを参照してください。さらに精度の高い制御を行う場合、Logon Managerではレジストリ設定が提供されています(次の項で説明します)。これらの設定は熟練した管理者のみが行うことをお薦めします。

2.14.5.1 手動による特定のJREに対するJHOの制限

前述のコンソール設定以外に、Logon Managerでは非常に精度の高い包含および除外ルールを作成できるレジストリ設定が提供されています(包含および除外ルールは、Logon Managerがターゲット・アプリケーションに対してJHOをロードするかどうかを決定する際に使用します)。Java Virtual Machine (JVM)実行可能ファイル、JARファイル、およびJHOで考慮されるコマンドライン・パラメータを、正規表現を使用して指定できます。

これらの設定を構成する際には、次の点に注意してください:

• 設定の対象となる値を省略すると、指定されているデフォルトが使用されます(値を設定すると、一致しない値はすべて無視されます)。

• JHOは最初に包含ルールを処理し、その後除外ルールを処理します。

• N接尾辞は、特定のアプリケーションに属する設定をバンドルする一意の数値識別子です。JHOは、このバンドルを昇順に順次処理します。N接尾辞は、1から始まる正の整数です。

• トレース・ロギング・ユーティリティを使用して、アプリケーションのホストJVM実行可能ファイルおよび起動コマンドを確認できます。Javaトレース・ログの先頭部分は、アプリケーションのホストJVMおよび起動コマンドを示します。

設定は、Windowsレジストリの次のパスにあります。HKEY_LOCAL_MACHINE\SOFTWARE\Passlogix\Extensions\AccessManager\JHO

設定は、次のカテゴリに分けられます。

• JHO包含ルール

• JHO除外ルール

• 許可されるJava Runtime Environment (JRE)バージョン

2.14.5.1.1 JHO包含ルール

これらの設定は、ホストJVM実行可能ファイル、アプリケーションJARファイル、およびターゲット・アプリケーションに対してJHOをロードするためのコマンドライン・パラメータを指定する場合に使用します。値は、大/小文字が区別されない正規表現です。

設定	説明
JhoIncludeHostNameN	アプリケーションのホストJVM実行可能ファイルを指定します。 たとえば、アプリケーションがjava.exeまたはjavaw.exeという名前のJVM実行可能ファイルによってホストされている場合にJHOをロードするには、値をJhoIncludeHostName1=.*javaw?\.exeのように設定し、値を指定しない場合のデフォルトでは、 すべての実行可能ファイルが受け入れられます(つまり、JHOはどのような実行可能ファイルに対してもロードされます)。
JhoIncludeHostCommandLineN	アプリケーションの起動に使用されるコマンドを指定します。通常、コマンド文字列には、JVM実行可能ファイルのフルパスと名前、JARファイル、および必要なすべてのコマンドライン・パラメータが含まれます。 たとえば、アプリケーションのJARファイルがLogin.jarという名前の場合のみJHOをロードする場合(コマンドの残り部分は異なっていても許容される)、値を次のように設定します。JhoIncludeHostCommandLine1=.*Login\.jar.*値を指定しない場合のデフォルト:すべてのコマンド文字列が受け入れられます(つまり、どのようなコマンドでもJHOはロードされます)。

2.14.5.1.2 JHO除外ルール

これらの設定は、ホストJVM実行可能ファイル、アプリケーションJARファイル、およびJHOがターゲット・アプリケーションを無視するためのコマンドライン・パラメータを指定する場合に使用します。値は、大/小文字が区別されない正規表現です。

設定	説明
JhoExcludeHostNameN	アプリケーションのホストJVM実行可能ファイルを指定します。 たとえば、ホストJVM実行可能ファイルの名前が"java.exe"または"javaw.exe"の場合にJHOがアプリケーションを無視するようにするには、値を次のように設定します。JhoExcludeHostName1=.*javaw?\.exe値を指定しない場合のデフォルト:空白(つまり、JHOはアプリケーションを無視しません)
JhoExcludeHostCommandLineN	アプリケーションの起動に使用されるコマンドを指定します。通常、コマンド文字列には、JVM実行可能ファイルのフルパスと名前、JARファイル、および必要なすべてのコマンドライン・パラメータが含まれます。 たとえば、JARファイルの名前が"Login.jar"の場合にJHOがアプリケーションを無視するようにするには(ただし、コマンドの残りの部分は非間接的)、値を次のように設定します。JhoExcludeHostCommandLine1=.*Login\.jar.*値を指定しない場合のデフォルト:空白(つまり、JHOはアプリケーションを無視しません)

2.14.5.1.3 許可されるJava Runtime Environment (JRE)バージョン

これらの設定では、JHOがロードされる目的のJRE/JDKバージョンを指定可能であり、この指定範囲外のバージョンはすべて無視され、JHOはロードされません。

どちらの設定の値もx.y.zという形式である必要があります。

• xは、メジャー・バージョンです。

• yは、マイナー・バージョンです。

• zは、リリース・タイプ(機能、メンテナンスまたは更新)、およびインストールされているJREのビルドID (1.6.0_07など)を示します。

設定	説明
JhoMinimumJavaVersion	許可されるJRE/JDKバージョンの下限を指定します。 デフォルト値: 1.2 (JHOでサポートされる最も古いJREバージョン)
JhoMaximumJavaVersion	許可されるJRE/JDKバージョンの上限を指定します。 デフォルト値: 空白(つまり、JREバージョンの上限はありません)

2.14.5.2 Java Helper Object (JHO)のイベント・レスポンス動作の手動によるカスタマイズ

コンソールで提供される設定以外に、Logon Managerでは、さらに高レベルの精度でJHOのイベント・レスポンス動作を制御するためのレジストリ設定が提供されています。これらの設定を使用すると、Javaアプリケーションが検出された場合に特定のイベントに対するJHOのレスポンスを変更することによって、Javaアプリケーションに応答する際のLogon Managerのパフォーマンスのトラブルシューティングおよび最適化を実行できます。

この設定は、Windowsレジストリの次のキーにあります。HKEY_LOCAL_MACHINE\SOFTWARE\Passlogix\Extensions\AccessManager

2.14.5.2.1 イベント・レスポンス構成の設定

設定	説明
JhoHierarchyEventProcessing	どのJava階層イベントを認識するかを決定します。フラグを次のように設定します。 HIERARCHY_EVENT_CHANGED = 0x1 前述の値は、すべての階層イベントを認識するようにJHOに指示します。
JhoEventWaitTimeout	JHOコントロールのイベント処理タイムアウトを決定します(ミリ秒単位)。デフォルト値の0は、JHOに無期限に待機するように指示します。
JhoWindowEventProcessing	どのJavaウィンドウ・イベントを認識するかを決定します。このフラグは、次の値の組合せです。 ·WINDOW_EVENT_OPENED = 0x1 ·WINDOW_EVENT_CLOSED = 0x2 ·WINDOW_EVENT_ACTIVATED = 0x4 ·WINDOW_EVENT_DEACTIVATED = 0x8 ·WINDOW_EVENT_CLOSING = 0x10 ·WINDOW_EVENT_ICONIFIED = 0x20 ·WINDOW_EVENT_DEICONIFIED = 0x40 デフォルトでは、すべてのウィンドウ・イベントが認識されます。
JhoComponentEventProcessing	どのJavaコンポーネント・イベントを認識するかを決定します。このフラグは、次の値の組合せです。 ·COMPONENT_EVENT_SHOWN = 0x1 ·COMPONENT_EVENT_HIDDEN = 0x2 ·COMPONENT_EVENT_ADDED = 0x4 ·COMPONENT_EVENT_REMOVED = 0x8 デフォルトでは、すべてのコンポーネント・イベントが認識されます。
JhoInjectType	データをコントロールに送信する際にJHOが使用する注入タイプを確認します。このフラグは、次の値のいずれかをとります。 · INJECT_TYPE_DEFAULT = 0 · INJECT_TYPE_METHOD = 1 · INJECT_TYPE_ACCESSIBLE = 2 · INJECT_TYPE_NONACCESSIBLE = 3 · INJECT_TYPE_ROBOT = 4 デフォルトでは、このフラグにINJECT_TYPE_DEFAULTが設定され、その場合、JHOは次の各方法を、ここに示す順に、注入が成功するまで試みます。 ·INJECT_TYPE_METHOD(コントロールに適切な設定方法が検出された場合) · INJECT_TYPE_ACCESSIBLE (コントロールでアクセシビリティがサポートされている場合) ·INJECT_TYPE_NONACCESSIBLE · INJECT_TYPE_ROBOT 注意: コンボ・ボックスおよびリスト・ボックスの場合、JHOは常にINJECT_TYPE_METHODを使用します。

2.14.5.2.2 推奨されるJHOイベント・レスポンス構成のデフォルト

Logon Managerの新規インストールでは、次のデフォルト設定をお薦めします。

• JhoWindowEventProcessing=0x3

• JhoComponentEventProcessing=0xB

• JhoHierarchyEventProcessing=0x0

これらの値は、次のイベントを認識するようにJHOに指示します。

• WINDOW_EVENT_OPENED (0x1)

• WINDOW_EVENT_CLOSED (0x2)

• COMPONENT_EVENT_SHOWN (0x1)

• COMPONENT_EVENT_HIDDEN (0x2)

• COMPONENT_EVENT_REMOVED (0x8)