アプリケーション リンクのトラブルシューティングのフローチャート

各アプリケーションに対して次のフローチャートの内容を確認することをおすすめします。両方のアプリケーションを確認してから次のチェックポイントに進みます。各チェックポイントの詳細な説明についてはフローチャートの質問をご確認ください。

applinksflow

用語

  • "ローカル": 確認中のアプリケーション
  • "リモート": もう片方のアプリケーション

トラブルシューティングのプロセスでは、両方のアプリケーションが "ローカル" および "リモート" として扱われます。

フローチャートの質問

アプリケーションの手前にリバース プロキシがありますか?

ここをクリックして展開...

各アプリケーションの server.xml ファイルを確認します。次の情報を確認します。

  • アプリケーションがユーザーのアクセス時とは異なるポートでリッスンしていますか?
    • 既定では、HTTP 接続にはポート 80 が、HTTPS 接続にはポート 443 が使用されます。
  • アプリケーションに、HTTP コネクタで定義されたプロキシが設定されていますか?
  • アプリケーションで AJP コネクタが定義されていますか?

ベース URL は適切ですか?

ここをクリックして展開...

各アプリケーションのベース URL が、ユーザーがアクセスするものに設定されている必要があります。これが異なる場合、各アプリケーションのベース URL を正しい値に更新します。

ローカルの "表示 URL" はリモートのベース URL に一致していますか?

ここをクリックして展開...

ローカル アプリケーションの "表示 URL" がリモート アプリケーションのベース URL と一致している必要があります。これが異なる場合、"表示 URL" が正しいベース URL を使用するように調整します。"表示 URL" はアプリケーション リンクの設定画面で編集可能なため、アプリケーション リンクを再作成する必要はありません。

ローカルの "アプリケーション URL" はリモート アプリケーションのベース URL に一致していますか?

ここをクリックして展開...

これはリバース プロキシをバイパスしていない場合にのみ適用されます。

アプリケーション リンクで、ローカルの "アプリケーション URL" の値がリモートのベース URL に一致していない場合、それを削除してアプリケーション リンクを再作成する必要があります。アプリケーション リンクの設定ダイアログで "アプリケーション URL" を編集することはできません。

ローカルのアプリケーション URL はリモート アプリケーションのプロキシされていない URL に一致していますか?

ここをクリックして展開...

これはリバース プロキシをバイパスしている場合にのみ適用されます。

このシナリオの場合、プロキシされていないコネクタが必要です。詳細については「アプリケーション リンクでリバース プロキシまたは SSL をバイパスする方法」をご参照ください。

アプリケーション リンクで、ローカルの "アプリケーション URL" の値がプロキシされていないコネクタに一致していない場合、それを削除してアプリケーション リンクを再作成する必要があります。アプリケーション リンクの設定ダイアログで "アプリケーション URL" を編集することはできません。

ローカルのすべての "Outgoing Authentication" 設定がリモートの "Incoming Authentication" 設定に一致していることを確認する

ここをクリックして展開...

アプリケーション リンクで使用される認証設定は同一である必要があります。次の点を確認します。

  • ローカル アプリケーションの "Outgoing Authentication" 設定で 1 種類の認証のみが選択されていること。
  • 設定が、リモート アプリケーションの "Incoming Authentication" 設定と同一であること。

OAuth について

これらの注意事項は OAuth を使用しているアプリケーション リンクにのみ適用されます。

  • "Execute As" オプションは "Incoming Authentication" 画面でのみ利用できます。
  • "Allow user impersonation through 2-Legged OAuth" オプションは "Incoming Authentication" 画面でのみ利用できます。
  • ローカル アプリケーションで "Enable outgoing 2-Legged OAuth requests" を選択した場合、リモート アプリケーションで "Allow 2-Legged OAuth" を選択する必要があります。
  • ローカル アプリケーションで "" を選択した場合、"Allow user impersonation through 2-Legged OAuth" を選択、または "Execute As" フィールドでユーザーを指定する必要があります。
  • 2-Legged OAuth オプションのいずれかを選択または指定しない場合、3-Legged OAuth が使用されます。

Network Time Protocol (NTP) 経由で時間が同期されていることを確認する

ここをクリックして展開...

ローカルおよびリモート アプリケーションが Network Time Server を使用していて、システム時刻が正しい値で同期されていることを確認します。これにより、2 つのアプリケーション間での通信中に証明書が失効する可能性を減らすことができます。

ご利用のオペレーティング システムのタイムゾーン定義に更新があった場合、それらがインストールされていることを確認します。これにより、各アプリケーションでタイムゾーンを適切に定義し、そのタイムゾーンでオフセットが利用されることを確実にできます。

リモート API が有効化されていることを確認する

ここをクリックして展開...

特定の製品横断機能を利用するためにリモート API の有効化が必要な場合があります。例として、次のようなものが含まれます。

  • Confluence のナレッジベース スペースからの検索結果を提供する Jira Service Desk
  • Confluence ページにリンクする Jira 課題
  • ガジェットでの Bamboo のプランやプロジェクトの表示
  • Stash の [Source] タブにあるリポジトリの Jira での表示

アプリケーション間ですべてではなく一部の機能が使用できない場合、各アプリケーションでリモート API を有効化することをお試しください。

最終更新日 2018 年 11 月 2 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.