Knoxbits Blog

Here's a way to get the Azure Service Bus output binding for your Azure Function working after you've enabled Duplicate Detection (or other features) on the Service Bus queue or topic. If you haven't had duplicate detection turned on or haven't been using some of the other Azure Service Bus features, you might set up the output binding in your Azure Functions so you can send a custom class object to a Service Bus queue or topic. Something like the following. [FunctionName("MyFunction1")] public static async Task<IActionResult> Run( [HttpTrigger(AuthorizationLevel.Function, "get", Route = null)] HttpRequest req, [ServiceBus("%MyQueueName%", Connection = "MyServiceBusConnection")] IAsyncCollector<MyItem> myOutputQueue) {     var myItem = new MyItem();     // Do stuff.     // . . .     // Add the item to the queue.     await myOutputQueue.AddAsync(myItem);     // Do more stuff.   ...

(Source code updated Feb. 16, 2022, to .NET 6 and Azure Functions v4) I implemented a sample serverless API as an HTTP triggered Azure Function that is protected to ensure that only authorized apps can access that API. The sample Azure Function works when used with an authorization server that supports OpenID Connect (OIDC) and OAuth 2.0 protocols. Service providers that support compatible authorization servers include Auth0 , okta and many others. The complete sample code is in GitHub here . What follows is my high-level description of the concepts and API-side implementation of the mechanisms used to protect an API implemented as an HTTP triggered Azure Function using the OAuth 2.0 Client Credentials Flow. Here’s the breakdown of what follows: What’s in the sample code. Some context, a high-level description of the OIDC and OAuth 2.0 flows used. How to make a call to a protected API. How the code that protects the API is called within an HTTP triggered Azure Function. Th...