1

Ich habe die Formularauthentifizierung in einem Projekt implementiert. Im Formular Authentifizierungs-Cookie speichere ich die Login-ID des Benutzers. das heißtWo kann ich den Formularauthentifizierungs-Cookie lesen?

FormsAuthentication.SetAuthCookie(LoginId, false); 

Ich brauche jetzt den Cookie-Wert bei jeder Anfrage lesen Weitere Informationen über den Benutzer zu erhalten und diese Informationen in der HttpContext.Items Eigenschaft setzen. Das Projekt ist ein MVC-Projekt, das sowohl reguläre MVC-Controller als auch Web-API-Controller hat. Derzeit habe ich zwei Aktionsfilter erstellt - einen für die MVC-Controller und einen für Web-API-Controller, in denen ich diesen Wert lese. So wie

public class MyMvcFilter : AuthorizeAttribute 
{ 
    public override void OnAuthorization(AuthorizationContext filterContext) 
    { 
     var cookie = HttpContext.Current.Request.Cookies[FormsAuthentication.FormsCookieName]; 
     if (cookie != null) 
     { 
      var ticket = FormsAuthentication.Decrypt(cookie.Value); 
      filterContext.HttpContext.Items.Add("LoginId",ticket.Name); 
     } 


     base.OnAuthorization(filterContext); 
    } 
} 

und

public class MyFilter : ActionFilterAttribute 
{ 
    public override void OnActionExecuting(HttpActionContext actionContext) 
    { 
     base.OnActionExecuting(actionContext); 

     var cookie = HttpContext.Current.Request.Cookies[FormsAuthentication.FormsCookieName]; 
     if (cookie == null) 
     { 
      return; 
     } 
     var ticket = FormsAuthentication.Decrypt(cookie.Value); 
     if (ticket == null) 
     { 
      return; 
     } 

     actionContext.Request.Properties.Add("LoginId", userId); 

    } 
} 

Doch je mehr ich davon, desto mehr sieht aus wie ein hässlicher Hack zu mir. Was wäre der korrekte Ort, an dem ich den Authentifizierungscookie entschlüsseln kann und derselbe für den MVC-Controller und den Web-API-Controller bleibt?

Antwort

1

tun das gleiche Material haben würde ich:

  1. das Cookie Lesen Sie auf der

    protected void Application_PostAuthenticateRequest(object sender, EventArgs e) 
    { 
    
    } 
    
  2. In dem obigen Verfahren .... Konvertieren das Cookie ein ClaimsPrincipal. Wie die unten:

    protected void Application_PostAuthenticateRequest(object sender, EventArgs e) 
    { 
    
    
    
        IList<Claim> claimCollection = new List<Claim> 
        { 
         new Claim("http://www.mycompany.com/claims/LoginId, "123456" /* use info from cookie instead of 123456*/) 
        }; 
    
        ClaimsIdentity claimsIdentity = new ClaimsIdentity(claimCollection, "My e-commerce website"); 
    
        Console.WriteLine(claimsIdentity.IsAuthenticated); 
    
        ClaimsPrincipal customPrinc = new ClaimsPrincipal(claimsIdentity); 
    
        if (null != customPrinc) 
        { 
         Thread.CurrentPrincipal = customPrinc; /* Set here. But when you need to "get" it, use "System.Security.Claims.ClaimsPrincipal.Current" */ 
         /* ASP.NET Authorization depends on value of HttpContext.Current.User. 
         * Consider putting ClaimsPrincipal into both HttpContext.Current.User and Thread.CurrentPrincipal */ 
         HttpContext.Current.User = customPrinc; 
    
         /* Note the second setter is necessary so you don't lose it later on, learned the hard way by experience */ 
        } 
    } 
    

den Haupt Ansprüche abrufen je nach Bedarf ..

/* MVC */ 
    public override void OnAuthorization(System.Web.Mvc.AuthorizationContext filterContext) 
    { 
     /* the below should be what you set in the Application_PostAuthenticateRequest method */ 
     IPrincipal currentClaimsPrinc = ClaimsPrincipal.Current; 

    } 


    /* WebAPI */ 
    public override void OnAuthorization(HttpActionContext actionContext) 
    { 
     IPrincipal claimsPrincCurrent = ClaimsPrincipal.Current; 

    } 

Sie könnten auch dies tun:

adding claims to forms authentication in asp.net

oder dies:

http://brockallen.com/2013/01/26/replacing-forms-authentication-with-wifs-session-authentication-module-sam-to-enable-claims-aware-identity/

oder diese:

http://chris.59north.com/post/Claims-based-identities-in-ASPNET-MVC-45-using-the-standard-ASPNET-providers

+0

Optional können Sie dies überprüfen: https://msdn.microsoft.com/en-us/library/system.security.claims.claimsprincipal.claimsprincipalselector(v=vs.110).aspx – granadaCoder

0

MVC und WebAPI (bis .NET Core) teilen nicht dieselbe Pipeline, daher müssen Sie zwei verschiedene Filter verwenden.

Was Sie tun können, ist den Code zu teilen, wenn Sie wollen, vielleicht mit einer Hilfsmethode oder etwas. Nur um zu vermeiden zwei Codes

+0

Gibt es einen anderen Ort außerhalb der MVC-Pipeline (d.h. in der Request-Pipeline) wo kann ich diese Logik setzen? – devanalyst

+0

Verwenden Sie OWIN? Wenn ja, können Sie eine Middleware dafür erstellen; es wird geteilt! –