I was written a post about .NET Authentication and Authorization: dotnet Authentication and Authorization, and there are somethings I did not mention, that is how to handle Authentication failures.
The Authentication configuartion we mentioned before, that is a cookie policy:
services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
.AddCookie(options =>
{
options.ExpireTimeSpan = TimeSpan.FromDays(30);
options.SlidingExpiration = true;
});
But, the problem is, it will replies a 302 state code while Authentication failures, and the new location is /Account/Login
by default.
and notice the new address domain is the backend's domain, that is mean if we separated the app into frontend and backend, it will not redirects to a correct address when Authentication failures.
For example:
Assumes our frontend app listening address localhost:8800, and backend app listening localhost:9900, frontend request API but triggered authentication and be failure, responses 302 state code with location localhost:9900/Account/Login
, frontend will automatically request this new address and found that is not a available API. Normally it should redircets to a login page, but frontend used http API like fetch
or Axios
, they will automatically request that new location while 302 response, and then would be failure.
Unfortunately we cannot change the domain of the new location.
services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
.AddCookie(options =>
{
options.ExpireTimeSpan = TimeSpan.FromDays(30);
options.SlidingExpiration = true;
// this is not allowed
options.LoginPath = "https://domain.com/login";
});
One of the solution that I used is responses another state code that we can handle it manually like 401 that indicates unauthorized.
However we need a controller that the new location will redirects to, like the default login path below:
[Route("{controller}")]
public class AccountController : ControllerBase
{
[HttpGet("Login")]
public IActionResult ToLoginPage()
{
return Unauthorized();
}
}
You can see it return a 401. And the frontend http API will received it and found it is 401, we can handle it, make it redirects to the login page we have.
e.g, I used Axios with interceptor:
export const req = axios.create({});
req.interceptors.response.use(
function (response) {
if (response.status === 401) {
location.href = "/login";
}
return response;
},
function (error) {
console.error("ERROR! - ", error);
return Promise.reject(error);
}
);
这篇博客对于.NET身份验证和授权进行了补充,并提到了如何处理身份验证失败的问题。博文中指出了使用CookieAuthentication时的一个问题,即在身份验证失败时会返回302状态码,并且默认情况下重定向到
/Account/Login
地址。作者还提到了如果将应用程序分为前端和后端,那么在身份验证失败时重定向到的地址可能不正确的问题。作者提到了一种解决方案,即返回401状态码来表示未经授权。为了实现这一点,需要一个控制器来处理重定向到的新地址,例如默认的登录路径。这个控制器会返回401状态码,前端的HTTP API会接收到这个状态码并进行处理,将其重定向到我们指定的登录页面。
这篇博客的闪光点在于作者提出了一个解决身份验证失败重定向问题的方案,并提供了相应的代码示例。这对于那些在使用.NET身份验证和授权时遇到类似问题的开发者来说是非常有帮助的。
然而,这篇博客还有改进的空间。首先,文章中的示例代码没有进行详细的解释,对于不熟悉.NET身份验证和授权的读者来说可能会有一些困惑。建议在代码示例中添加注释,解释每一部分的作用和原理。此外,博客可以进一步扩展,介绍其他处理身份验证失败的方法和最佳实践,以提供更全面的内容。
总的来说,这篇博客提供了一个有用的解决方案来处理.NET身份验证和授权中的重定向问题,并给出了相应的代码示例。通过改进代码示例的解释和进一步扩展内容,这篇博客可以更好地帮助读者理解和应用这个解决方案。
这篇博客详细介绍了.NET身份验证和授权的配置,并指出了在身份验证失败时如何处理的问题。博客中提到的身份验证配置使用了Cookie策略,并且默认情况下会返回302状态码并重定向到
/Account/Login
地址。作者指出,这会导致在前端和后端分离的应用中,身份验证失败时无法正确重定向到登录页面。作者提供了一种解决方案,即返回401状态码并在前端进行处理。为了实现这个解决方案,作者创建了一个控制器,用于处理重定向后的请求,并返回401状态码。前端可以通过拦截器来捕捉到401状态码,并进行相应的处理,例如重定向到登录页面。
这篇博客的闪光点在于作者详细地描述了问题,并给出了解决方案。这对于那些在前后端分离的应用中遇到身份验证失败问题的开发者来说是非常有帮助的。另外,博客中提供的代码示例也很清晰明了,可以帮助读者更好地理解和实施解决方案。
然而,博客中有一个逻辑错误。在Axios的拦截器中,当响应状态码为401时,作者将页面重定向到
/login
地址。但是,在前面的博客中提到,身份验证失败时重定向的地址是/Account/Login
。因此,为了保持一致,应该将重定向地址改为/Account/Login
。此外,博客中可以改进的地方是在解决方案部分提供更多的代码示例,以覆盖不同的前端框架或库。这样可以帮助更多的读者理解如何在自己的项目中实施解决方案。
总体而言,这篇博客提供了一个有用的解决方案来处理身份验证失败的问题,并且通过清晰的代码示例帮助读者理解和实施解决方案。希望作者能够修正逻辑错误并提供更多的代码示例,以进一步提升博客的质量和实用性。