沒有authenticationScheme指定，也沒有發現DefaultChallengeScheme餅乾認證

我使用驗證下面的代碼在ASP.NET 2.0的核心使用cookie沒有authenticationScheme指定，也沒有發現DefaultChallengeScheme餅乾認證

services 
    .AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme) 
    .AddCookie("MyCookieMiddlewareInstance", options => 
    { 
     options.AccessDeniedPath = new PathString("/Account/Login"); 
     options.LoginPath = new PathString("/Account/Login"); 
     options.LogoutPath = new PathString("/Account/LogOff"); 
    });

我得到一個錯誤「沒有authenticationScheme是。指定，也沒有發現DefaultChallengeScheme」

的餅乾設置如下：

var claims = new List<Claim> 
{ 
    new Claim(ClaimTypes.NameIdentifier, userId.ToString()), 
    new Claim(ClaimTypes.Name, userName) 
}; 

var identity = new ClaimsIdentity(claims, "Forms"); 
identity.AddClaim(new Claim(ClaimTypes.Role, "ADMIN")); 
var principal = new ClaimsPrincipal(identity); 
HttpContext.Authentication.SignInAsync("MyCookieMiddlewareInstance", principal, new AuthenticationProperties 
{ 
    IsPersistent = isPersistent, 
    ExpiresUtc = DateTime.UtcNow.AddYears(1) 
});

我做了一些研究，但沒有找到解決方案。這裏是我使用的鏈接：https://docs.microsoft.com/en-us/aspnet/core/security/authentication/cookie?tabs=aspnetcore2x

任何人都可以請讓我知道我該如何解決這個問題？

來源

2017-09-18 San Jaisy

可能重複[ASP.NET Core 2.0身份驗證中間件]（https://stackoverflow.com/questions/ 45805411/asp-net-core-2-0-authentication-middleware） –

-1

HttpContext.Authentication是在ASP.net核心2.0過時的，所以不是 HttpContext.Authentication.SignInAsync使用HttpContext.SignInAsync

來源

2017-09-18 12:35:54 YuriyP

確實如此，但與OP的問題無關。過時也並不意味着它不再有效。 – poke

據我記憶，在這種變化之後，它開始爲我工作。 – YuriyP

authenticationBuilder.AddCookie("MyCookieMiddlewareInstance", …)

這將註冊使用認證方案名稱"MyCookieMiddlewareInstance"一個cookie認證處理程序。因此，無論何時您引用Cookie身份驗證方案，都需要使用該確切名稱，否則您將無法找到該方案。

然而，在AddAuthentication電話，您使用的是不同的方案名稱：

services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)

此註冊CookieAuthenticationDefaults.AuthenticationScheme，它具有恆定值"Cookies"，作爲缺省的認證方案。但是這個名字的方案永遠不會被註冊！相反，只有一個"MyCookieMiddlewareInstance"。

因此，解決方案是簡單地爲這兩個調用使用相同的名稱。您也可以使用默認值，並刪除顯式名稱;如果你沒有多種方案並需要更多的控制，那就沒有必要明確地設置他們的名字。

來源

2017-09-18 18:19:22 poke

對於那些誰降落在此留下沮喪，我的建議是看看在這個問題的答案：ASP.NET Core 2.0 authentication middleware

，而無需重新迭代，你發現有什麼太大的話，看來這個問題是關係到ASP.Net Core 1和2之間的安全性變化。當然，那裏的建議解決了我自己的問題。這也是值得看看這篇博客文章：https://ignas.me/tech/custom-authentication-asp-net-core-20/（我懷疑是基於這樣的回答寫的）

來源

2017-11-28 10:06:34

雖然這個鏈接可能回答這個問題，但最好在這裏包含答案的基本部分，並提供參考鏈接。如果鏈接頁面更改，則僅鏈接答案可能會失效。 - [來自評論]（/ review/low-quality-posts/18085439） –

如果你的意思是這個鏈接的答案，那麼這可能會活到只要SO做？我很樂意刪除該博客文章的鏈接;它本質上是對第一個答案的重新考慮，所以它並沒有真正增加太多。但它也可能沒有害處。 –

並非如此，如果該用戶的SO內容發生變化，則該答案不再有效。通常情況下，您可以離開鏈接，但是如果鏈接內容發生更改，則會從鏈接中複製必要的部分，並留在此處。 –

沒有authenticationScheme指定，也沒有發現DefaultChallengeScheme餅乾認證

回答

相關問題