web-dev-qa-db-ja.com

ASP.NET Core 2 Webアプリケーションがデバッグ時にユーザーシークレットを読み込まないIIS Webサイト

注：この問題は解決されました-解決策については、以下のUpdate 3を参照してください。

SQL Serverデータベースに接続する必要があるASP.NET Core 2 Webアプリがあります。以下のUpdate 2に従って、IISでアプリをデバッグしています。

私はProgramクラスに設定をロードしています（ロギングを設定するために必要なので）：

_public static IConfiguration Configuration => new ConfigurationBuilder()
    .SetBasePath(Directory.GetCurrentDirectory())
    .AddJsonFile("appsettings.json", optional: false, reloadOnChange: true)
    .AddJsonFile($"appsettings.{EnvName ?? "Production"}.json", optional: true)
    .AddUserSecrets<Startup>(false)
    .Build();
_

私のBuildWebHostメソッドは次のようになります：

_public static IWebHost BuildWebHost(string[] args)
{
    return WebHost.CreateDefaultBuilder(args)
        .UseStartup<Startup>()
        .UseConfiguration(Configuration)
        .UseSerilog()
        .Build();
}
_

私の_appSettings.json_ファイルには次のセクションがあります：

_{
  "ConnectionStrings": {
    "DefaultConnection": "*****" // secret
  }
}
_

Visual Studioのコンテキストメニューを使用してプロジェクトにユーザーシークレットファイルを追加しました。上記のセクションを複製していますが、実際の接続文字列を使用しています。

これがすべて整ったら、私のコードは接続文字列の形式に関する例外をスローします。ただし、メインの_appSettings.json_ファイルの「*****」を実際の接続文字列に置き換えると、アプリケーションは正常に動作します。だから私はそれが私のユーザーの秘密をロードしていないと思います。

さて、AddUserSecretsのオーバーロードを使用して引数falseを渡すと、ユーザーのシークレットを読み込めなかった場合にコードが壊れるのではないかと考えました。しかし、それはここで壊れていません。他に何ができるかわかりません。 ASP.NET Coreがユーザーシークレットを読み込めない原因は何ですか？

更新1

デバッグすると、Configurationプロパティ内に、期待する3つのプロバイダーがあることがわかります：_appsettings.json_、_appsettings.Development.json_、および_secrets.json_。ただし、シークレットプロバイダーのファイルルートはデバッグパスであり、シークレットファイルの場所ではありません。つまり、C：\ Users [username]\AppData\Roaming\Microsoft\UserSecrets ...です。

enter image description here

更新2

Webプロジェクトのデバッグ設定がIIS ApplicationPoolIdentityユーザーで実行されているアプリケーションプールを使用するサイト）でポイントされていることに気付きました。これは、ユーザーシークレットの必要性を意味する可能性があります自分のユーザーアカウントではなくC：\ Users [app-pool-user]\AppData\Roaming\Microsoft\UserSecretsの下にありますか？この場所にGUIDという名前のsecrets.jsonフォルダーを文字通りコピーしようとしましたが、助けにはなりませんでした。しかし、IIS Expressで実行するように変更しようとしましたが、今回はユーザーシークレットが読み込まれます。しかし、さまざまな理由からIISコンテキストでユーザーシークレットを読み込むにはどうすればよいですか？メインのWindowsを使用するようにアプリプールを変更しようとしました。特定のドメイン名でこのアプリケーションをデバッグできるようにする必要があります。 AppPoolIdentityではなくuserですが、これは役に立ちませんでした。

更新3：解決済み

さて、私は今日何かを学びました！最終的には ここでの答え が私の問題を解決しましたが、私が期待した方法ではありませんでした。 IISでホストすることで実現したので、元の問題-ユーザーシークレットの読み込みから移行しました。私は基本的に、一時的なデバッグセッションではなく展開で作業していたため、ユーザーシークレットを移動しました環境変数（たとえば、接続文字列の例では、システム環境変数_ConnectionStrings:DefaultConnection_を追加）とAddEnvironmentVariables()を構成設定に追加します。しかし、何らかの理由で、これらはまだ私の構成に読み込まれています。最後に this SO post that IIS=ここで変数を追加すると問題が解決し、秘密を安全に保ちながらIIS=でローカルにホストしてデバッグできるようになります。

c#asp.net-coreasp.net-core-2.0
14
getsetcode

IISで実行している場合、secrets.jsonはサイトの物理パスにあると予想されます。

5
kraihn

ほとんどのドキュメントは、IIS Expressを使用していることを前提としており、開発マシン上のローカルIISインスタンスのシナリオをカバーしていません。

IISアプリケーションプールは制限付きの権限で実行されます（たとえば、デフォルトで[user]\desktop\ExpenseReport.xlsを読み取ることができるとどうなるかを想像してください）。したがって、シークレットが必要です。 jsonはWebサイトフォルダー内のどこかに配置します。これを.gitignoreファイル（または代替）に追加しても、「秘密」のままであることを確認してください。

0
Milen