I have multiple RESTful APIs that are hosted in azure web app / azure service plans and covered by application insights
I have setup availability tests on top of these API using application insights which when triggered call an azure function
There is an auto resolve setting for availability tests which lets your hook up alerting when the availablity issue has been resolved.
However I didn't find anything on similar lines for Failure Anomalies
Question:
How do I setup a webhook call back on azure application insight failure anomaly detection ?
Related
I have a Node.js API (built with Express.js) hosted on Firebase Cloud Functions and an accompanying web application hosted on Firebase Hosting which is supposed to interact with the aforementioned API.
I would like to restrict calls to the API so that only the web application would be able to call the cloud functions. How can I achieve that?
What I have tried:
using the App Check or more precisely Google's reCAPTCHA v3 for web apps. I have whitelisted the domain of the web application and have activated App Check token validation server side as well. The problem with App Check, however, is that I am able to obtain the reCAPTCHA attestation token from the browser (after authenticating through the web app) and use that with requests made from anywhere. This enables bombarding the API from outside the web application and defeats the purpose of using App Check in the first place.
Something to note here, the documentation for activating App Check in Cloud Functions instructs the usage of functions.https.onCall(). However, since my API is built using Express.js, I had to use a workaround to be able to use functions.https.onRequest() as instructed here.
restricting the Cloud Function from Google Cloud console to allow only clients of the same project to call the function as instructed here. Unfortunately, my web application hosted on Firebase Hosting does not seem to belong under the same Google Cloud project. Apps hosted on Firebase Hosting do not appear in Google Cloud console. Furthermore, after adjusting the Ingress settings of the functions to "allow internal traffic only", I am receiving CORS errors when attempting to access the API through the web application. I am unable to access the API from anywhere else though, which is partly the desired outcome.
Before anyone proposes limiting the domains in CORS options from within the API, while this might serve the purpose of restricting access to the API endpoints, it still would allow calling the function rapidly and thus, potentially, racking up the bill.
I am grateful for any suggestions!
Firebaser here.
This is a great question! Doug has already made some great points above, and I'll just add to that by saying that the TTL on App Check tokens reduce the replay window that you observed in your first bullet point, and this TTL is configurable.
The default TTL for reCAPTCHA v3 is 1 day to protect against running out of quota, but you can set a shorter TTL to increase the cost for an attacker trying to set up a replay attack. But please do be mindful of the associated trade-offs as described in the documentation. You can read about the associated quotas and limits here.
Unfortunately, web applications redirected from Firebase Hosting can't hook up to the GCP internal network. App Check is actually exactly what you are looking for in this situation.
Finally, because we are continuously working on improving the App Check platform, the comments you leave here are valuable for us as we decide on what anti-abuse features we want to work on next.
I have a ASP.NET Web API controller that provides a saveAndNew operation.
This class is derived from System.Web.Http.ApiController as expected.
Application Insights is correctly configured using version 2.1.0 of the SDK and the default settings in ApplicationInsights.config.
If a request to the mentioned operation fails - for example with status code 400 - the request is recorded correctly in App Insights.
The problem is that if the operation SUCCEEDS (status code 200) nothing is recorded in Application Insights.
I've used Fiddler to see if the request is made to the App Insights track service and it is not. So the problem is not in the configuration of Application Insights on the Azure portal.
I can't figure out what is preventing ALL requests to my Web API controllers operations from being recorded.
Can anyone help?
You might want to try removing/commenting out TransferRequestHandler in ApplicationInsights.config file.
GitHub issue "REST API app can have all requests filtered out" here states that: "commenting out the one line in the ApplicationInsights.config caused successful requests to start getting logged. Web API 2 project.
<!--<Add>System.Web.Handlers.TransferRequestHandler</Add>-->
I have a ASP.NET Web API controller that provides a saveAndNew operation.
This class is derived from System.Web.Http.ApiController as expected.
Application Insights is correctly configured using version 2.1.0 of the SDK and the default settings in ApplicationInsights.config.
If a request to the mentioned operation fails - for example with status code 400 - the request is recorded correctly in App Insights.
The problem is that if the operation SUCCEEDS (status code 200) nothing is recorded in Application Insights.
I've used Fiddler to see if the request is made to the App Insights track service and it is not. So the problem is not in the configuration of Application Insights on the Azure portal.
I can't figure out what is preventing ALL requests to my Web API controllers operations from being recorded.
Can anyone help?
You might want to try removing/commenting out TransferRequestHandler in ApplicationInsights.config file.
GitHub issue "REST API app can have all requests filtered out" here states that: "commenting out the one line in the ApplicationInsights.config caused successful requests to start getting logged. Web API 2 project.
<!--<Add>System.Web.Handlers.TransferRequestHandler</Add>-->
I have backend(e.g. https://api.myapp.com) based on the Azure Mobile services(AMS), now I need
1. add one or two apis that doesn't require to be on AMS e.g. an heartbeat controller to check that service is online or not, that doesn't require Zumo Auth
2. an ASP.net MVC page(e.g. https://www.myapp.com) that explains about the application
Can I use the existing AMS to do this, I tried to add plain asp.net web api, but getting error that end point doesn't exist
Are you truly using Azure Mobile Services and not Azure Mobile Apps? You generally cannot have a custom domain on Azure Mobile Services. Since you mention ZUMO Auth 2, I'm assuming you mean App Service Auth and thus Azure Mobile Apps.
I'd recommend taking a look at Azure Functions for any APIs that do not require ZUMO. However, you can just add a custom API to your service. I cover all the options for you in my book - http://aka.ms/zumobook - chapter 4.
As to a service controller for checking heartbeat. If the intent is to ensure that the service is alive, then just create an unauthenticated custom API that tests the database connectivity (maybe does an SQL command to get the count of rows in your main table) and returns success or failure. You can then use Azure Functions, Azure Scheduler or OMS to do a query of that custom API.
I have built a simple Chat application using SignalR followed the tutorial there, which works great.
Then I followed the tutorial of SignalR Scaleout with Azure Service Bus, also from Microsoft.
So I have completed all the following steps:
Created a new Cloud Service on Azure Portal
Created a new Service Bus namespace on Azure Portal
Created a Windows Azure Cloud Service with a SignalR ASP.NET Web Role
Setup the SignalR Web Role running on 2 instances (VM Size: Small)
Deployed the Cloud Service to the Azure Cloud Service.
But I can't get the SignalR Chat application to work. Can't start the hub.
I noticed it tried to use longPolling and shows status Cancelled/Abort in the browser's debugging tool (Chrome) with the following error in the console:
WebSocket connection to 'ws://example.cloudapp.net/signalr/connect?transport=webSockets&clientProtocol=1.5&connectionToken=KOlz9psd6yCqvYjmCbI3ch5mrXcP%2BAAl3JVMFaP24p2Cv%2FyRb94D5uE27SO9Bz%2B5Itba4vADtv3%2Btv2FMF9LJI6Zxr026UJYxDPNQMVpFTw2hiHd&connectionData=%5B%7B%22name%22%3A%22schathub%22%7D%5D&tid=10' failed: Error during WebSocket handshake: Unexpected response code: 400
and this is the log in the Network:
Do I need to do anything extra besides all the steps listed in the tutorial to make this work?
Based on the current Pricing, you need to set the Service bus to at least Standard tier to support Topics.
In this case, I did create my service bus choosing Standard tier, although it shows Standard on it's Overview page under the "Pricing tier" section, I have to specifically go to the settings and scaled it up from Basic to Standard. Which has solved the problem.