|
| 1 | +# Change log |
| 2 | +Change log stars with version 3.1.3 |
| 3 | + |
| 4 | +## 4.1.0 |
| 5 | +- ### [Breaking] Removing support for `Bearer` scheme and adding `FunctionsBearer` |
| 6 | + Recent security updates in the Azure Functions runtime are clashing with the use of the default, well known `Bearer` scheme.<br/> |
| 7 | + 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. |
| 8 | + 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.<br/> |
| 9 | + 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. |
| 10 | + |
| 11 | +## 4.0.1 |
| 12 | +Deprecating `DarkLoop.Azure.Functions.Authorize` package in favor of `DarkLoop.Azure.Functions.Authorization.InProcess` package.<br/> |
| 13 | +The functionality remains the same, it's just a way to keep package naming in sync. |
| 14 | + |
| 15 | +## 4.0.0 |
| 16 | +Starting from 4.0.0, support for Azure Functions V4 Isolated mode with ASPNET Core integration is added. |
| 17 | +The package is now split into two separate packages, one for each mode. |
| 18 | + |
| 19 | +The package for Azure Functions V3+ In-Proc mode is now called `DarkLoop.Azure.Functions.Authorization.InProcess` and the package for Azure Functions V4 Isolated mode with ASPNET Core integration is called `DarkLoop.Azure.Functions.Authorize.Isolated`. |
| 20 | + |
| 21 | +- ### .NET 6 support |
| 22 | + Starting with version 4.0.0, the package is now targeting .NET 6.0. This means that the package is no longer compatible with .NET 5 or lower. If you are using .NET 5 or lower, you should use version 3.1.3 of the package. |
| 23 | + |
| 24 | +- ### DarkLoop.Azure.Functions.Authorize v4.0.0 |
| 25 | + This package is published but is now deprecated in favor of `DarkLoop.Azure.Functions.Authorization.InProcess`. All it's functionality remains the same. It's just a way to keep package naming in sync. |
| 26 | + |
| 27 | +- ### Introducing IFunctionsAuthorizationProvider interface |
| 28 | + The `IFunctionsAuthorizationProvider` interface is introduced to allow for custom authorization filter provisioning to the framework. |
| 29 | + By default the framework relies on decorating the function or type with `[FunctionAuthorize]`. You could skip this decoration and provide the middleware with an authorization filter sourced from your own mechanism, for example a database. |
| 30 | + At this moment this can be done only with Isolated mode even when the interface is defined in the shared package.<br/> |
| 31 | + Support for In-Process will be added in a future version, once source generators are introduced, as the in-process framework relies on Invocation Filters to enable authorization. |
| 32 | + Replacing the service in the application services would break the authorization for in-process mode at this point. |
| 33 | + |
| 34 | +## 3.1.3 |
| 35 | +3.1.3 and lower versions only support Azure Functions V3 In-Proc mode. Starting from 4.0.0, support for Azure Functions V4 Isolated mode with ASPNET Core integration is added. |
| 36 | +- ### Support for disabling `FunctionAuthorize` effect at the application level. |
| 37 | + Adding support for disabling the effect of `[FunctionAuthorize]` attribute at the application level. |
| 38 | + This is useful when wanting to disable authorization for a specific environment, such as local development. |
| 39 | + |
| 40 | + When configuring services, you can now configure `FunctionsAuthorizationOptions`. |
| 41 | + ```csharp |
| 42 | + builder.Services.Configure<FunctionsAuthorizationOptions>(options => |
| 43 | + options.DisableAuthorization = Configuration.GetValue<bool>("AuthOptions:DisableAuthorization")); |
| 44 | + ``` |
| 45 | + |
| 46 | + Optionally you can bind it to configuration to rely on providers like User Secrets or Azure App Configuration to disable and re-enable without having to restart your application: |
| 47 | + ```csharp |
| 48 | + builder.Services.Configure<FunctionsAuthorizationOptions>( |
| 49 | + Configuration.GetSection("FunctionsAuthorization")); |
| 50 | + ``` |
| 51 | + |
| 52 | + For function apps targeting .NET 7 or greater, you can also use `AuthorizationBuilder` to set this value: |
| 53 | + ```csharp |
| 54 | + builder.Services |
| 55 | + .AddAuthorizationBuilder() |
| 56 | + .DisableAuthorization(Configuration.GetValue<bool>("AuthOptions:DisableAuthorization")); |
| 57 | + ``` |
| 58 | + |
| 59 | + It's always recommended to encapsulate this logic within checks for environments to ensure that if the configuration setting is unintentionally moved to a non-desired environment, it would not affect security of our HTTP triggered functions. This change adds a helper method to identify if you are running the function app in the local environment: |
| 60 | + ```csharp |
| 61 | + if (builder.IsLocalAuthorizationContext()) |
| 62 | + { |
| 63 | + builder.Services.Configure<FunctionsAuthorizationOptions>( |
| 64 | + options => options.AuthorizationDisabled = true); |
| 65 | + } |
| 66 | + ``` |
| 67 | + |
| 68 | + If you want to output warnings emitted by the library remember to set the log level to `Warning` or lower for `Darkloop` category in your `host.json` file: |
| 69 | + |
| 70 | + ```json |
| 71 | + { |
| 72 | + "logging": { |
| 73 | + "logLevel": { |
| 74 | + "DarkLoop": "Warning" |
| 75 | + } |
| 76 | + } |
| 77 | + } |
| 78 | + ``` |
| 79 | + |
| 80 | + Thanks to [BenjaminWang1031](https://github.com/BenjaminWang1031) for the suggestion to add this functionality. |
| 81 | + |
| 82 | +- #### Remove Functions bult-in JwtBearer configuration by default |
| 83 | + Azure Functions recently [added configuration](https://github.com/Azure/azure-functions-host/pull/9678) for issuer and audience validation for the default authentication flows, not the one supported by this package through `FunctionAuthorizeAttribute`, which interferes with token validation when using our own Bearer scheme token configuration. |
| 84 | + In prior versions, this package has functionality to clear Functions built-in configuration, but it was not enabled by default when using `AddJwtBearer(Action<JwtBearerOptions> configure, bool removeBuiltInConfig = false)`. Since the use of this package is commonly used for custom JWT token, the default value of `removeBuiltInConfig` is now `true`. |
0 commit comments