DfMon Isolated is incompatible with ASP.NET Core Integration

[mdddev]

Hello,

I'm using dfMon in injected mode in an isolated function app. If have disabled auth for testing purposes. When opening http://localhost:7071/api/durable-functions-monitor in a browser, the screen stays blank. In the Edge DevTools, an error is shown Manifest: Line: 1, column: 1, Syntax error. The manifest seems empty.

Here are my packages I'm using.

  <ItemGroup>
    <PackageReference Include="DurableFunctionsMonitor.DotNetIsolated" Version="6.3.0-beta6" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="1.2.1" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.0" OutputItemType="Analyzer" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.DurableTask" Version="1.1.1" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http" Version="3.1.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Timer" Version="4.3.0" />
  </ItemGroup>

[scale-tone]

@mdddev , can you share Network tab there in your browser's DevTools, and also your host.json file?

[mdddev]

Thanks for reaching out @scale-tone ! Of course, here you go:

host.json

{
    "version": "2.0",
    "logging": {
        "applicationInsights": {
            "samplingSettings": {
                "isEnabled": true,
                "excludedTypes": "Request"
            },
            "enableLiveMetricsFilters": true
        }
    },
    "extensions": {
        "durableTask": {
            "hubName": "myTaskHub"
        }
    }
}

[mdddev]

PS, looking through the DevTools I've found this, though Javascript is not disabled on that site.

[scale-tone]

Right, so it appears that DfMon Isolated is incompatible with ASP.NET Core Integration (which you're using in your project, as Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore reference indicates).

OK, will need to check what can be done about it...

Until then you're welcome to use DfMon in all other supported forms.

[mronnblom-ith]

So what are you saying? DfMon Isolated in injected mode isn't usable at all?

[scale-tone]

@mronnblom-ith , if your Durable Functions project uses ASP.Net Core Integration, then you are still welcome to use all other supported ways of running DfMon to monitor it.

[scale-tone]

Hi @mdddev , I've just pushed version 6.5.0-beta2, which should work with ASP.Net Core Integration.

In an ASP.NET Core Integration function project DfMon needs to be initialized as usual:

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication((builderContext, workerAppBuilder) => {

        workerAppBuilder.UseDurableFunctionsMonitor(......);

        //......
    })
    .ConfigureServices(services => {
         //....
    })
    .Build();

Note that this new package targets .NET 8.

May I ask you to try it out and see if there're any issues? Thanks!

[mdddev]

Hi, thanks for your work. Apologies for the late reply. I have switched to an isolated azure function with the ASP.NET integration. It builds fine and I can run it locally. However, I am experiencing some auth issues (DurableFunctionsMonitor.DotNetIsolated.DfmUnauthorizedException: No access token provided. Call is rejected.) I will try to deploy to the AppService and see if the problem remains, however, the function app itself is currently engaged in an active MS support ticket, so I might have to wait a bit for this to finish. I will report back soon.

[mdddev]

Hi, I can confirm, that even if deployed in Azure, I am getting this error on pageload.. if I remove the ASP.NET integration and re-deploy, it works without the 401 error.

[mdddev]

PS: Even without the ASP.NET integration I am experiencing an error. When I enter an orchestration the history cannot be displayed, due to an 401 error. The failures seem to originate in DfmGetOrchestrationHistoryFunction. If I search this repo for DFM failed it seems to be indeed auth related. I am using EasyAuth in an unchanged configuration I have set-up aover a year ago, and which has been running ever since correctly in the in-proc model. I have now migrated over to the isolated model.

One further info, as per this I have created a custom endpoint in order to expose the Dfmon at the root of the site.. Though I have changed /{p1?}/{p2?}/{p3?} to {p1?}/{p2?}/{p3?} (without the leading /). I have jsut now also tried without the custom endpoint and I see the same error, 401 in the UI.

[scale-tone]

@mdddev , the "No access token provided" error means that DfMon thinks it is under the client-directed login flow, and yet for some reason doesn't get a token from the client side.

Generally speaking, to make DfMon (no matter if it is standalone or injected, inproc or isolated, with or without ASP.Net Core Integration) work, you are required to configure the authentication, as per documented here. By default, your DfMon endpoint would always reject unauthenticated calls to it, for obvious security reasons.

I am using EasyAuth in an unchanged configuration

Can you show your Function App instance's "Authentication" tab, for me to better understand what that "unchanged" configuration is? There shouldn't be any secrets there, but still do ensure that you don't share any.

Also, do you have any other HTTP endpoints in your project, and if yes, how are those authenticated?

[mdddev]

Hi @scale-tone , of course, here you go. EasyAuth was not changed, and it used to work fine in the injected/in-process version of the app deployment.

This is my Program.cs

public class Program
{
    public static async Task Main()
    {
        var host = new HostBuilder()
            // .ConfigureFunctionsWebApplication((IFunctionsWorkerApplicationBuilder workerApplication) =>
            .ConfigureFunctionsWorkerDefaults((IFunctionsWorkerApplicationBuilder workerApplication) =>
            {
                 workerApplication.UseDurableFunctionsMonitor((settings, extPts) =>
                 {
                    settings.AllowedReadOnlyAppRoles = [AppRoles.READ];
                    settings.AllowedAppRoles = [AppRoles.WRITE];
                 });
            })
            .ConfigureAppConfiguration((HostBuilderContext ctx, IConfigurationBuilder builder) => 
            {
                builder
                    .SetBasePath(Directory.GetCurrentDirectory())
                    .AddJsonFile("local.settings.json", optional: true, reloadOnChange: true)
                    .AddEnvironmentVariables();
            })
            .ConfigureServices((HostBuilderContext ctx, IServiceCollection services) => 
            {
            })
            .Build();

        await host.RunAsync();
    }
}

public static class AppRoles
{
    public const string READ = "Workflows.Read";
    public const string WRITE = "Workflows.Write";
}

[scale-tone]

Thanks for all that info, @mdddev .

I can confirm that there is still an issue in this "Isolated+Asp.Net Core Integration" beta package, that prevents the server-directed login flow (the one your current setup is using) to work. More specifically, the HttpRequestData.Identities property seems to be empty or not populated correctly.

The workaround is to switch to client-directed flow, by changing your EasyAuth settings to look like this:

---

If you then get an auth error like the following:

, then adjust the Redirect URIs settings in your Entra Id app registration accordingly.

Please, let me know if the workaround works or doesn't.

[scale-tone]

Should be fixed in v6.5