Migrera från statisk ClaimsPrincipal-åtkomst

Den aktuella ClaimsPrincipal är en grundläggande komponent i autentiserade webbprogram som ger åtkomst till den aktuella användarens identitet och anspråk. När du migrerar från ASP.NET Framework till ASP.NET Core innebär åtkomst till detta unika utmaningar eftersom de två ramverken har olika metoder för hantering av användarkontexter.

Varför statisk ClaimsPrincipal-migrering är komplex

ASP.NET Framework och ASP.NET Core har olika sätt att komma åt den aktuella användaren:

• ASP.NET Framework använder statiska egenskaper som ClaimsPrincipal.Current och Thread.CurrentPrincipal med automatisk kontexthantering. Dessa egenskaper är utbytbara och båda ger åtkomst till den aktuella användarens identitet.
• ASP.NET Core lagrar den aktuella användaren i HttpContext.User och undviker statiskt tillstånd.

Dessa skillnader innebär att du inte bara kan fortsätta att använda statiska huvudnamnsegenskaper (ClaimsPrincipal.Current eller Thread.CurrentPrincipal) i ASP.NET Core utan ändringar. Som standard anges inte de statiska egenskaperna, och kod beroende på dem måste uppdateras för att hämta den aktuella autentiserade användarens identitet på olika sätt.

Översikt över migreringsstrategier

Du har två huvudsakliga metoder för att hantera statisk huvudåtkomst under migreringen:

1. Fullständig omskrivning – Skriv om all åtkomstkod för statiska huvudprinciper för att använda ASP.NET Core:s inhemska mönster
2. System.Web-adaptrar – Använd adaptrar för att aktivera statiska åtkomstmönster under inkrementell migrering

För de flesta program ger migrering till ASP.NET Cores interna ClaimsPrincipal-åtkomst bästa prestanda och underhållsbarhet. Större program eller program med omfattande användning av statisk huvudprincip kan dock dra nytta av att använda System.Web-adaptrar under inkrementell migrering.

Välj migreringsmetod

Du har två huvudsakliga alternativ för att migrera statisk huvudåtkomst från ASP.NET Framework till ASP.NET Core. Ditt val beror på din tidslinje för migrering, om du behöver köra båda programmen samtidigt och hur mycket kod du är villig att skriva om.

Snabb beslutsguide

Besvara dessa frågor för att välja din metod:

1. Gör du en fullständig omskrivning eller inkrementell migrering?

   • Slutför omskrivningen → Fullständig omskrivning till ASP.NET Core-mönster
   • Inkrementell migrering → Fortsätt till fråga 2

2. Har du omfattande användning av statiskt huvudnamn (ClaimsPrincipal.Current eller Thread.CurrentPrincipal) i delade bibliotek?

   • Ja, massor av delad kod → System.Web-adaptrar
   • Nej, isolerad användning av statiskt huvudnamn → Fullständig omskrivning till ASP.NET Core-mönster

Jämförelse av migreringstillvägagångssätt

Slutför omskrivningen till ASP.NET Core-mönster

Välj den här metoden när du utför en fullständig migrering eller vill ha bästa möjliga prestanda och underhåll.

ASP.NET Core innehåller flera alternativ för att hämta den aktuella autentiserade användarens ClaimsPrincipal utan att förlita sig på statiska egenskaper. Den här metoden kräver att du skriver om åtkomstkoden för statiskt huvudnamn men erbjuder de flesta fördelarna på lång sikt.

Fördelar och nackdelar med fullständig omskrivning

ASP.NET Core ClaimsPrincipal-åtkomstmönster

Det finns flera alternativ för att hämta den aktuella autentiserade användarens ClaimsPrincipal i ASP.NET Core i stället för ClaimsPrincipal.Current:

• ControllerBase.User
• HttpContext.User
• skickas från uppringaren. Bibliotek utan åtkomst till den aktuella HttpContext anropas ofta från styrenheter eller mellanprogramskomponenter och kan få den aktuella användarens identitet skickad som ett argument.
• IHttpContextAccessor. Projektet som migreras till ASP.NET Core kan vara för stort för att enkelt överföra den aktuella användarens identitet till alla nödvändiga platser. I sådana fall kan IHttpContextAccessor användas som en lösning. Detta är inte idealiskt eftersom det använder en statisk accessor i bakgrunden. Föredrar ett mer direkt alternativ om det är möjligt.

Kodexempel

Här är exempel på migrering av vanliga användningsmönster för statiska enheter:

ASP.NET Framework (före):

public class UserService
{
    public string GetCurrentUserId()
    {
        // Both ClaimsPrincipal.Current and Thread.CurrentPrincipal work interchangeably
        return ClaimsPrincipal.Current?.FindFirst(ClaimTypes.NameIdentifier)?.Value;
        // or: return Thread.CurrentPrincipal?.Identity?.Name;
    }
}

ASP.NET Core (uppdaterad) – Skicka ClaimsPrincipal som parameter:

public class UserService
{
    public string GetCurrentUserId(ClaimsPrincipal user)
    {
        return user?.FindFirst(ClaimTypes.NameIdentifier)?.Value;
    }
}

// Usage in controller
public class HomeController : Controller
{
    private readonly UserService _userService;
    
    public HomeController(UserService userService)
    {
        _userService = userService;
    }
    
    public IActionResult Index()
    {
        var userId = _userService.GetCurrentUserId(User);
        return View();
    }
}

ASP.NET Core (efter) – Beroendeinmatning:

public class UserService
{
    private readonly IHttpContextAccessor _httpContextAccessor;
    
    public UserService(IHttpContextAccessor httpContextAccessor)
    {
        _httpContextAccessor = httpContextAccessor;
    }
    
    public string GetCurrentUserId()
    {
        return _httpContextAccessor.HttpContext?.User?.FindFirst(ClaimTypes.NameIdentifier)?.Value;
    }
}

När du ska välja den här metoden

• Du har råd att skriva om åtkomstkoden för statiskt huvudnamn
• Prestanda är högsta prioritet (i det här fallet föredrar du att skicka identiteten som en parameter över DI)
• Du vill eliminera statiska beroenden
• Du delar inte kod med äldre program
• Du vill ha den mest testbara och underhållsbara lösningen

System.Web-adaptrar

Välj den här metoden när du behöver upprätthålla befintliga statiska användningsmönster för "principal" under en inkrementell migrering, eller när du har omfattande delade bibliotek som skulle vara svåra att uppdatera.

System.Web-adaptrar kan möjliggöra stöd för både ClaimsPrincipal.Current och Thread.CurrentPrincipal i ASP.NET Core, vilket gör att du kan behålla befintliga kodmönster under en stegvis migrering. Båda egenskaperna fungerar växelvis när adaptrarna har konfigurerats.

System.Web adapters för- och nackdelar

Konfigurera stöd för statiskt huvudnamn

Om du vill aktivera stöd för statiska principals (ClaimsPrincipal.Current och Thread.CurrentPrincipal) med System.Web-adapters, måste slutpunkter annoteras med SetThreadCurrentPrincipalAttribute metadata.

// Add to controller or action
[SetThreadCurrentPrincipal]
public class HomeController : Controller
{
    public IActionResult Index()
    {
        // Both ClaimsPrincipal.Current and Thread.CurrentPrincipal are now available
        var user1 = ClaimsPrincipal.Current;
        var user2 = Thread.CurrentPrincipal;
        return View();
    }
}

När du ska använda System.Web-adaptrar

• Du har omfattande användning av statiska huvudroller i delade bibliotek
• Du gör en gradvis migrering
• Du har inte råd att skriva om all åtkomstkod för statiskt huvudnamn omedelbart
• Du måste upprätthålla kompatibiliteten med befintlig ASP.NET Framework-kod
• Du förstår prestanda- och trådningskonsekvenserna

Överväganden vid migrering

Prestandakonsekvenser

• Interna ASP.NET Core-mönster ger bästa prestanda utan extra kostnad
• System.Web-adaptrar medför en viss prestandaöverhead men möjliggör gradvis migrering
• Statiska variabler bör undvikas eftersom de kan orsaka minnesläckor och trådproblem