現在のApplicationUserをデータベースに直接問い合わせる必要はありません。
これは、初心者のための追加のコンテキストを持つという新しい依存関係を導入しますが、ユーザーデータベーステーブルの変更は(過去2年間で3回)変化しますが、APIは一貫しています。たとえば、users
テーブルがAspNetUsers
Identity Frameworkで呼び出され、いくつかの主キーフィールドの名前が変更され続けるため、いくつかの回答のコードはそのままでは機能しなくなります。
別の問題は、データベースへの基になるOWINアクセスが別のコンテキストを使用するため、別のSQLアクセスからの変更が無効な結果を生成する可能性があることです(たとえば、データベースに加えられた変更が表示されない)。再び溶液を、であるとの仕事提供するAPIとしようとしない仕事の周りにそれ。
(現時点で)ASP.Net IDの現在のユーザーオブジェクトにアクセスする正しい方法は次のとおりです。
var user = UserManager.FindById(User.Identity.GetUserId());
または、非同期アクションがある場合は、次のようになります。
var user = await UserManager.FindByIdAsync(User.Identity.GetUserId());
FindById
非同期UserManager
メソッドを使用できるようにするには、次のusingステートメントが必要です(これらはUserManagerの拡張メソッドであるため、これを含めないと、表示されるだけですFindByIdAsync
)。
using Microsoft.AspNet.Identity;
コントローラにまったくいない場合(IOCインジェクションを使用している場合など)、ユーザーIDは以下から完全に取得されます。
System.Web.HttpContext.Current.User.Identity.GetUserId();
標準のアカウントコントローラーを使用していない場合は、コントローラーに(例として)以下を追加する必要があります。
1.次の2つのプロパティを追加します。
/// <summary>
/// Application DB context
/// </summary>
protected ApplicationDbContext ApplicationDbContext { get; set; }
/// <summary>
/// User manager - attached to application DB context
/// </summary>
protected UserManager<ApplicationUser> UserManager { get; set; }
2.これをコントローラーのコンストラクターに追加します。
this.ApplicationDbContext = new ApplicationDbContext();
this.UserManager = new UserManager<ApplicationUser>(new UserStore<ApplicationUser>(this.ApplicationDbContext));
2015年3月の更新
注:Identityフレームワークの最新の更新により、認証に使用される基になるクラスの1つが変更されます。これで、現在のHttpContentのOwinコンテキストからアクセスできます。
ApplicationUser user = System.Web.HttpContext.Current.GetOwinContext().GetUserManager<ApplicationUserManager>().FindById(System.Web.HttpContext.Current.User.Identity.GetUserId());
補遺:
AzureでEFおよびIdentity Frameworkを使用する場合、リモートデータベース接続(Azureデータベースへのローカルホストテストなど)を介して、恐ろしい「エラー:19-物理接続は使用できません」にランダムにヒットする可能性があります。原因は、再試行を追加できないIdentity Framework(または欠落しているように見えるもの.Include(x->someTable)
)に隠れているため、SqlAzureExecutionStrategy
プロジェクトにカスタムを実装する必要があります。