다음을 통해 공유


ASP0026: [Authorize] "더 멀리"에서 재정 [AllowAnonymous] 의됩니다.

규칙 ID ASP0026
범주 사용
수정 사항이 주요 변경인지 여부 주요 변경 아님

원인

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

다음 코드에서는 멀리 떨어진 특성에 의해 더 가까운 [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] 특성을 제거해야 합니다. 특성이 더 가까운 [Authorize] 특성을 재정의 [AllowAnonymous] 하도록 의도된 경우 특성 뒤 [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] 의하려는 경우 경고를 표시하지 않을 수 있습니다. 그러나 특성 뒤 [Authorize] 의 특성을 반복하여 의도를 [AllowAnonymous] 명확히 하는 것이 좋습니다.