Блог

Существует объект типа AuthenticationState с именем «контекст», доступный внутри компонентов AuthorizeView и AuthorizedRouteView. Этот объект позволяет получить доступ к ClaimsPrincipal через context.User.

Я вижу в исходном коде, что состояние аутентификации передается этим компонентам как задача компонентом CascadingValue, реализованным в компоненте CascadingAuthenticationState (который, в свою очередь, определен в верхней части иерархии компонентов в App.razor).

Однако, когда я проверяю источник AuthorizeRouteView, я вижу каскадный параметр задачи типа с именем ExistingCascadedAuthenticationState. Тем не менее, для меня остается полной загадкой, как и где Задача раскрывается и раскрывается как «контекст». Кто-нибудь знает ответ?

Вам нужно копнуть глубже, и это немного сложно.

1. AuthorizeView наследует от AuthorizeViewCore
2. AuthorizedRouteView строит его самостоятельно AuthorizeRouteViewCore , унаследовав от AuthorizeViewCore .

Код в нижней части AuthorizedRouteView :

         private sealed class AuthorizeRouteViewCore : AuthorizeViewCore
        {
            [Parameter]
            public RouteData RouteData { get; set; } = default!;

            protected override IAuthorizeData[]? GetAuthorizeData()
                => AttributeAuthorizeDataCache.GetAuthorizeDataForType(RouteData.PageType);
        }
 

AuthorizedRouteView захватывает любой каскад в ExistingCascadedAuthenticationState . Если он существует (не нулевой), то CascadingAuthenticationState существует внутри App , так что больше ничего не нужно делать. Если он равен нулю, то он добавляет CascadingAuthenticationState в качестве корневого компонента компонент в свой фрагмент рендеринга. Это гарантирует, что Task<AuthenticationState> это каскадно.

AuthorizeViewCore захватывает каскадное значение:

 [CascadingParameter] private Task<AuthenticationState>? AuthenticationState { get; set; }
 

Он «разворачивается» в OnParametersSetAsync

   currentAuthenticationState = await AuthenticationState;
  isAuthorized = await IsAuthorizedAsync(currentAuthenticationState.User);
 

и используется в BuildRenderTree том «контексте», который вы видите.

    var authorized = Authorized ?? ChildContent;
   builder.AddContent(0, authorized?.Invoke(currentAuthenticationState!));
 

Содержание исходит от:

 RenderFragment<TValue>
 

объявляется следующим образом, где TValue — content — объявляется как AuthenticationState :

 [Parameter] public RenderFragment<AuthenticationState>? Authorized { get; set; }
 

Комментарий энета помог мне найти ответ.

Когда у нас есть RenderFragment<TValue> делегат, <TValue> он по умолчанию отображается как @context .

Например, в AuthorizeRouteView у нас есть параметр NotAuthorized :

  [Parameter]
 public RenderFragment<AuthenticationState> NotAuthorized { get; set; }
 

В данном случае AuthenticationState есть TValue , следовательно AuthenticationState , выставляется как @context .

Эта статья об Университете Блейзора стала для меня ключом к пониманию концепции: передача заполнителей в фрагменты визуализации.

Параметр каскадирования Task<AuthenticationState> context указывает , что context при ожидании будет возвращен объект типа AuthenticationState. Итак, то, что вы получаете, — это Задача. Задача, когда ее ожидают, возвращает значение, возвращенное Задачей. Фактический синтаксис для доступа к Пользователю таков

 var state = await context;
var user = state.User;
 

Кроме того, вы можете дать любое имя параметру каскадирования. Так

 [CascadingParameter]
public Task<AuthenticationState> AuthState {get;set;}

var state = await AuthState;
var user = state.User;
 

в равной степени справедливо.