ASP0026: [Authorize]가 더 먼 곳에서 온 [AllowAnonymous]에 의해 재정의됩니다.

원인

MVC 작업에 "더 가깝게" 배치된 [Authorize] 특성이 [AllowAnonymous] 특성을 재정의하고 권한을 부여하도록 강제하는 것은 직관적으로 보일 수 있습니다. 그러나 반드시 그렇지는 않습니다. 중요한 것은 특성의 상대적 순서입니다.

다음 코드에서는 더 가까운 [Authorize] 특성이 더 멀리 떨어진 [AllowAnonymous] 특성에 의해 재정의되는 예제를 보여 줍니다.

[AllowAnonymous]
public class MyController
{
    [Authorize] // Overridden by the [AllowAnonymous] attribute on the class
    public IActionResult Private() => null;
}

[AllowAnonymous]
public class MyControllerAnon : ControllerBase
{
}

[Authorize] // Overridden by the [AllowAnonymous] attribute on MyControllerAnon
public class MyControllerInherited : MyControllerAnon
{
}

public class MyControllerInherited2 : MyControllerAnon
{
    [Authorize] // Overridden by the [AllowAnonymous] attribute on MyControllerAnon
    public IActionResult Private() => null;
}

[AllowAnonymous]
[Authorize] // Overridden by the preceding [AllowAnonymous]
public class MyControllerMultiple : ControllerBase
{
}

규칙 설명

[Authorize] 속성이 더 먼 곳에서 온 [AllowAnonymous] 속성에 의해 덮어씌워졌음을 경고합니다.

위반 문제를 해결하는 방법

이 경고가 표시되면 수행할 올바른 작업은 특성 뒤에 있는 의도에 따라 달라집니다. 의도치 않게 엔드포인트를 익명 사용자에게 노출하는 경우 멀리 떨어진 [AllowAnonymous] 특성을 제거해야 합니다. [AllowAnonymous] 속성이 더 가까운 [Authorize] 속성을 재정의하도록 의도된 경우, [Authorize] 속성 뒤에 [AllowAnonymous] 속성을 반복하여 의도를 명확히 할 수 있습니다.

[AllowAnonymous]
public class MyController
{
    // This produces no warning because the second, "closer" [AllowAnonymous]
    // clarifies that [Authorize] is intentionally overridden.
    // Specifying AuthenticationSchemes can still be useful
    // for endpoints that allow but don't require authenticated users.
    [Authorize(AuthenticationSchemes = "Cookies")]
    [AllowAnonymous]
    public IActionResult Privacy() => null;
}

경고를 표시하지 않는 경우

이 진단의 심각도 수준은 참고사항입니다. 특성을 재정의하려는 경우 경고를 무시할 수 있습니다. 그러나 의도를 명확히 하기 위해 [Authorize] 특성 뒤에 [AllowAnonymous] 특성을 반복하는 것이 좋습니다.