Use of PipelinePolicies in Azure.AI.OpenAI.AzureOpenAIClient

In this post let's see how we can make use of PipelinePolicies in AzureOpenAIClient. Even though we specifically talk about AzureOpenAIClient in this post, the concept will be the same among many Clients in Azure SDK.

When a client in Azure SDK sends a request to Azure Service/API, the request travels through a pipeline which consists of a set of policies that get to modify the request before it's being sent and observe the response after it's received.

In order to add a Custom policy, we need to implement the abstract class PipelinePolicy.

public class CustomLoggingPolicy : PipelinePolicy
{
    // For synchronous processing
    // Not implementing as most of the time we are calling async methods in the client
    public override void Process(PipelineMessage message, IReadOnlyList<PipelinePolicy> pipeline, int currentIndex)
    {
        ProcessNext(message, pipeline, currentIndex);
    }
 
    // For asynchronous processing
    public override async ValueTask ProcessAsync(PipelineMessage message, IReadOnlyList<PipelinePolicy> pipeline, int currentIndex)
    {
        Console.WriteLine($"Sending Request to {message.Request.Method}: {message.Request.Uri}");
 
        await ProcessNextAsync(message, pipeline, currentIndex);
 
        if (message.Response?.IsError == true)
        {
            Console.WriteLine($"Request to {message.Request.Method}: {message.Request.Uri} failed.");
            Console.WriteLine(new
            {
                message.Response.ReasonPhrase,
                message.Response.Content,
            });
        }
        else
        {
            Console.WriteLine($"Request to {message.Request.Method}: {message.Request.Uri} completed.");
        }
    }
}

Here I have added CustomLoggingPolicy for demo purposes. A key thing to remember is, we need to call the  ProcessNext/ProcessNextAsync method to pass the control to the next PipelinePolicy.

We can now make use of the CustomLoggingPolicy as follows.

string deploymentName = "gpt-4o";
 
AzureOpenAIClientOptions azureOpenAIClientOptions = new();
azureOpenAIClientOptions.AddPolicy(new CustomLoggingPolicy(), PipelinePosition.BeforeTransport);
 
AzureOpenAIClient azureOpenAiClient =
    new(new Uri("<openai-endpoint>"), new DefaultAzureCredential(), azureOpenAIClientOptions);
 
ChatClient chatClient = azureOpenAiClient.GetChatClient(deploymentName);
 
List<ChatMessage> chatMessages =
[
    // messages
];
 
ChatCompletionOptions chatCompletionOptions = new()
{
    // options
};
 
ClientResult<ChatCompletion> clientResult
   = await chatClient.CompleteChatAsync(chatMessages, chatCompletionOptions);

CustomLoggingPolicy

Say you want to add a Custom Retry policy, then you can implement a class that inherits from ClientRetryPolicy and override ShouldRetryAsync method.

public class CustomClientRetryPolicy : ClientRetryPolicy
{
    protected override async ValueTask<bool> ShouldRetryAsync(PipelineMessage message, Exception? exception)
    {
        if (message.Response.Status == (int)HttpStatusCode.RequestEntityTooLarge)
        {
            return false;
        }
 
        return await base.ShouldRetryAsync(message, exception);
    }
}

Usage:

AzureOpenAIClientOptions azureOpenAIClientOptions = new();
...
azureOpenAIClientOptions.RetryPolicy = new CustomClientRetryPolicy();

Hope this helps.

Happy Coding.

Regards,

Jaliya

EF Core 9.0: UseSeeding and UseAsyncSeeding

EF Core 9.0 (EF 9) introduced new methods UseSeeding and UseAsyncSeeding to seed the initial data.

Let's have a look at an example.

Consider the following MyDbContext.

public record Blog
{
    public int Id { get; set; }
 
    public string Name { get; set; }
}
 
public class MyDbContext : DbContext
{
    public DbSet<Blog> Blogs { get; set; }
 
    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        optionsBuilder
            .UseSqlServer("<ConnectionString>");
    }
 
    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Blog>(x =>
        {
            x.HasData
            (
               new Blog
               {
                   Id = 1,
                   Name = "Some Blog"
               }
            );
        });
    }
}

Here in the above example, some data is seeded through Model-managed data which is handly when we want to include seed data in migrations as well and it was available for as far as I can remember.

Now let's see where UseSeeding and UseAsyncSeeding come in.

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    optionsBuilder
        .UseSqlServer("<ConnectionString>")
        .UseSeeding((context, _) =>
        {
            Blog? blog = context.Set<Blog>().SingleOrDefault(b => b.Name == "Some Other Blog");
            if (blog is null)
            {
                context.Set<Blog>().Add(new Blog { Name = "Some Other Blog" });
                context.SaveChanges();
            }
        })
        .UseAsyncSeeding(async (context, _, cancellationToken) =>
        {
            Blog? blog = await context.Set<Blog>().SingleOrDefaultAsync(b => b.Name == "Some Other Blog", cancellationToken);
            if (blog is null)
            {
                context.Set<Blog>().Add(new Blog { Name = "Some Other Blog" });
                await context.SaveChangesAsync(cancellationToken);
            }
        });
}

As you can see, the new seeding methods are available as part of configuring DbContextOptions. Unlike Model-managed data, you can seed data for multiple DbSets all from a single place. These methods will get called as part of EnsureCreated operation, Migrate and dotnet ef database update command, even if there are no model changes and no migrations were applied.

Now let's see this in action.

using var context = new MyDbContext();
await context.Database.EnsureDeletedAsync();
await context.Database.EnsureCreatedAsync();
 
foreach (Blog blog in context.Blogs)
{
    Console.WriteLine(blog.Name);
}
 
// Output:
//Some Blog
//Some Other Blog

And a note from the official documentation:

UseSeeding is called from the EnsureCreated method, and UseAsyncSeeding is called from the EnsureCreatedAsync method. When using this feature, it is recommended to implement both UseSeeding and UseAsyncSeeding methods using similar logic, even if the code using EF is asynchronous. EF Core tooling currently relies on the synchronous version of the method and will not seed the database correctly if the UseSeeding method is not implemented.

More read:
   EF Core: Data Seeding

Happy Coding.

Regards,
Jaliya

Blazor Web App: Adding Custom Claims to Current User

I recently had a requirement where I want to add Custom Claims to the current user in a Blazor Web Application. I used IClaimsTransformation, but it doesn't work with Blazor. Instead, the correct option for Blazor is to implement a custom AuthenticationStateProvider.

public class ApplicationAuthenticationStateProvider : AuthenticationStateProvider
{
    private readonly AuthenticationStateProvider _authenticationStateProvider;
    private readonly IUserService _userService;
 
    public ApplicationAuthenticationStateProvider(AuthenticationStateProvider AuthenticationStateProvider, IUserService userService)
    {
        _authenticationStateProvider = AuthenticationStateProvider;
        _userService = userService;
    }
 
    public override async Task<AuthenticationState> GetAuthenticationStateAsync()
    {
        AuthenticationState authenticationState = 
            await _authenticationStateProvider.GetAuthenticationStateAsync();

        if (authenticationState.User.Identity?.IsAuthenticated != true)
        {
            return authenticationState;
        }
 
        // Check if user already has the UserId claim
        if (authenticationState.User.HasClaim(x => x.Type == ApplicationClaimTypes.UserId))
        {
            return authenticationState;
        }
 
        // TODO: Get the user from the database using current claims and IUserService
        string applicationUserId = "someUserId";
 
        ClaimsIdentity claimsIdentity = new ClaimsIdentity();
        claimsIdentity.AddClaim(new Claim(ApplicationClaimTypes.UserId, applicationUserId));
 
        authenticationState.User.AddIdentity(claimsIdentity);
 
        return authenticationState;
    }
}

Register ApplicationAuthenticationStateProvider,

builder.Services.AddScoped<ApplicationAuthenticationStateProvider>();

Use,

// This is some service where you want to use authenticationState
public class BlazorIdentityService : IIdentityService
{
    private readonly ApplicationAuthenticationStateProvider _applicationAuthenticationStateProvider;
 
    public BlazorIdentityService(ApplicationAuthenticationStateProvider applicationAuthenticationStateProvider)
    {
        _applicationAuthenticationStateProvider = applicationAuthenticationStateProvider;
    }
 
    public async Task<string> GetCurrentUserId()
    {
        AuthenticationState authenticationState = 
            await _applicationAuthenticationStateProvider?.GetAuthenticationStateAsync();
 
        return authenticationState.User?.Claims?.SingleOrDefault(x => x.Type == ApplicationClaimTypes.UserId)?.Value;
    }
}

Hope this helps.

Happy Coding.

Regards,

Jaliya

Azure APIM Backends with OpenAPI Specifications: Importance of operationId

I recently faced an issue in one of the APIs where as part of importing OpenAPI to Azure APIM, it started throwing an error: "(ValidationError) Operation with the same method and URL template already exists".

Let's have a look at a Minimal Reproducible Example (MRE).

Say I have the following ASP.NET Core API controller that is getting exposed in OpenAPI Spec.

[Route("api/some/very/very/very/very/very/very/very/very/very/very/very/very/very/very/very/long-resources")]
[ApiController]
public class ValuesController : ControllerBase
{
    [HttpGet]
    public IEnumerable<string> Get()
    {
        return ["value1", "value2"];
    }
 
    [HttpGet("{id}")]
    public string Get(int id)
    {
        return "value";
    }
}

When I import this to APIM, it's getting imported.

Note the operationId. 

OpenAPI Specification

Since the code hasn't explicitly specified an operationId, APIM is generating the operationId by following a convention (see Normalization rules for operationId).

Now let's remove the first endpoint and try to import again.

[Route("api/some/very/very/very/very/very/very/very/very/very/very/very/very/very/very/very/long-resources")]
[ApiController]
public class ValuesController : ControllerBase
{
    [HttpGet("{id}")]
    public string Get(int id)
    {
        return "value";
    }
}

This time I am getting the error.

(ValidationError) Operation with the same method and URL template already exists

Since we no longer have multiple operations, now for the operationId no de-duplication suffix will be used, but the newly generated operationId is the same operationId that was previously used for"GET: /api/some/very/.../long-resources" endpoint.

We can fix this by adding operationId in the code, as follows.

[Route("api/some/very/very/very/very/very/very/very/very/very/very/very/very/very/very/very/long-resources")]
[ApiController]
public class ValuesController : ControllerBase
{
    [HttpGet("{id}", Name = "GetValueById")]
    public string Get(int id)
    {
        return "value";
    }
}

Explicit operationId

So as a practice, we should always consider explicitly specifying operationId in our code rather than letting APIM auto-generate one.And this is going to be very important if you are using APIOps and has custom APIM policy overrides for operations. Because the policies are maintained by operationId and if operationId generation convention is changed for some reason, your APIOps deployments will fail.

Hope this helps.

Happy Coding.

Regards,

Jaliya

Blazor Web App: Authentication Redirect URI is not HTTPS

.NET 9 is finally out and I was playing around with Blazor. I was setting up Authentication in a .NET 9 Blazor Web App. The authentication is configured with AzureAD, and locally everything was working fine. The application was running on HTTPS and the redirect_uri was HTTPS too.  

When the application was deployed to Azure, the Authentication was failing, because the redirect_uri was HTTP.  In Azure AD App Registration I configured it with HTTPS (HTTP is allowed only when using localhost). The application was running inside a Linux Container in an Azure Web App.

In order for redirect_uri to be HTTPS, I had to do the following:

1. Enable UseForwardedHeaders

WebApplicationBuilder builder = WebApplication.CreateBuilder(args);
 
builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
    options.ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
});
// Other service registrations
 
WebApplication app = builder.Build();
 
// Note: Forwarded Headers Middleware should run before other middleware. 
// This ordering ensures that the middleware relying on forwarded headers information can consume the header values for processing. 
// Forwarded Headers Middleware can run after diagnostics and error handling, but it MUST BE RUN before calling UseHsts
app.UseForwardedHeaders();
 
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error", createScopeForErrors: true);
    app.UseHsts();
}
 
app.UseHttpsRedirection();
// Other middleware
 
app.Run();

2. Add the following app setting in Azure (More: Forward the scheme for Linux and non-IIS reverse proxies)

{
  "name": "ASPNETCORE_FORWARDEDHEADERS_ENABLED",
  "value": "true",
  "slotSetting": false
}

And that did it.

Hope this helps.

Happy Coding.

Regards,
Jaliya

Azure APIM: Policy Expression to Read application/x-www-form-urlencoded Request Data

Recently I had a requirement where a particular Client sends some request data as application/x-www-form-urlencoded and needed to get those moved to the request header before it gets forwarded to the Backend.

In this post, let's see how we can read request data sent via application/x-www-form-urlencoded.

If we have a look at .NET Framework types allowed in policy expressions, we have access to System.Net.WebUtility.

So we can make use of that as follows:

<policies>
    <inbound>
        <!--Extract URL Encoded Form Data (if any)-->
        <set-variable name="serializedFormData" value="@{
            var formData = new System.Collections.Generic.Dictionary<String, String>();
            if(context.Request.Headers.GetValueOrDefault("Content-Type", "") != "application/x-www-form-urlencoded")
            {
                return JsonConvert.SerializeObject(formData);
            }
 
            string encodedBody = context.Request.Body.As<String>(preserveContent: true);
            string decodedBody = System.Net.WebUtility.UrlDecode(encodedBody);
            foreach (string key in decodedBody.Split('&'))
            {
                string[] keyValue = key.Split('=');
                formData.Add(keyValue[0], keyValue[1]);
            }
 
            return JsonConvert.SerializeObject(formData);
        }" />
        <!--Check if the interested headers are sent in the form data-->
        <set-variable name="isRequiredHeadersSentInFormData" value="@{
            string serializedFormData = context.Variables.GetValueOrDefault<String>("serializedFormData");
            System.Collections.Generic.Dictionary<String, String> formData = 
                JsonConvert.DeserializeObject<System.Collections.Generic.Dictionary<String, String>>(serializedFormData);
 
             return formData.ContainsKey("key1") && formData.ContainsKey("key2");
        }" />
        <!--Set the headers from the form data if present-->
        <choose>
            <when condition="@(context.Variables.GetValueOrDefault<bool>("isRequiredHeadersSentInFormData"))">
                <set-header name="x-key1" exists-action="override">
                    <value>@{
                        string serializedFormData = context.Variables.GetValueOrDefault<String>("serializedFormData");
                        System.Collections.Generic.Dictionary<String, String> formData = 
                            JsonConvert.DeserializeObject<System.Collections.Generic.Dictionary<String, String>>(serializedFormData);
 
                        return formData["key1"];
                    }</value>
                </set-header>
                <set-header name="x-key2" exists-action="override">
                    <value>@{
                        string serializedFormData = context.Variables.GetValueOrDefault<String>("serializedFormData");
                        System.Collections.Generic.Dictionary<String, String> formData = 
                            JsonConvert.DeserializeObject<System.Collections.Generic.Dictionary<String, String>>(serializedFormData);
 
                        return formData["key2"];
                    }</value>
                </set-header>
            </when>
        </choose>
        ...
    </inbound>
    ...
</policies>

And now we test with trace, we can see the request is correctly being transformed.

Trace

Hope this helps.

Happy Coding.

Regards,

Jaliya

.NET 9.0: Out-of-order Metadata Reading in System.Text.Json

Release of .NET 9.0 is like 3 weeks away and in this post, let's have a look at one of the most awaited System.Text.Json features.

Let's have a look at an example.

Consider the below types.

[JsonDerivedType(typeof(Student), "student")]
record Person(string Name);
 
record Student(string Name, string StudentId) : Person(Name);

The following code will throw an error on Deserialize.

using System.Text.Json.Serialization;
using System.Text.Json;
 
JsonSerializerOptions options = new();
 
Person person = new Employee("John Doe", "STU001");
string serializedPerson = JsonSerializer.Serialize(person, options);
// {"$type":"student","StudentId":"STU001","Name":"John Doe"}
 
// Change the order of $type
serializedPerson = """
{
    "StudentId":"STU001",
    "Name":"John Doe",
    "$type":"student"
}
""";
 
person = JsonSerializer.Deserialize<Person>(serializedPerson, options)!; // Exception
// System.Text.Json.JsonException: The metadata property is either not supported by the type or is not the first property in the deserialized JSON object.

The reason is (as the exception says) that the metadata property $type is not the first property in the JSON string, and it has to be. While there is a reason for that requirement, until .NET 9, it was a known limitation (see #dotnet/runtime/issues/72604).

Finally, in .NET 9, we can enable AllowOutOfOrderMetadataProperties in JsonSerializerOptions.

JsonSerializerOptions options = new()
{
    AllowOutOfOrderMetadataProperties = true
};

And now the above would work just fine.

Hope this helps.

Happy Coding.

Regards,

Jaliya

Ingressing Custom Text Log Files from an Azure Virtual Machine into Log Analytics

I recently had a requirement where I wanted to see some logs in an Azure Virtual Machine, but didn't want to SSH into the VM to see the logs. Instead, it would have been nice if I could see those in a Log Analytics workspace (LAW) in Azure. This gives a lot of advantages, like I can set up alerts on those logs if I want to.

So in this post, let's see how we can ingress some logs that is being written into some custom log file in an Azure Virtual Machine into LAW.

Assuming we already have a LAW created, the first step is creating a custom table there to ingress the logs into.

# Connect-AzAccount
$tableName = "<TableName>_CL"
$tableParams = @"
{
    "properties": {
        "schema": {
            "name": "$tableName",
            "columns": [
                {
                    "name": "TimeGenerated",
                    "type": "DateTime"
                },
                {
                    "name": "RawData",
                    "type": "String"
                },
                {
                    "name": "FilePath",
                    "type": "String"
                },
                {
                    "name": "Computer",
                    "type": "String"
                }
            ]
        }
    }
}
"@
 
Invoke-AzRestMethod `
    -Path "/subscriptions/<SUBSCRIPTION_ID>/resourcegroups/<RESOURCE_GROUP>/providers/microsoft.operationalinsights/workspaces/<LAW_NAME>/tables/$($tableName)?api-version=2021-12-01-preview" `
    -Method PUT `
    -payload $tableParams

Here I am using a default template as for the demo purposes I am not doing any transformations.

Make sure the table is created in your LAW.

Log Analytics Workspace

Next, I am going to Azure Monitor (search for Monitor in Azure Portal) and creating a Data Collection Endpoint (DCE).

Create data collection endpoint

It's pretty straightforward.

Now from Azure Monitor, I am creating a Data Collection Rule (DCR).

Create Data Collection Rule

My VM is on Linux so I am selecting Linux as the Platform Type, and I am selecting the DCE I created in the previous step as the Data Collection Endpoint.

Next on Resources, I am adding a new Resource and selecting the target VM and the DCE.

Create Data Collection Rule: Resources

Now going to Collection and deliver tab and selecting a Data Source of type Custom Text Logs.

Add data source: Custom Text Logs

Add data source: Custom Text Logs

Here, for the File pattern, I am giving the path of the file where I need the logs ingested from and for the Table name, giving the name of LAW table I created before. And for the Transform, I am leaving it as it is.

Now configuring the destination as Azure Monitor Logs as follows.

Add data source: Custom Text Logs

And that's it. I am creating the DCR and Azure will deploy Azure Monitor Agent to the target VM and configure the ingestion.

And once deployment is completed, after some time, I can see the logs in LAW.

Ingested Logs

More read:
   Data collection rules (DCRs) in Azure Monitor
   Collect data with Azure Monitor Agent
   Troubleshooting guidance for the Azure Monitor agent on Linux virtual machines and scale sets

Hope this helps.

Happy Coding.

Regards,

Jaliya