Azure App Service へのデプロイ

Power Portals Proポータルは、どのスタックを選んでも単一の ASP.NET Coreアプリケーションなので、デプロイは普通のApp Serviceへの通常の dotnet publish です。このページでは、作成すべきリソース、ポータルが読み取る設定、デフォルトとして推奨するもの、そしてPower Portals Pro特有のいくつかのステップについて説明しています。これは ASP.NET Coreに特有ではないものです。

展開するもの

両方のテンプレートは1つのウェブアプリケーションと1つの公開出力を生成します。独立したフロントエンドホストは存在せず、静的サイトリソースも、2つ目のApp Serviceも存在しません。

• Blazor — アプリをホストするサーバープロジェクトです。 Server または Auto のインタラクティビティの下では、Blazor SignalR回線もサービスを提供します。 WebAssembly ではクライアントバンドルとクライアントが呼び出す /api/* エンドポイントにもサービスを提供します。
• React — dotnet publish クライアントプロジェクトのViteビルドを実行し、その dist/ をホストの wwwrootに段階化するため、1つの ASP.NET コアホストが単一の発信元からSPAとAPIをサービスします。追加の配線作業はありません。

注記

Reactのパブリッシュはnpmに出力されるため、Nodeはdotnet publish動作するマシン、つまりノートパソコンかビルドエージェントにインストールしなければなりません。テンプレートのクライアントはNode ^20.19.0 || >=22.12.0を求めます。App Service自体はNodeを必要としません。ビルドされた出力だけを認識します。

推奨されるデフォルト

ルールではなく出発点ですが、新しい制作ポータルとして選ぶのはこういうことです。

• オペレーティングシステム:Linux。 階層ごとのコストが安く、開始も早く、IISや web.config を完全に排除できます。組織がWindowsを標準化していれば問題なく動作します。
• ランタイムスタック:.NET 10。 テンプレートは net10.0をターゲットにしています。フレームワーク依存のパブリッシュをし、App Serviceにランタイムを提供させます。
• プラン:B3 — すべての環境、本番環境も含めて。 B3はBasic: Always Onの最上位で、4コア、7GBなので、ポータルは最初の本格負荷で制限を満たすのではなく、ヘッドルームから始まります。後から階層を変えるのは、再デプロイなし、意味のあるダウンタイムもないコマンド1つで、開発やテスト環境ならB1まで下がり、スペースを必要としません。Basicが提供しないもの:デプロイスロットとオートスケーリング(どちらもStandardから始まります)です。S1とP0v3はLinuxで通常安価でメモリも多いです。
• 常時オン:オン。 App Serviceはアイドルアプリをアンロードし、コールドスタートはDataverseへの再接続とメタデータやローカリゼーションキャッシュの再構築を意味します。静かな期間の後、最初の訪問者がすべての費用を支払います。
• HTTPSのみ:オン、最低TLS 1.2、HTTP/2有効。 ポータルは認証クッキーを発行します。普通のHTTPを受け入れる理由はありません。
• ウェブソケット: Blazor ServerまたはAutoでオン。 オフは App Serviceのデフォルトで、これがないと回路は静かに長いポーリングに戻ってしまいます。
• セッションアフィニティ: Blazor ServerやAutoではオン — 回線が1つのインスタンスに属します。ReactやBlazor WebAssemblyポータルは オフ にしてください。これらはHTTP上でステートレスであり、アフィニティはインスタンスのバランスを崩すだけです。
• Key Vault内の秘密は、アプリ設定から参照されます。 App Serviceに管理IDを与え、その設定をVaultに向けて、秘密が設定ブレードやデプロイメントスクリプトに入らないようにしましょう。
• デプロイメントスロットを使った瞬間やインスタンスを1回を超えてスケールするとすぐにBlob Storageにデータ保護キーを入れます。デフォルトのキーリングはスロットごとに割り当てられ、スワップすると全員がサインアウトされます。
• WEBSITE_RUN_FROM_PACKAGE=1: オプションであり、それだけの価値があります。デプロイメントは原子的になり、コンテンツディレクトリは読み取り専用になります。ポータルはコンテンツのルートからのみ読み込むため、何も壊れません。アップロードバッファはシステム一時フォルダを通じて記録可能で、書き換え可能なままです。
• アプリケーションインサイト:オン。 フレームワークはライセンス拒否やDataverseの障害を ILoggerを通じて記録します。シンクがなければ、望ましい瞬間にログストリームを手作業で読み込むことになります。

1. アプリサービスの作成

3つのコマンドです。自分の名前を置き換えてください — このページ全体で使われ myportal 。

ウェブアプリ名は https://myportal.azurewebsites.net になり、グローバルに一意でなければなりません。意図的に選んでください。カスタムドメインを前に付けない限り、ライセンスキーが割り当てられるURLになります。

2. プラットフォームオプションの設定

これらはポータルとしてデフォルトが間違っている人たちです。

• --web-sockets-enabled true — はBlazor ServerおよびAutoで必要です。ReactやWebAssemblyポータルでは無害で、回路を開かないため。
• --client-affinity-enabled — Blazor ServerとAutoには true を残し、ReactとBlazor WebAssemblyにはパス false してインスタンス間で均等にリクエストを分散させます。
• --always-on true — ベーシックティア以上。無料プランや共有プランでは利用できません。

3. 構成

App Serviceのアプリケーション設定は環境変数として届き、 appsettings.jsonを上書きします。まさにあなたが望む通りです:ファイルはそのままにして、ここで環境ごとの値を設定してください。

重要

ユーザーの秘密は移動しません。 開発中に保存したすべての dotnet user-secrets はマシン上だけに残ります。それらのキーはすべてアプリケーション設定やKey Vault参照として再作成しなければならず、そうでなければ展開したアプリは起動しません。

セクション区切りにはダブルアンダースコアをつけてください:D365:ClientIdD365__ClientIdになります。コロンフォームはWindows App Serviceでは動作しますがLinuxでは使えないため、__フォームはどこでも使うべきです。

常に必要です

• D365__Url — Dataverse環境のURL、例えば https://yourorg.crm.dynamics.com。秘密ではありません。
• D365__ClientId — ポータルがDataverseに接続しているEntraアプリ登録のクライアントID。秘密ではありません。
• D365__ClientSecret — その登録のクライアント秘密。秘密:キー・ボールトの参照を使う。
• D365__EmailSenderEmailAddress — ポータルがアカウント確認やパスワードリセットメールをDataverse経由で送信する送信先アドレス。 appsettings.json に入っておらず、アプリが起動しないと起動しないため、最も忘れやすいものです。
• ASPNETCORE_ENVIRONMENT — Productionに設定してください。これはエラーページを変えるだけでなく、ReactポータルではSPAのフォールバックがDevelopmentの外に登録されているため、 Development に残ったサイトはアプリを提供する代わりに http://localhost:5173 への深いリンクをリダイレクトします。

そのサインインプロバイダーを有効にした場合は必須です

• Authentication__Microsoft__ClientId そして Authentication__Microsoft__ClientSecret — サインイン登録であり、これはDataverseのものとは 異なる アプリ登録です。 Entra IDサインインを参照してください。
• Authentication__Google__ClientId そして Authentication__Google__ClientSecret。
• Authentication__Facebook__AppId そして Authentication__Facebook__AppSecret。

オプション

• Azure__Translation__Key、 DeepL__Translation__Key または Google__Translation__Key — 登録した機械翻訳プロバイダーのいずれかです。設定を解除すると、ローカリゼーション管理者ページは単に翻訳パネルを非表示します;ページの他の部分は引き続き動作します。
• Security__SystemAdminRoleName — Dataverseのセキュリティロールで、ポータル管理者にアクセス権を与える。 appsettings.jsonに納入され、環境ごとにロール名が異なる場合はここで上書きします。

注記

必要なキーは GetRequiredValueで読み取られるため、欠けているキーは起動時にスローされ、最初のDataverse呼び出しで失敗することはありません。App Serviceでは、ログストリームを読み込み、例外でキー名を付けます。

4. ポータルに送信先のアドレスを与える

D365__EmailSenderEmailAddress アカウント確認やパスワードリセットメールの元であり、フレームワークはそのアドレスを持つDataverseユーザーを探し、次に キュー、そしてチームを解析します。 キューを使いましょう。 アドレスはExchange Onlineで 共有メールボックス が必要で、ライセンスは必要ありません。その他はすべてDataverseで行われます。設定を実際の人物に向けると、3つのコストがかかります:

• その人の名前はすべての自動メッセージに記載されています。 受信者は、送信していないパスワードリセットの送信者として同僚を認識します。
• 返信は受信箱に届きます。 返信しないメールには返信する人もいますが、その返信は誰も見ていない場所に送られます。
• ポータルは彼らが去ると壊れます。 アカウントを無効にすると送信者も一緒に消え、アカウント確認が静かに機能しないという失敗が表面化します。

4つのステップがあります:Exchangeで1つ、次にDataverseで3つです。 MCPサーバー は create_email_queueとの1回の通話で3つのDataverseステップを実行し、メールが届かない場合にどのステップが抜けているか check_email_sender 指示します:

1. アドレスを含んだ共有メールボックスをExchange管理センター(受信者→メールボックス→共有メールボックスを追加)で作成します。ライセンスは不要です。サーバー側の同期が送信するものなので、ライセンスがなければ最後のステップでリモートサーバーのメールボックス設定検証に関するエラーが出て失敗します。
2. アドレス(例:noreply@contoso.com)、受信配信なし、送信配信サーバーサイド同期でプライベートキューを作成します。キューの名前は受信者が送信者として認識するものなので、人ではなくポータルの名前で呼びます。
3. アドレスを承認してください。 2つのフラグが一致しなければならず、それらは異なるレコードに保存されます:キュー自身のメールアドレス承認と 、O365管理者によるメールボックスの承認です。キューは両方で保留中が作成され、2つ目の承認はOffice 365のグローバル管理者またはExchange管理者のみが承認できます。
4. Power Platform管理センターの設定→→メール設定→メール設定メールボックスを有効にしてください。アドレスから自分自身にテストメッセージを送信し、メールボックスは成功してから送信します。create_email_queue実行して結果を報告します。

重要

未承認またはテストされていないメールボックスは静かに失敗します。 Dataverseはメールを受け取り、記録し、配信しません。ポータル側から見ると、送信成功と区別がつきません。何もスローも記録されず、エラーとして記録されず、問題の最初の兆候は確認リンクを受け取っていないと言うユーザーです。登録メールが届かない場合は、まずメールボックスの 送信状況 を確認してください。実行 しない(Not Run )はテストが実行されず、 Failure(失敗 )はリモートサーバーでのメールボックス設定検証に関するアラートが出ることを意味します。 check_email_sender は両方のメールボックスを報告し、メールボックスのアラートも共有します。

5. 秘密をキーヴォールトに保管すること

アプリに管理されたアイデンティティを与え、ボールトへの読み取り権限を付与し、各シークレットのURIをシークレット自体ではなくアプリ設定に配置してください。App Serviceが参照を解決し、その値は設定ブレードやスクリプト、デプロイログには一切現れません。

クライアントのシークレットが期限切れになったら(Entraはデフォルトで1年)、新しいバージョンをボールトに追加し、アプリを再起動します。アプリ設定自体は変わりません。

MCPサーバーはこの一連の流れを行います。create_managed_identityユーザー割り当てのアイデンティティを作成し、それをアプリにアタッチenable_managed_identity、create_key_vaultボールトを作成し、そのIDに読み込み権限を与え、シークレットツールがdestination: "key-vault"を受け入れます。これにより、Entraから新たに作成されたクライアントシークレットが直接ヴォールトに送信され、アプリ設定には参照だけが残ります。その値は決して文字通りの設定にはならず、誰の手にも渡りません。ユーザーシークレットに既にあるシークレットはpush_secrets_to_key_vaultに同行し、コピーされる前に各エントリーにチェックを入れ、対応するアプリ設定をその人に向けます。check_deploymentはすべての参照のシークレットが存在し、アプリのアイデンティティがそれを読み取れるかを確認します。

重要

Key Vaultの名前は削除後90日間予約されます。 ソフト削除はデフォルトでオンでオフにできないため、Vaultを削除しても名前が解放されません。同じ名前のウィンドウ内で再作成するには明確なパージが必要で、それ自体が許可が必要で不可逆的です。ここで唯一、安価に取り消せるリソースなので、App Serviceの名前と同じくらい意図的に名前を選んでください。

注記

さらに良いのは、Dataverseクライアントの秘密を完全に削除することです。 管理されたアイデンティティのクライアントIDに D365__ManagedIdentityId 設定すると、ポータルはそのIDとしてDataverseに認証され、秘密はなく、期限切れもありません。環境チェックもビルドスイッチもありません。設定はApp Serviceの設定に存在し、 appsettings.jsonではなく、ローカルには存在し、デプロイ時には存在し、どちらのビルドも正しく動作します。 ユーザー割り当て のIDを使う — システム割り当てのIDはアプリと共に作成・破棄され、デプロイスロットごとに異なるため、アプリを再構築すると新しいIDが作成され、Dataverseアプリケーションユーザーは古いIDを基に構築されてしまいます。アイデンティティは依然としてそのアプリケーションユーザーを必要とし、Azureポータルが最初に表示するプリンシパルIDではなく、 アプリケーション IDから作成されます。これはApp ServiceとDataverse環境が 同じEntraテナントに属している場合にのみ適用されます。もしそうでない場合は、下記の「 When Dataverse is another tenants 」を参照してください。

Dataverseが別のテナントにいる場合

上記のすべては、App ServiceとDataverse環境が同じEntraテナントに属することを前提としています。これは組織が独自のポータルをホストする場合の一般的なケースです。もしあなたがポータルを運営し、顧客がDataverse環境を所有している場合、 彼らは異なるテナントに属し、アイデンティティアドバイスが変わります。

重要

マネージドIDは、他のテナントでDataverseに認証することはできません。 そのサービスプリンシパルはサブスクリプションのテナントに属しており、他の誰かのテナントに同意できないため、顧客のDataverseがアプリケーションユーザーを作成する理由はありません。この形で単独で D365__ManagedIdentityId を設定しないでください。ポータルはトークンを受け取り、すべての通話で拒否され、誤ったアイデンティティではなく、壊れたセキュリティロールのように見えます。ただし、複数テナントアプリ登録の 認証 情報としてテナント間を越えるものとして、下記の最初のオプションを参照してください。

ポータルはアプリの登録としてサインインし、顧客のテナントがサービスプリンシパルを持っています。その仕組みには3つの方法があり、認証情報の有効期間を管理する人によって異なります。

• マルチテナント登録を所有している場合 — 推奨。 自分のテナント内で作成し、 signInAudience を AzureADMultipleOrgsに設定し、Microsoft Graphの委任 User.Read 権限と返信URLを付けます。管理者の同意は両方なしの登録を拒否しますが、ポータルはどちらも使わず(新たに追加create_dataverse_app_registration )。秘密はテナントから離れず、シー クレットがいつローテーションしいつ期限切れになるかは自分で決め ます。これが重要な違いです。なぜなら、失禁したシークレットはポータルをダウンさせ、それを防げる人が呼ばれるオプションだからです。 さらに良いのは、シークレットを一切付与しないことです。 フェデレーテッド認証情報は、登録がユーザー割り当ての管理IDをあなたのものの代わりに受け入れることを可能にします(add_app_registration_federated_credential 追加);IDをApp Serviceに紐付け、 D365__ClientId を登録に設定し、顧客のテナントに D365__TenantId 、 D365__ManagedIdentityId をIDのクライアントIDに設定します。ポータルはそのIDのトークンを持つアプリであることを証明し、何も期限切れになりません。
• 顧客が自分のテナント内で作成する登録です。 一部の組織ではこれを義務付けており、サポートされています。コストとしては、認証情報の有効期間が相手のものになるため、秘密が切れるとポータルは停止し、更新できません。この方法を選ぶ前に、誰が有効期限を監視しているかを合意してください。
• Power Portals Pro自身の登録 — Power Portals Proがポータルをホストしている場合。 顧客は登録を作成しません。管理者はPower Portals Proに同意し、クライアントIDは 46c0b100-f468-4bfc-ba89-d128bceabe31、Dataverseはそのアプリケーションユーザーを取得します。Power Portals ProのホスティングはマネージドIDでサインインするため、保存、ローテーション、期限切れの秘密はありません。自分で運営するポータルではこのオプションはありません。なぜなら、Power Portals Pro自身のホスティングのみがサインインできるからです。同意リンクは https://login.microsoftonline.com/organizations/adminconsent?client_id=46c0b100-f468-4bfc-ba89-d128bceabe31&redirect_uri=https%3A%2F%2Fpowerportalspro.com%2Fです。

どちらを選ぶにせよ、 顧客の テナントの管理者は一度登録に同意しなければなりません。それがサービスプリンシパル(クライアントIDを含むオブジェクト)を作り出し、Dataverseがアプリケーションユーザーをバインドできるオブジェクトです。こちらのリンクを送ってください:

重要

同意はアプリケーションの先に行い、後からではありません。 同意が行われるまでは顧客のテナントにサービスプリンシパルが存在しないため、Dataverseアプリケーションユーザーの作成は、テナントや同意が記載されていない未知のアプリケーションに関するエラーで失敗し、この道筋で最も混乱を招くポイントです。このステップは彼らの代わりに行うことはできません。これは彼らのテナントが所有していない登録へのアクセスを許可しているため、あなたの権限ではなくテナントの権限が必要です。

その秘密はアプリケーション設定ではなくKey Vaultに入れてください。それは他人のデータに対する認証情報であり、設定はアプリにContributorがある誰でも読み取れ、設定のエクスポートとともに移動します。もし報告しなければ check_deployment が報告します。

6. 公開

フレームワーク依存のPublishを、出力をzipし、zipをプッシュします。Reactポータルでは同じ dotnet publish がSPAを構築し、 wwwrootにステージ化します。

Zipフォルダーの 内容 はzipで削除してください。フォルダ自体ではなく、App Serviceはアーカイブを直接サイトルートにアンパックするため、入れ子状のトップレベルディレクトリは何もサービスしないサイトを生成します。

Visual Studioの Publish ダイアログもインタラクティブに同じことを行い、GitHub ActionsやAzure Pipelinesのワークフローはプッシュ時に行います。Reactポータルの追加ステップは、ビルドより先行してNodeを設定するステップだけです。なぜなら dotnet publish はnpmに出力されるからです。

7. ライセンスをデプロイされたURLに向ける

ウェブサイトのライセンスはURLにバインドされています。Power Portals Proのモデル駆動アプリで、ライセンスキーを保持した Portal Website レコードを開き(または作成)、その URL を展開したポータルの本番URL( https://myportal.azurewebsites.net、またはカスタムドメインが先にある場合は)に設定してください。

本番環境のURLのみ登録してください。バリデーションは-dev、-test、-uat、-stage、-prodの接尾辞ホストも受け入れており、リードサブドメインとして同じ5つも受け入れるため、他の環境では別個のレコードは不要です。ライセンスページには完全なリストがあります。

重要

トラフィックを送信する前にこれを行ってください。すべてのデータサービングエンドポイントはライセンスを確認するため、レコードが存在しホストと一致するまではポータルはレンダリングしますが、すべてのデータ呼び出しは 402返されます。

8. 生産リダイレクトURIを追加する

ポータルがMicrosoftのサインインを提供している場合、サインインアプリの登録は依然としてローカルホストのリダイレクトURIしか認識しません。そこにデプロイされたURIを追加してください。Entraは複数のURIを受け入れているので、ローカルのURIは動作し続けます:

他のプロバイダーもそれぞれのコールバックパス(/signin-google、 /signin-facebook)で同じパターンです。環境ごとに1つ、カスタムドメインごとに1つずつ追加してください。

展開枠

ステージングスロットとスワップは、ウォームアップされたアプリと即座のロールバックを提供します。これらはBasicを離れる価値のある唯一の理由であり、必要な時に置いておくべき理由でもあります。注意が必要な点が二つあります。

データ保護キーはスロットごとに割り当てられています。 ASP.NET Coreはキーリングをその %HOME%に永続化し、各スロットにはそのコピーがあるため、スワップで置き換えられ、前のスロットで発行された認証クッキーはすべて復号不可能になります。全員がログアウトされます。キーリングを両方のスロット共有する場所に移動させてから、スワッピングに頼る前に:

環境固有の設定をスロット設定としてマーク し、スワップ中も残るようにしてください。Dataverse環境のURLが問題です。URLがなければ、サンドボックスを指すステージングスロットを交換すると、そのサンドボックス接続が本番環境に進みます。

拡大

拡大は必要性を測る際に決めるべきもので、プロビジョニング時ではありません。デフォルトティアの一つのインスタンスは、驚くほど多くのポータルトラフィックを運んでいます。

• Blazor Server / Auto: セッションアフィニティをオンにし、自社回線を測定する前に、1回の並行回線あたり約250KB のサーバーメモリを予算化しましょう。Azure SignalR ServiceはApp Service上で必須ではありません。非常に多くの接続数やグローバルに分散したユーザー向けのツールです。
• React / Blazor WebAssembly: セッションアフィニティをオフにして横方向にスケールします。リクエストはステートレスなので、インスタンスは互換性があります。
• テンプレートは AddDistributedMemoryCache()レジスタをします。これはインスタンスごとにです。複数のインスタンスで、メタデータやローカライゼーションキャッシュを各インスタンスで再構築するのではなく共有できるように、実際の分散キャッシュに交換してください。

これらすべてをAIエージェントから行う

Power Portals Pro MCPサーバー はこのページのすべてのステップを実行できます。フォルダを一度、ターミナルでサブスクリプションに割り当ててください。バインドはそのフォルダに属しているので、複数のプロジェクトが同時に異なる顧客をターゲットにでき、マシン全体での変更はありません。

• check_deployment — 最初に手を伸ばすべきもの。プロジェクトに必要なものとApp Serviceのものを比較し、問題点を指摘します:ユーザーシークレットにのみ存在していた必須設定、開発に残された環境、BlazorポータルでWebSocketをオフにしている、ホストをカバーしないPortal Websiteレコード、Dataverseにアクセスできないポータル。読み取り専用で、本番環境に対して安全に実行できます。
• get_deployment_plan — すべてのプランのステップと、Azureの公開価格表から実際の現在の価格が記載されています。
• create_app_service — リソースグループ、プラン、ウェブアプリ、WebSocketsとアフィニティペアがすでにスタックに設定されています。
• set_app_service_settings — 設定を置き換えるのではなく統合するため、秘密を保持している設定を消去できません。
• deploy_to_app_service — dotnet publish を積み重ね、結果を押し進めます。
• create_dataverse_app_registration、 create_signin_app_registration 、 add_app_registration_redirect_uri — ステップ6と7のEntra側で、自分のサインイン済みアカウントのディレクトリロールを使用します。作成されたクライアントシークレットはユーザーシークレットやApp Service設定に直接入り、表示されません。
• create_managed_identity、 enable_managed_identity 、 create_key_vault ――上のアイデンティティと金庫、あなたのために割り当てられ、それが伝播する間に再試される役割が記されています。
• get_deployment_plan また、この展開が2つのテナントにまたがるかどうかも明記されており、 create_dataverse_app_registration ホスト形態に対して登録の作成、管理者同意リンクの印刷、秘密を直接Vaultに入力するというもの multiTenant: true を処理します。
• create_email_queue — Step 4のノーレスポンド送信者キューは、Exchange Onlineで共有メールボックスが存在した後、1回の通話で作成、承認、テストされました。 check_email_sender 、なぜそこからのメールが届かないのか説明しています。

注記

Azureで何かを変更するすべてのツールは、確認を求められる前に何が起こるか、費用も含めて表示されます。これはあなたのリージョンの実際の月額であり、小売リストはあなたが持っているEnterprise Agreementや予約を無視しているという注意書きもあります。読み取りだけのツールはプロンプトを表示しません。サーバーはAzure CLIを使わず、サインイン状態を読み取ったり変更したりしません。

トラブルシューティング

• そのサイトは一度も表示されません。 通常は必須のアプリ設定が欠けています。スタートアップ例外はキー名を指定します — ログストリーム で読み取るか、 問題を診断して解決してください。
• ポータルは表示されますが、「一部のコンテンツは利用できません」という通知が表示され、ラベルは生キーとして表示され、データロードはありません。 ポータルはDataverseにサインインできません。ログには「 Dataverseに接続できません」 という一行で原因が記載されており、通常は期限切れや誤った D365__ClientSecret、または他のテナントからの D365__ClientId です。その間、 /health は回答 503 Unhealthyするため、App Serviceの健康チェックや稼働時間モニターがそれを認識し、 check_deployment も同様に尋ねます。
• ポータルはレンダリングされますが、すべてのデータ呼び出しは402を返します。 ライセンスチェックはホストを拒否しています。ポータルウェブサイトのレコードのURLがブラウザが実際に使用しているホストと一致し、管理ソリューションがポータルが接続する環境にインストールされているかを確認してください。拒否は検証された正確なホスト、転送されたホスト、スキームとともに記録されます。
• リダイレクトループや http:// 予想通りのURL https://。 アプリはApp Serviceのフロントエンドから転送されたヘッダーを尊重していません。リクエストスキームとクライアントIPが元のリクエストを反映するように ASPNETCORE_FORWARDEDHEADERS_ENABLED=true 設定してください。
• Blazorポータルのブラウザコンソールで「Long Pollingのフォールバックを使用してWebSockets経由で接続に失敗しました」 — App ServiceのWebソケットはまだオフのままです。
• 展開または交換後、全員がログアウトされます。 データ保護キーリングが変更されました。上記のデプロイスロットを参照してください。
• Reactは404をDeepリンクするか、localhostにリダイレクトします。ASPNETCORE_ENVIRONMENTはProductionではなく、SPAのフォールバックはDevelopmentの外でのみ登録されています。
• ログには何も役に立 たない。App Serviceアプリケーションログはデフォルトでオフになっている:情報レベルでファイルシステムのログをオンにし、その後 az webapp log tailでフォローする。