search

dotnet / aspnetcore

ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
https://asp.net
MIT License
35.21k stars 9.95k forks source link

Add an option to AuthorizationMessageHandler to not throw if unable to get token #46862

Open mkArtakMSFT opened 1 year ago

mkArtakMSFT commented 1 year ago

Context

When using HttpClient to make API calls from Blazor WebAssembly application, users have to add AuthorizationMessageHandler to the configured HttpClient instance. That's required specifically for calling APIs which require authorization. What the AuthorizationMessageHandler does, it will try to get an access token through the configured token provider and send it with the outgoing HTTP Request headers. And if the token provider can't retrieve a token (let's say for a non-authenticated user), the corresponding http client request will fail with AccessTokenNotAvailableException.

Problem

Users who intend to call an unprotected API (one which doesn't require authorization) don't need to use the AuthorizaitonMessageHandler. Hence, in Blazor WebAssembly applications, which have both protected and unprotected APIs to communicate with, users currently have to have two separate HttpClient instances to work with: one configured with AuthorizaitonMessageHandler, and another which does not.

The problem, however, arises, when the user wants to interact with an API, which doesn't require the callers to be authorized, but behaves differently if they are. For this scenario, the current solution doesn't work, and users will have to avoid using AuthorizaitonMessageHandler and inject tokens directly into their outing http requests manually, which defeats the purpose of AuthorizaitonMessageHandler.

Proposal

Expose a mechanism to configure the behavior of the AuthorizationMessageHandler, so that it doesn't throw AccessTokenNotAvailableException if token can't be aquired. Isntead, it lets the call throuigh without attaching an access token to that request.

The current behavior should remain as the default, and customers who would like to use the above proposed behavior will need to explicitly opt-into it by setting some boolean parameter.

ghost commented 1 year ago

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.

oluatte commented 10 months ago

For the sake of all that is holy, please add this. The default behavior is inflexible and makes users have to workaround what should be a basic scenario.

ghost commented 9 months ago

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 commented 9 months ago

Related https://github.com/dotnet/aspnetcore/issues/28951