I have a web application which uses ASP.NET Core 3.1 on an Azure AppService, combined with Azure AD B2C authentication.
In my Startup.cs code, I call UseHttpsRedirection, but when I visit the site with an empty browser cache / or a new incognito session, using the HTTP protocol, I don't get redirected to HTTPS. Because of this, the B2C authentication doesn't work, so my app is not working.
This (HTTP) link is not working.
This link (HTTPS) does work.
What is strange though, once you visited the HTTPS site, and then the HTTP one, you will see the redirection is working.
What are getting served here are static HTML and JS files, served by the ASP.NET Core self-hosted server (running on a Linux AppService).
What do I miss here? Do I need to make an additional setting in Azure or in my code? Or do I need another record in the DNS?
It turned out that you have to go to the Protocol settings of the App Service and set "HTTPS only" to "on".
Related
I am hosting an angular application in azure web app. I want my application should be only accessible on chrome browser. If someone access the site from other browser then user should redirect to browser restriction page. So to achieve this is there any policy available that can be added to web app, instead of writting the code to detect the browser and then redirect?
Rajesh
Azure web app does not have the functionality to restrict access to the browser as you described.
Reason
Azure app service (Windows & Linux) is essentially a webserver running in a sandbox, which is no different from real IIS or Nginx and Apache.
WebServer provides program deployment and access functions, and only receives HttpRequest. As for the information contained in HttpRequest, azure app service does not provide analysis.
For example, adding User-Agent: Chrome is the specific information contained in HttpRequest. This means that we can only determine the source by parsing the HttpRequest through the code.
I have hosted a static website in azure mainly by following the Microsoft tutorials. The process has been to create a storage account, create a CDN endpoint, map my custom domain to the endpoint and then enable HTTPS using an SSL certificate managed by azure.
The custom domain is working but the problem is firstly that although in Azure CDN it says that both HTTP and HTTPS are enabled, I can only access the website via HTTPS and when I try with HTTP the error I get says 'The account being accessed doesn't support HTTP'. The other thing is that in order to navigate to the secure site I have to put the entire URL in the search bar, starting with the https or the website can't be found. I'm not sure if this is normal but if I think of web browsing in general, this isn't usually necessary.
Any ideas on how to fix this would be greatly appreciated.
Default is that Azure only Allows HTTPS.
On App Service go to TLS/SSL settings and switch to HTTPS Only to Off.
On Storage Account go to Configuration and change Secure transfer
required to disabled.
I have a very simple website I'm using for testing purposes that I want to support HTTP. Presently all HTTP requests are being automatically redirected to HTTPS. Here are the steps to reproduce the app:
In Visual Studio 2019 create a new ASP.NET Core Web Application. Choose ASP.NET Core 3.1 and Empty for the project template. Disable "Configure for HTTPS". Right-click the new project and select "Publish...". Publish the app to a new App Service.
After publishing browse to the website. It will redirect you to HTTPS. Here's what I've already tried to remedy this.
In the Azure portal configure the newly created app service. Ensure App service authentication is off. In TLS/SSL settings set "HTTPS Only" to off.
In Program.cs add the UseUrls option.
public static IHostBuilder CreateHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
.ConfigureWebHostDefaults(webBuilder =>
{
webBuilder.UseUrls("http://localhost:8001");
webBuilder.UseStartup<Startup>();
});
In launchSettings.json ensure the application URL uses http.
None of the above solutions have worked for me.
If you're getting a 307 redirect, make sure you aren't calling app.UseHttpsRedirection(); in Startup.cs (thanks https://stackoverflow.com/a/61818466/40783)
Just tried it real quick myself and can kinda reproduce your experience.
I think it is the permanent 301 returned from the azure website when HTTPS only was ON for a while and you tested your site with the setting enabled.
Your browser will cache that response, because its a permanent redirect.
Disabling the cache in Chrome DEV tools and explicitly calling the url with http again then works just fine for me.
Example blank empty ASP.NET Core 3.1 site.
(I didn't change anything in program or startup or settings.)
http://webapplication1020200429115511.azurewebsites.net/
We are not able to force HTTPS to HTTP on Azure. Because when we created the App Services service, we used azurewebsites.net wildcard certificate. We can’t make changes no matter what you do.
For more details, you can refer this post. I also personally tried the code modification and application settings on Portal. After reading this post, I understood the principle. And you can see the certificate information.
As for the debugging program you mentioned, you need to use Wireshark for packet capture analysis. I think it's good to write filtering rules, and it's not too complicated.
I have two web apps setup in Azure, and for simplicity let's call them webapp1 and webapp2. They sit behind an application gateway, which is selecting the correct web app based on the subdirectory in the URL.
Here's a basic example of how I've set it up:
www.mydomain.com -> webapp1 (the default route)
www.mydomain.com/app -> webapp2
This is working fine, except for one problem: if webapp2 redirects to the login page, for example, the domain in the URL changes to the azurewebsites.net domain. Instead of redirecting to www.mydomain.com/login, it's going to webapp2.azurewebsites.net/login.
I'm fairly new to Azure application gateway, but I know it injects the x-forwarded-* and x-original-host headers. I assumed the gateway would either alter the redirected url request to correct the domain or the config on the web app would use the x-original-host instead. Neither of these things are happening.
Is there a way to configure either the web app or the gateway to make sure the host name doesn't change on redirects? Would this scenario work better with a separate web app/VM with a classic IIS reverse proxy setup instead of the application gateway?
Currently Application Gateway would not overwrite the response from the backend. We do inject X-Original-Host and your application should use that to write the redirect URL correctly back to mydomain.
Example to configure URL rewrite on web app can be found here. An example of rewriting default *.azurewebsites.net domain to a custom domain can be found here
Almost have this working. Almost.
My set up is that I have an Azure B2C Tenant set up, and some modified example code that I've changed to reflect the Tenant information. This all works fine locally, with a localhost uri.
My remote set up is a Ubuntu 16.01 server, with a Nginx 1.10.0 webserver acting as a reverse proxy to a .NET Core 1.0.4 and all with a LetsEncrypt SSL cert.
The proxy serves .NET projects fine, however when I hit the sign in it takes me over to the B2C login with an incorrect redirect_url.
I'd expect the value to reflect what is in the settings file, "https.sub.host.suffix/signin-oidc" instead I'm getting "http.sub.host.suffix,sub.host.suffix/signin-oidc"
Any ideas or suggestions appreciated!
If NGINX is offloading SSL/TLS and then calling the .NET Core app, check as most probably is doing it through open HTTP (port 80).
You either need to ensure HTTPS all-the-way, or signal an HTTPS scheme to get triggered if HTTP endpoint was called.
As the .NET Core App gets a request through an HTTP endpoint, every URI created by it will keep that same scheme. So, you'll need to force https:// at link building time.
Hope it helps!