We are going to look at ways on how we can restrict access to our ASP.NET Core Web API.
But first, we will look at ways of debugging ASP.NET Core errors in Azure.
In part 1, we set up both our ASP.NET Core Web API and Blazor Wasm applications into Azure Devops.
In part 2 and part 3, we successfully deployed our ASP.NET Core Web API and Blazor Wasm applications from Azure Devops to Azure servers.
In this tutorial, we are going to force our ASP.NET Core Web API to throw a 500 error. From there, we can go about the steps of identifying a fix.
We can identify an error in Azure when we try to access it and it doesn't work.
In-order to create a 500 error, we went ahead and deleted the connection string from our API app in Azure. This means our API app can no longer connected to the database.
The following page gets displayed when our application has a problem.
Learn Blazor WebAssembly with our online courses
This error doesn't give us much information. It tells us that there is a problem, but it doesn't us what the problem is.
What we need to do is to turn on logging.
In Azure, go into our API app and go to Monitoring and App Service Logs.
We will need to turn on the Application Logging. Personally, I would turn on all the log options on this page.
In addition, assuming we are running an ASP.NET Core Web API, it will prompt us to install the ASP.NET Core site extension.
Once installed, we go to Monitoring and Log Stream in our Azure API app. Make sure that Application Logs is selected.
This will connect to our application and will print out any logs.
Now we go ahead and recreate our 500 error in our Web API. As the 500 error occurs, the full message will be displayed in the Log Stream.
As we have removed the connection string from the ASP.NET Core Web API, we expect to see an error related to the database.
I did find that there was another way of logging errors in Azure.
If we go to Development and Advanced Tools in our Azure API app, it redirects us to Kudu Services for our Web API.
Kudu Services allows us to look at our server environment. We can look at details about our Azure environment, like our app settings and what runtime versions are installed on the server.
We can download the log files by going to Tools and Diagnostic Dump.
This will download all the log files available on the Azure server. This will be downloaded into a zip file.
We can find errors specific to our Web API application by going to the Log Files and Application folders in our zip file.
Setting up access restrictions in our Web API is important. We don't want to expose our Web API to the whole world unless that's the intention.
Watch our tutorial where we talk through the steps on how to restrict a ASP.NET Core Web API application through an IP address.
As well as that, we walk through the steps of debugging a 500 internal server error in an Azure application.
In my opinion, it's worth investing the time setting up our environment in Azure.
We do need a fair bit of time to set up the process. From setting up our Azure Devops environment, to configuring the Azure servers. Then there is continuous integration and deployment.
Don't expect these tasks to be quick and easy.
However, once it's all setup and working, it should make the whole Devops process a lot easier. And we should save a lot of time in the long run!
That means that a developer can concentrate on what they do the best. Developing!
