問題の詳細を提供しますので、ご容赦ください...
認証、承認、役割/メンバーシップなどにFormsAuthentication
とカスタムサービスクラスを使用するMVCサイトがあります。
サインオンするには、次の3つの方法があります。(1)メール+エイリアス、(2)OpenID、および(3)ユーザー名+パスワード。 3つすべてがユーザーに認証Cookieを取得し、セッションを開始します。最初の2つは訪問者(セッションのみ)によって使用され、3つ目はdbアカウントを持つ作成者/管理者によって使用されます。
_public class BaseFormsAuthenticationService : IAuthenticationService
{
// Disperse auth cookie and store user session info.
public virtual void SignIn(UserBase user, bool persistentCookie)
{
var vmUser = new UserSessionInfoViewModel { Email = user.Email, Name = user.Name, Url = user.Url, Gravatar = user.Gravatar };
if(user.GetType() == typeof(User)) {
// roles go into view model as string not enum, see Roles enum below.
var rolesInt = ((User)user).Roles;
var rolesEnum = (Roles)rolesInt;
var rolesString = rolesEnum.ToString();
var rolesStringList = rolesString.Split(',').Select(role => role.Trim()).ToList();
vmUser.Roles = rolesStringList;
}
// i was serializing the user data and stuffing it in the auth cookie
// but I'm simply going to use the Session[] items collection now, so
// just ignore this variable and its inclusion in the cookie below.
var userData = "";
var ticket = new FormsAuthenticationTicket(1, user.Email, DateTime.UtcNow, DateTime.UtcNow.AddMinutes(30), false, userData, FormsAuthentication.FormsCookiePath);
var encryptedTicket = FormsAuthentication.Encrypt(ticket);
var authCookie = new HttpCookie(FormsAuthentication.FormsCookieName, encryptedTicket) { HttpOnly = true };
HttpContext.Current.Response.Cookies.Add(authCookie);
HttpContext.Current.Session["user"] = vmUser;
}
}
_
権限の単純なフラグ列挙:
_[Flags]
public enum Roles
{
Guest = 0,
Editor = 1,
Author = 2,
Administrator = 4
}
_
フラグ列挙型を列挙するのに役立つ列挙型拡張機能(すごい!)。
_public static class EnumExtensions
{
private static void IsEnumWithFlags<T>()
{
if (!typeof(T).IsEnum)
throw new ArgumentException(string.Format("Type '{0}' is not an enum", typeof (T).FullName));
if (!Attribute.IsDefined(typeof(T), typeof(FlagsAttribute)))
throw new ArgumentException(string.Format("Type '{0}' doesn't have the 'Flags' attribute", typeof(T).FullName));
}
public static IEnumerable<T> GetFlags<T>(this T value) where T : struct
{
IsEnumWithFlags<T>();
return from flag in Enum.GetValues(typeof(T)).Cast<T>() let lValue = Convert.ToInt64(value) let lFlag = Convert.ToInt64(flag) where (lValue & lFlag) != 0 select flag;
}
}
_
サービスは、認証されたユーザーのロールをチェックするためのメソッドを提供します。
_public class AuthorizationService : IAuthorizationService
{
// Convert role strings into a Roles enum flags using the additive "|" (OR) operand.
public Roles AggregateRoles(IEnumerable<string> roles)
{
return roles.Aggregate(Roles.Guest, (current, role) => current | (Roles)Enum.Parse(typeof(Roles), role));
}
// Checks if a user's roles contains Administrator role.
public bool IsAdministrator(Roles userRoles)
{
return userRoles.HasFlag(Roles.Administrator);
}
// Checks if user has ANY of the allowed role flags.
public bool IsUserInAnyRoles(Roles userRoles, Roles allowedRoles)
{
var flags = allowedRoles.GetFlags();
return flags.Any(flag => userRoles.HasFlag(flag));
}
// Checks if user has ALL required role flags.
public bool IsUserInAllRoles(Roles userRoles, Roles requiredRoles)
{
return ((userRoles & requiredRoles) == requiredRoles);
}
// Validate authorization
public bool IsAuthorized(UserSessionInfoViewModel user, Roles roles)
{
// convert comma delimited roles to enum flags, and check privileges.
var userRoles = AggregateRoles(user.Roles);
return IsAdministrator(userRoles) || IsUserInAnyRoles(userRoles, roles);
}
}
_
私はこれを属性を介してコントローラーで使用することを選択しました:
_public class AuthorizationFilter : IAuthorizationFilter
{
private readonly IAuthorizationService _authorizationService;
private readonly Roles _authorizedRoles;
/// <summary>
/// Constructor
/// </summary>
/// <remarks>The AuthorizedRolesAttribute is used on actions and designates the
/// required roles. Using dependency injection we inject the service, as well
/// as the attribute's constructor argument (Roles).</remarks>
public AuthorizationFilter(IAuthorizationService authorizationService, Roles authorizedRoles)
{
_authorizationService = authorizationService;
_authorizedRoles = authorizedRoles;
}
/// <summary>
/// Uses injected authorization service to determine if the session user
/// has necessary role privileges.
/// </summary>
/// <remarks>As authorization code runs at the action level, after the
/// caching module, our authorization code is hooked into the caching
/// mechanics, to ensure unauthorized users are not served up a
/// prior-authorized page.
/// Note: Special thanks to TheCloudlessSky on StackOverflow.
/// </remarks>
public void OnAuthorization(AuthorizationContext filterContext)
{
// User must be authenticated and Session not be null
if (!filterContext.HttpContext.User.Identity.IsAuthenticated || filterContext.HttpContext.Session == null)
HandleUnauthorizedRequest(filterContext);
else {
// if authorized, handle cache validation
if (_authorizationService.IsAuthorized((UserSessionInfoViewModel)filterContext.HttpContext.Session["user"], _authorizedRoles)) {
var cache = filterContext.HttpContext.Response.Cache;
cache.SetProxyMaxAge(new TimeSpan(0));
cache.AddValidationCallback((HttpContext context, object o, ref HttpValidationStatus status) => AuthorizeCache(context), null);
}
else
HandleUnauthorizedRequest(filterContext);
}
}
_
私はコントローラーのアクションをこの属性で装飾します。Microsoftの_[Authorize]
_のように、パラメーターがないということは、認証された人を誰でも入れることを意味します(私にとっては、列挙型= 0であり、必要な役割はありません)。
それは背景情報(おい)を締めくくる...そしてこれをすべて書き出すことについて私は私の最初の質問に答えた。この時点で、セットアップの適切性について興味があります。
手動で認証Cookieを取得し、HttpContext
のFormsIdentityプリンシパルにデータを入力する必要がありますか、それとも自動で行う必要がありますか?
属性/フィルターOnAuthorization()
内の認証のチェックに関する問題はありますか?
_Session[]
_を使用してビューモデルを保存することと、認証Cookie内でシリアル化することのトレードオフは何ですか?
このソリューションは、「関心の分離」の理想に十分従っているように見えますか? (より意見指向の質問であるためボーナス)
my CodeReview answer からのクロスポスト:
私はあなたの質問に答えるのを突き刺し、いくつかの提案を提供します:
web.config
でFormsAuthenticationを構成している場合は、Cookieが自動的にプルされるため、FormsIdentityを手動で入力する必要はありません。これは、どのような場合でもテストするのは非常に簡単です。
効果的な認証属性を得るには、AuthorizeCore
とOnAuthorization
の両方をオーバーライドすることをお勧めします。 AuthorizeCore
メソッドはブール値を返し、ユーザーが特定のリソースにアクセスできるかどうかを判断するために使用されます。 OnAuthorization
は返されません。通常、認証ステータスに基づいて他のものをトリガーするために使用されます。
Session-vs-cookieの質問が大部分は好みだと思いますが、いくつかの理由からセッションに参加することをお勧めします。最大の理由は、Cookieがすべてのリクエストで送信されることです。現在、Cookieにはほんの少しのデータしか含まれていない可能性があり、時間の経過とともに、そこに何を詰め込むかを知っている人がいます。暗号化のオーバーヘッドを追加すると、要求が遅くなるほど大きくなる可能性があります。セッションに保存すると、データの所有権もあなたの手に渡ります(クライアントの手に渡され、復号化して使用するのはあなたに依存するのではありません)。私が行う提案の1つは、セッションアクセスをUserContext
と同様に静的なHttpContext
クラスにラップすることです。これにより、UserContext.Current.UserData
のように呼び出すことができます。コード例については、以下を参照してください。
それが関心の分離であるかどうかははっきりとは言えませんが、私にとっては良い解決策のように見えます。これは、私が見た他のMVC認証アプローチと同じです。実際、私は自分のアプリで非常によく似たものを使用しています。
最後の質問-FormsAuthentication.SetAuthCookie
を使用する代わりに、FormsAuthenticationCookieを手動で作成して設定したのはなぜですか。ちょっと興味があるんだけど。
静的コンテキストクラスのサンプルコード
public class UserContext
{
private UserContext()
{
}
public static UserContext Current
{
get
{
if (HttpContext.Current == null || HttpContext.Current.Session == null)
return null;
if (HttpContext.Current.Session["UserContext"] == null)
BuildUserContext();
return (UserContext)HttpContext.Current.Session["UserContext"];
}
}
private static void BuildUserContext()
{
BuildUserContext(HttpContext.Current.User);
}
private static void BuildUserContext(IPrincipal user)
{
if (!user.Identity.IsAuthenticated) return;
// For my application, I use DI to get a service to retrieve my domain
// user by the IPrincipal
var personService = DependencyResolver.Current.GetService<IUserBaseService>();
var person = personService.FindBy(user);
if (person == null) return;
var uc = new UserContext { IsAuthenticated = true };
// Here is where you would populate the user data (in my case a SiteUser object)
var siteUser = new SiteUser();
// This is a call to ValueInjecter, but you could map the properties however
// you wanted. You might even be able to put your object in there if it's a POCO
siteUser.InjectFrom<FlatLoopValueInjection>(person);
// Next, stick the user data into the context
uc.SiteUser = siteUser;
// Finally, save it into your session
HttpContext.Current.Session["UserContext"] = uc;
}
#region Class members
public bool IsAuthenticated { get; internal set; }
public SiteUser SiteUser { get; internal set; }
// I have this method to allow me to pull my domain object from the context.
// I can't store the domain object itself because I'm using NHibernate and
// its proxy setup breaks this sort of thing
public UserBase GetDomainUser()
{
var svc = DependencyResolver.Current.GetService<IUserBaseService>();
return svc.FindBy(ActiveSiteUser.Id);
}
// I have these for some user-switching operations I support
public void Refresh()
{
BuildUserContext();
}
public void Flush()
{
HttpContext.Current.Session["UserContext"] = null;
}
#endregion
}
以前は、必要なユーザーデータにアクセスするためにプロパティをUserContext
クラスに直接配置していましたが、これを他のより複雑なプロジェクトに使用したため、SiteUser
クラス:
public class SiteUser
{
public int Id { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
public string FullName
{
get { return FirstName + " " + LastName; }
}
public string AvatarUrl { get; set; }
public int TimezoneUtcOffset { get; set; }
// Any other data I need...
}
あなたはこれで素晴らしい仕事をしていると思いますが、なぜあなたが車輪を作り直しているのか疑問に思います。マイクロソフトはこのためのシステムを提供しているため、メンバーシップおよびロールプロバイダーと呼ばれます。カスタムメンバーシップとロールプロバイダーを作成するだけで、独自の認証属性やフィルターを作成する必要がなく、組み込みのものを使用できます。
MVCカスタム認証、承認、および役割の実装は適切に見えます。最初の質問に答えるには、membershipproviderを使用していないときに、FormsIdentityプリンシパルを自分で入力する必要があります。私が使用する解決策はここに説明されています 私のブログ