AuthorizeView should expose the results of the AuthorizeAsync call as a context variable.

[michac]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

I am using asp.net Policy to enforce licensing restrictions. When a user is not authorized to view or use a component I want to be able to tell them why they are not authorized. This is supported via Policy, where you can include a reason why access is denied that then shows up in the AuthorizationResult as a AuthorizationFailureReason. AuthorizeViewCore, however, throws away all this metadata and boils the result down to a true/false for which view to show.

Describe the solution you'd like

I wrote a custom AuthorizeViewCore that wraps the AuthenticationState and the AuthorizationResult in a new type, and makes that available as a context variable. Now my NotAuthorized view can show a tooltip or other message indicating why it's not authorized (ex. "this is disabled because you are not licensed for this feature").

Additional context

No response

[javiercn]

@michac thanks for contacting us.

Your ask sounds reasonable, but I'll let other people on the team chime in.

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[mkArtakMSFT]

@michac feel free to send us a PR with the fix. We'd be happy to consider it.

[IDisposable]

Looks like the simplest change that could work would be in AuthorizeViewCore.cs to replace the private bool? isAuthorized; with private AuthorizationResult? currentAuthorizationResult; .

Then in BuildRenderTree:

• We do the null check against currentAuthorizationResult for the Authorizing case.
• If not null we check currentAuthorizationResult.Succeeded for the Authorized case.
• If not null and not Succeeded (the else clause), we would pass down the currentAuthorizationResult along with the state like builder.AddContent(0, NotAuthorized?.Invoke(currentAuthenticationState!, currentAuthorizationResult!));.
  • This would add a new argument to the Invoke to the NotAuthorized RenderFragment... that would break existing usages right @mkArtakMSFT?

Finally, around line 99, we replace the Task<bool> IsAuthorizedAsync( with Task<AuthorizationResult> AuthorizeAsync( and change the last two lines (at 112 and 113) to simply return the whole value that AuthorizationService.AuthorizeAsync( was previously returning instead of returning the dotted-into Succeeded value.

Obviously we would need to adjust the tests accordingly, but this seems like a relatively safe and simple change if the addition of the argument to the NotAuthorized fragment won't break things... I simply don't know that...

This path doesn't change any public exposure except that if we would also want to expose the authorization result for others via a new property public AuthorizationResult AuthorizationResult { get { return currentAuthorizationResult }; }, but that would only be required if we didn't have the value getting passed to the Invoke.

[IDisposable]

A trial implementation of this reveals that Invoke can only take one argument, so I guess we do need to introduce a wrapping object or modify the declaration of the NotAuthorized fragment. This means that we would have some breaking changes to the people providing the RenderFragment for NotAuthorized . What's the desired approach for this? Do we create a different template that expects a State+Result object?

[IDisposable]

The changing of the NotAuthorized argument would break so much, it looks like the only reasonable path is to just expose the AuthorizationResult directly on AuthorizeViewCore.cs which likely isn't actually very useful.

[IDisposable]

Can the AuthorizedViewCore have more than one [CascadingParameter]?