I am not able to make the azure generic webhook function work with
authlevel keys (function/host/anonymous etc.)
I created a generic webhook function. I understand it is by default protected with function key auth level - is this correct? In such case how to change the authlevel to Host or anonymous?
Next I am calling it from a request-response logic app flow. So I get a request, call the function and then respond back with the result from the function. From the code view of logic app I cannot see any function call that is taking the code and client as parameters. So my question is why is the function call not failing. Is this happening in anonymous mode? Or is there any way the logic app is calling the function with the appropriate parameters (code and clientid) which is not shown even in the code view? Perhaps I am missing some very basic thing - appreciate any help in this regard.
In such case how to change the authlevel to Host or anonymous?
When creating a generic webhook function, you could set the mode for your trigger and the Mode notes as follows:
The mode of the trigger. "Standard" means that the request will be standard HTTP with no additional semantics. "Webhook" means that the request will be processed according to a specified webhook type.
The authLevel property in function.json file does not apply to the WebHook triggers. To trigger a WebHook function the HTTP request must include an API key (e.g. https://<yourapp>.azurewebsites.net/api/<function>?code=<Host key or Function key>). You could choose your generic webhook function, choose your HTTP trigger, then click the Documentation link for more detailed tutorials about HTTP and webhook bindings.
Next I am calling it from a request-response logic app flow. So I get a request, call the function and then respond back with the result from the function.
Based on your scenario, I did the sample flow as follows:
You just need to choose your generic webhook function and logic app would handle the authorization for you. Moreover, the API keys are stored under D:\home\data\Functions\secrets folder, you could use kudu and find them in the host.json or <function-name>.json file. Also, here is a tutorial using PowerShell to access KUDU REST API for retrieving Azure Function key. Additionally, you could add your comment here.
Related
I have an Azure Event Grid topic:
https://xxx.westeurope-1.eventgrid.azure.net/api/events
Is there any way to direct clients to publish events to https://xxx.mydomain.com/api/events without getting certificate validation errors, etc.?
It would appear, after researching further documentation and speaking to Microsoft that this is currently not possible. If you create a CNAME entry in your own DNS to point to the Azure fqdn of the endpoint, certificate errors are (understandably) generated.
You could use some type of API gateway to accomplish this. The gateway would have your desired domain name and route for the public to submit requests. A service
behind the gateway would forward the request to the event topic's endpoint.
Another option, but based on the same idea mentioned above, would be to use Azure Functions. The function becomes the gateway and the client publishes to the function's endpoint. Code within the Azure Function bundles the request and forwards it to the event topic.
I'm currently using the Functions approach. My function accepts a generic JSON body, validates a few things, packages it up so it has everything the event topic needs (access keys, headers, correct properties for the event schema, etc), and sends it off to the event topic endpoint. If everything works, I send the client a 200 HTTP status from the Azure Function. If there's a problem, I send a 400 or 500 series status as appropriate.
I came across the term Webhook recently (in Azure Alerts, Github deployment, etc.). In my effort to understand the difference between API and Webhook, I read the explanations in stackexchange and sendgrid. My understanding is that the difference is in the way an API is invoked. But this sounds confusing. I think any API does following,
may accept some inputs
perform some action
respond to the caller
If the above mentioned is true, then there is no need for APIs to be categorised based on how they are invoked. At least, this is true from coding perspective as the API is going to work anyway as long as it is invoked and gets the inputs (if required).
Just to explain my understanding of these terms with an example, Azure currently offers (in preview mode as of writing this question) creating Action Groups while setting up Alerts. Two of the alert types supported are Azure Function and Webhook. I could create a Http Trigger Azure function and use it in two Alerts where first one is of Azure Function type and the second one is of the Webhook type. To my surprise, the Webhook type Alert works even though I am using a Http Trigger Azure function (note that, Azure offers template for creating Webhook Azure function too). Below given is the Http Trigger Azure Function I wrote to setup the Webhook for Alert (actual link to code with instructions).
#r "Newtonsoft.Json"
using System.Net;
using Newtonsoft.Json;
using Newtonsoft.Json.Linq;
public async static Task<HttpResponseMessage> Run(HttpRequestMessage req, TraceWriter log, ICollector<string> outputQueueItem)
{
log.Info("C# HTTP trigger function processed a request.");
string jsonContent = await req.Content.ReadAsStringAsync();
JToken activityLog = JObject.Parse(jsonContent.ToString())
.SelectToken("data.context.activityLog");
//captures the details of the resource group being modified
log.Info(string.Format("Resource group '{0}' was {1} on {2}.",
(string)activityLog["resourceGroupName"],
((string)activityLog["subStatus"]).ToLower(),
(DateTime)activityLog["eventTimestamp"]));
return req.CreateResponse(HttpStatusCode.OK);
}
At least in the Azure example, it looks like the Webhook Azure function does nothing special, otherwise the Webhook type Alert would not have worked with a Http Trigger Azure function. So, is there any difference in the way of coding or thought process when you code a REST API and Webhook using WebAPI?
Functionally, there is no real difference, but they are different.
With an API, the author defines the spec (audience, protocol, verb, arguments, etc.) for the given endpoint, whereas with a Web Hook, this is specified by a third party.
It is important to maintain the differentiation, as it will help you or other developers to understand how the function is being consumed, and, in the case of a Web Hook, what parts of your solution will be impacted if its intended consumer changes its specification.
After diffing through both Azure HTTP Trigger as well as the "Generic Web hook" functions, I see no difference except that the Web hook mode are offered on both constructs and can be interchangeably used, where the Web hook mode needs a API key whereas its optional on the HTTP Trigger construct.
The Generic JSON option lets you dictate how your Web hook can look like unlike third party providers like Git or Slack.
I am not sure if this is an option. I require it badly, and cannot find any references of it.
When integrating between an HTTP Triggered Azure Function within your Logic App flow, you are requested to pass a body object for the function to digest:
I am hoping for a way to customize the Request Body inputs, to make it have a strict template structure, in and out.
In:
Out:
(The function returns an Object)
Is there any way I can achieve this?
You could create a Logic Apps Custom Connector.
You can create one of these from a Postman collection or using an OpenAPI definition. You can get hold of the OpenAPI definition from the Function App.
With a custom connector, you have a bit more control over the request and response. This will allow the users of your connector to provide inputs when used in a Logic App and also receive tokens from the response. These can then be used in further Logic App steps.
Just hard coded it to the fields I require it using the Logic App syntax and it responds to satisfaction
#{body('function-name')?['property']}
Haven't tried the Custom Connector
If I have an API-only app in Azure App Service where users can send a callback URL in the request. The app sends a POST request to the callback URL upon completion.
There are some complexities in implementing calling a callback URL, for example: retries, time between retries, etc.
Is there a service, or set of services, in Azure that can help me implement a callback URL? For example, in AWS the Simple Notification Service (SNS) allows me to send a "push" to a HTTPS endpoint with retries, etc.
Without knowing what sort of context you might need for your callback, you could drop a message in a service bus queue or topic and then write a simple logic app or function which is triggered by the presence of a new message in the queue or topic.
A logic app would provide a solution with no code, only config. A function would require some very basic coding. Logic apps have built in retry features.
Here is an example which somewhat resembles what I think you're after.
I wanna build a small workflow using Azure Logic Apps that contains an "Approval" step, which is simply an API call in my own system, similar to office 365 approval connector.
However, from what I found on the internet, the only way to make a long running task in Azure Logic Apps is to use Webhooks.
In Webhooks, I could not set a value to the parameter I created "Bool-Approved".. so, How can I check it later in a condition step?
The other possible solution maybe is to use Swagger to have an "Bool-Approved" parameter. However, it does not support long running action!
What's the possible solution for me?
As you mentioned, the way to do it is to use the Webhook action, and for that you need to implement the Subscribe/Unsubscribe pattern described here. The webhook action will allow you to get any payload (via an HTTP Post) from the instance-based webhook you are subscribing to.
The points below are a summary of this blog post:
https://www.mexia.com.au/correlation-identifier-pattern-on-logic-apps/
To implement the Subscribe/Unsubscribe Webhook pattern you need to consider:
Subscription store: A database to store the unique message Id and the
instance-based callback URL provided by the webhook action.
Subscribe and Start Request Processing API: this is a RESTful API that is in charge of starting the processing of the request and storing the
subscription.
Unsubscribe and Stop Request Processing API: this is another RESTful API that is only going to be called if the webhook action on the main workflow times out. This API is in charge of stopping the processing and deleting the subscription from the store.
Instance-based webhook: this webhook is to be triggered by your own custom approval event. Once triggered, your webhook is in charge of getting the instance-based callback URL from the store and invoking it. After making the call back to the main workflow instance, the subscription is to be deleted. This is the webhook that is in charge of sending the payload you require to the waiting webhook action in your Logic App.
The subsequent actions will be able to use that response body, so you can implement your conditions, etc.
You can follow the blog post mentioned above to see a detailed example and get more details on how to implement it.
make you api return HTTP code 200 if the response if "ok" and 400 if the response is "not ok". This way you can force logic app to behave the way you need it to behave..