v4.1.3

Added support for specifying a scheme name in a AddJwtFunctionsBearer method overload. It throws exception if Bearer is defined as the scheme.

v4.1.3-preview-20241121-5

Adding support for specifying a scheme name in a AddJwtFunctionsBearer method overload.

v4.1.2

Fixes

• Ensuring metadata collection middleware is thread safe when no metadata has been built for a specific function.

v4.1.2-preview-20240819-12

Setting flag for Monitor to release locks on all awaiting threads after first locking threads exits

v4.1.2-preview-240818-2

• Resolving issue related to race condition between metadata and authorization middleware.
• Moving sample app to FunctionsBearer scheme for attribute

v4.1.1

Adding AuthenticateResult to middleware features and creating specific .NET targets with package for 6, 7 and 8

• Enabling storing AuthenticateResult in authentication features, mirroring what ASP.NET Core middlewares do.
• Adding framework specific dependencies for .NET 6, .NET 7 and .NET 8.
  ASP.NET Core Authentication and Authorization packages reference version 6 of Identity Model packages that causing issues when referenced by this framework.

v4.1.1-preview-240816-18

Adding specific target versions of .NET to ensure the correct Microsoft.IdentityModel package is referenced for consuming projects.

v4.1.1-preview-240719-1

During authentication not all available information is stored in the user identity/the service principal. Normally ASP.NET stores the full authentication result (AuthenticateResult) in a feature via HttpContext.Features. This PR adds support for storing the authenticate result in the HttpContext. This should promote maximum compatibility with other authentication/authorization middleware designed to use these features.

The AuthenticateResult is also stored in the FunctionContext.Features for ease of use.

v4.1.0

• [Breaking] Removing support for Bearer scheme and adding FunctionsBearer

  Recent security updates in the Azure Functions runtime are clashing with the use of the default, well known Bearer scheme.
  
  One of the effects of this change is the portal not able to interact with the functions app to retrieve runtime information and in some cases not able to retrieve functions information.
  In the past this was not an issue and application was able to replace the default Bearer configuration to enable the functionality provided by this package.
  
  Starting from this version, using the default AddJwtBearer with no custom name, will produce an error. You will have 2 options: you can switch your app to use AddJwtFunctionsBearer method without providing any name which will map your configuration to the FunctionsBearer scheme, or you can use AddJwtBearer("<your-custom-scheme>", ...) to specify something different.

v4.1.0-preview-240521-1

• [Breaking] Removing support for Bearer scheme and adding FunctionsBearer

  Recent security updates in the Azure Functions runtime are clashing with the use of the default, well known Bearer scheme.
  
  One of the effects of this change is the portal not able to interact with the functions app to retrieve runtime information and in some cases not able to retrieve functions information.
  In the past this was not an issue and application was able to replace the default Bearer configuration to enable the functionality provided by this package.
  
  Starting from this version, using the default AddJwtBearer with no custom name, will produce an error. You will have 2 options: you can switch your app to use AddJwtFunctionsBearer method without providing any name which will map your configuration to the FunctionsBearer scheme, or you can use AddJwtBearer("<your-custom-scheme>", ...) to specify something different.