Server-seitiges Caching von Ansprüchen mit Owin-Authentifizierung
Ich habe eine Anwendung, die früher verwendet wurdeFormsAuthentication
, und vor einiger Zeit habe ich es auf das umgestelltIdentityModel
vonWindowsIdentityFramework
Damit ich von der anspruchsbasierten Authentifizierung profitieren konnte, war es jedoch ziemlich hässlich, sie zu verwenden und umzusetzen. So, jetzt schaue ichOwinAuthentication
.
Ich schaue aufOwinAuthentication
und dasAsp.Net Identity
Rahmen. Aber dieAsp.Net Identity
Frameworks einzige Implementierung im Moment verwendetEntityModel
und ich benutzenHibernate
. Im Moment versuche ich es also mit der UmgehungAsp.Net Identity
und benutze einfach dieOwin Authentication
direkt. Ich konnte endlich ein funktionierendes Login bekommen, indem ich die Tipps von "Wie kann ich die Identity Framework-Magie ignorieren und einfach die OWIN-Authentifizierungs-Middleware verwenden, um die von mir gesuchten Ansprüche zu erhalten?", aber jetzt ist mein Cookie mit den Behauptungen ziemlich groß. Als ich das verwendeteIdentityModel
Ich konnte einen serverseitigen Caching-Mechanismus verwenden, der die Ansprüche auf dem Server zwischengespeichert hat, und der Cookie enthielt nur ein einfaches Token für die zwischengespeicherten Informationen. Gibt es eine ähnliche Funktion inOwinAuthentication
, oder müsste ich es selbst implementieren?
Ich gehe davon aus, dass ich in einem dieser Boote sein werde ...
Der Cookie bleibt 3 KB groß, na ja, er ist etwas groß.Aktivieren Sie eine ähnliche Funktion wieIdentityModel
's SessionCaching inOwin
das weiß ich nicht.Schreiben Sie eine eigene Implementierung, um die Informationen, die das Aufblähen des Cookies verursachen, zwischenzuspeichern und zu prüfen, ob ich sie bei der Konfiguration anschließen kannOwin
beim Start der Anwendung.Ich mache das alles falsch und es gibt einen Ansatz, an den ich nicht gedacht habe oder in dem ich etwas missbraucheOwin
.
public class OwinConfiguration
{
public void Configuration(IAppBuilder app)
{
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
AuthenticationType = "Application",
AuthenticationMode = AuthenticationMode.Active,
CookieHttpOnly = true,
CookieName = "Application",
ExpireTimeSpan = TimeSpan.FromMinutes(30),
LoginPath = "/Login",
LogoutPath = "/Logout",
ReturnUrlParameter="ReturnUrl",
SlidingExpiration = true,
Provider = new CookieAuthenticationProvider()
{
OnValidateIdentity = async context =>
{
//handle custom caching here??
}
}
//CookieName = CookieAuthenticationDefaults.CookiePrefix + ExternalAuthentication.ExternalCookieName,
//ExpireTimeSpan = TimeSpan.FromMinutes(5),
});
}
}
AKTUALISIEREN Mit den Informationen von Hongye konnte ich den gewünschten Effekt erzielen und fand die folgende Logik ...
Provider = new CookieAuthenticationProvider()
{
OnValidateIdentity = async context =>
{
var userId = context.Identity.GetUserId(); //Just a simple extension method to get the ID using identity.FindFirst(x => x.Type == ClaimTypes.NameIdentifier) and account for possible NULLs
if (userId == null) return;
var cacheKey = "MyApplication_Claim_Roles_" + userId.ToString();
var cachedClaims = System.Web.HttpContext.Current.Cache[cacheKey] as IEnumerable<Claim>;
if (cachedClaims == null)
{
var securityService = DependencyResolver.Current.GetService<ISecurityService>(); //My own service to get the user's roles from the database
cachedClaims = securityService.GetRoles(context.Identity.Name).Select(role => new Claim(ClaimTypes.Role, role.RoleName));
System.Web.HttpContext.Current.Cache[cacheKey] = cachedClaims;
}
context.Identity.AddClaims(cachedClaims);
}
}