I am using this code to print the TLS Version (e.g. Tls12) when running a WebAPI project locally.
var tlsHandshakeFeature = context.Features.Get<ITlsHandshakeFeature>();
Console.WriteLine(tlsHandshakeFeature.Protocol);
After deploying the project to an Azure Web App, I get a NullReferenceException when accessing the Protocol property.
How can I retrieve the TLS version used for the current request when running a Dotnet Core Web API project on Azure?
Of course, the Azure Application Gateway terminates SSL/TLS client connections, so there is no direct connection between client and the application. But the gateway passes meta data to the application and so I somewhat assume (optimistically) the APIs in .NET Core may support this environment.
Because of the Termination of the TLS connection at the Azure Application Gateway, the available information at the application container is limited.
I examined the HTTP X-Headers and the TLS version has not been recorded. So the problem simply is the gateway does not report the needed information to the application.
Related
I'm pretty new to Azure, and I wanted to get familiar with using Azure AD auth as an authentication provider for a dotnet core web app.
I followed this tutorial: https://learn.microsoft.com/en-us/azure/app-service/tutorial-auth-aad?pivots=platform-linux
It worked as described, but I have to be missing something, because the way it's deployed doesn't make any sense to me.
The "starting point" tutorial code is this repo, here: https://github.com/Azure-Samples/dotnet-core-api
It's a simple dotnet core web app that hosts an Angular frontend. Through the course of the tutorial, you make some changes to get the "frontend" to talk to the "backend", and you add two remotes to your Git repo - frontend and backend - but they're on the same repo.
As I understand it, at the end of this tutorial, I have two nearly-identical Azure App Service instances running in my Azure resource group. They are both running the same code. Both include the full-stack application - both are hosting a Kestrel or HTTP.sys (or whatever) instance on port 443 at their respective .azurewebsites.net URL - both show my index.html page - but one is supposed to be the "frontend" and the other is supposed to be the "backend". The only thing different about the "frontend" and "backend" is that the "backend" has an identity provider configured, and the "frontend" has API permissions granted to it from the "frontend".
Is it really necessary to have the whole service running in both places? Is there a way to host the actual dotnet core API service as an App Service, host the HTML / JS / CSS separately as an Azure Static Page (or something similar), and still configure the identity provider? Or does it have to be like this? It seems like overkill, from a technical standpoint, as well as from a billing standpoint.
As #Caius Jard mentioned, we can include both of them in a single solution. We can actually use MVC Web Application in this case where we can create a frontend in view and write the actual code in control. If we are using a core application then we can create the backend and frontend in two environments such as Angular for Frontend and .Net core for Backend and integrate them.
REFERENCES:
Azure AD Authentication For MVC Web Application (c-sharpcorner.com)
Angular and .Net core - Azure AD authentication | The-worst.dev
Is it still possible to self-host a SignalR Hub (server) without using IIS / Kestrel?
MS does not have any information as though if it is still possible (using asp.net core migration) to achieve this.
My use case for this would be to be able to deploy both the client and the server to local machines and then be able to easily switch to remote servers at a later stage. Ideally, the client would host the server for now.
ASP.NET Core implies using Kestrel as its web server. That means that in order to host a SignalR hub (server), you will need to use Kestrel and basically build an ASP.NET Core application.
You will however not need to use IIS or some other web server to host the application. Kestrel on its own already is a full web server, so you can use it directly without needing anything else.
The ASP.NET Core application hosting your SignalR hub also doesn’t need to do any other web-stuff. It would be totally fine for it to just contain the single hub and host just that. So you usually don’t need to worry about it too much.
So, to address your use case: Yes, you could have a separate ASP.NET Core application hosting the hub and start that directly on the client and the client could connect to it. And then later you could have another ASP.NET Core application hosting the hub running elsewhere and reconfigure the client to use that one then.
Yes, you can self host .NET Core SignalR.
A SignalR server is usually hosted in an ASP.NET application in IIS, but it can also be self-hosted (such as in a console application or Windows service) using the self-host library.
You can read more about it here.
I have several clients who are using web application hosted in their local IIS server at different locations. Currently all are using version 1.0.
I published the new version of the application say version 1.1, zipped and host in http server at location X.
My application can check if new version is available or not. Now what can be done so that v1.0 at client side can be replaced with new version i.e. 1.1. I want the v1.0 running at client side, automatically (of course with user permission) downloads the v1.1 from http server using internet, extracts the file and host itself in local IIS server.
Is their any method like ClickOnce for web application? I have build the application using asp.net C#. Any 3rd party application or C# code sample would be useful.
I came across your question, if you want to make web apps that are self updating, you can check a solution here http://haacked.com/archive/2011/01/15/building-a-self-updating-site-using-nuget.aspx/, as for updating database, you can add a bootsrapper class that if you are using nHibernate use SchemaUpdate(config).Execute(true, true); that you call on site/index to ensure that the schema is updating. hope thats help
I have a WinRT app that is going to interact with a WebAPI service on my server backed by an Entity Framework managed SQL database (MVC - ASP.NET). For security, I'm only allowing users authenticated on the WinRT side with the Microsoft Live Connect SDK to interact with the WebAPI service. I already have the login code for authenticating with the Live Connect SDK on the WinRT app side working. The WebAPI service is running in the context of an MVC Web Role running on my Azure hosted server.
I've done a lot of reading on StackOverflow and there's a wide range of documents on the topics of authentication, OData, OAuth, Azure Mobile Services, WebAPI and how to combine them:
Live Connect Authentication Token for use on Azure Mobile Services (REST)
How to use a MVC WebAPI OData endpoint securely?
Disable Windows Authentication for WebAPI
I am very concerned that I choose the tools/path that implements only what I need to implement the above scenario and in a secure manner. My main attack concern is un-authenticated users trying to access the ApiController and performing harmful Puts or Deletes. Some questions:
Do I need Azure Mobile Services at all?
What tool(s) do I use or configuration changes do I need to make to manage/pass the Live Connect token between the WinRT app and the service?
Is there a template or NuGet package that I should use that automates much of this?
Is there a document that addresses my scenario or one close to it?
Is there anything built-in to Entity Framework that can help, or conversely has a vulnerability I need to address? If so, what?
What changes do I need to make to the server configuration (web.config)?
I am developing a set of web services using ServiceStack.net. I plan to host these services on Appharbor. I am fairly new to appharbor and cloud hosting in general.
I see that there is an interface within the dashboard to upload my SSL cert. What other configuration do I need to do to AppHarbor and/or my application to get this working properly?
Another note, My Servicestack services will be hosted within an MVC website. I will require all servicestack calls to be made over SSL and have implemented a request filter to check for this and throw a 403 if a non-secure call is attempted.
If you are happy with SNI SSL support, no further configuration should be necessary. Use this gist to determine whether a request is made with an SSL-encrypted connection.