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.
Related
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".
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.
Is there a way with Azure Functions to force connections to be over HTTPS?
I'm not seeing it in the App Settings, and I don't see any reference to web.config for Azure Functions.
Update November 2017
In the Azure portal, go to your function app.
Platform features > Custom Domains > toggle HTTPS Only to 'On'.
Anyone using HTTP will receive a 301 Moved Permanently and be redirected to the HTTPS endpoint. You do not need to actually add a new hostname/domain to toggle this feature. This appears to work with both consumption and app service plans.
I don't think there is a way today, but I could see making a case for enforcing this globally (or at least as an option).
Please open an issue https://github.com/Azure/azure-webjobs-sdk-script/ so it can get properly tracked.
You can do it by going to your function app in azure portal.
Under the settings section you will see the "custom domains" as a selection option.
Now on the new page you will see the toggle called HTTPS Only, On it and you will be able to access you api endpoint with "https". Like this as below.
I have been struggling to configure an SSL Certificate based environment for hight trust apps in SharePoint 2013. I have on-premises installation of SharePoint 2013 (Enterprise). Following google and msdn articles, I figured out that high trust apps require Client SSL authentication. My app is a provider hosted app and requires an "https" url to be hit when triggered (there is no option for setting "http" url). Any help would be appreciated.
I highly recommend Kirk Evans' blog post on the subject to get you started:
http://blogs.msdn.com/b/kaevans/archive/2012/11/27/creating-high-trust-sharepoint-apps-with-microsoft-office-developer-tools-for-visual-studio-2012-preview-2.aspx
I was able to walk through this to get 90% to where I needed to be, including creation of a self-signed certificate for the PHA server.
What Kirk's blog didn't cover for me:
Setting up a dedicated PHA server. Kirk's post finishes with running the app
from IIS Express inside Visual Studio. I wound up needing a modified
web.config for non-dev builds, i.e. for code deployed to a dedicated
IIS instance.
Setting up for App lifecycle event receivers. If you want to handle
App lifecycle events from your PHA, then you may have even more
tweaking to do in the web.config file. To this point I've had to
enable Anonymous authentication in my service bindings in web.config
in order for SharePoint to call those handlers.
YMMV
Please visit this for bindings :
http://www.sslshopper.com/article-how-to-create-a-self-signed-certificate-in-iis-7.html
and In the publishing profile, modify the "SiteUrlToLaunchAfterPublish" and the "publishUrl"
SiteUrlToLaunchAfterPublish --> https://YourServerName:PortNumber/VistualDirectoryFolderName
& publishUrl --> Path where you publish your web
before this uncheck the "Use IIS Express" from your provider hosted web properties and select "Use local IIS web server". Pass the address of your simple http://YourServerName:PortNumber/.. url and create virtual directory.
In my MVC web app, one controller function (Validate) calls a service. See below code and note that MessageHandlerClient is a service proxy generated in Visual Studio. The service proxy call client.ValidateMessage(formdataasbson["HLmessage"].ToString()) works fine in my local dev environment. When I publish the project to Azure, calls to Validate controller function no longer work. Suspecting a problem with the proxy, I changed Validate() to give back hard-coded results, re-publish to Azure, and all works fine - confirming a problem with the web service proxy behavior in Azure.
[HttpPost]
public ActionResult Validate(String serializedformdata)
{
try
{
BsonDocument formdataasbson = this.serializer.JSONFormtoBSON(serializedformdata);
MessageHandlerClient client = new MessageHandlerClient();
this.jsonresponse.ReturnValue = "true";
StandaloneValidator.My_ServiceReference.Error[] results = client.ValidateMessage(formdataasbson["HLmessage"].ToString());
this.jsonresponse.ReturnMessage = results.ToJson();
return Json(this.jsonresponse);
}
catch (Exception ex)
{
this.jsonresponse.ReturnValue = "false";
this.jsonresponse.ReturnMessage = ex.Message;
return Json(this.jsonresponse);
}
}
What's more, I see details of the web service proxy in my local web.config file as below (IP intentionally obscured):
I have read various posts about web.config in Azure and the fact that it is not writable, so I'm suspecting my local ..... proxy info is never published in Azure. If indeed web.config does not publish from local to Azure, then I understand why my proxy doesn't work. The question is.....what should I do to fix??!
EDIT: I see various posts discussing migration of some settings from web.config to csfg files for Azure - perhaps a viable solution? Given that I am not coding manual read of these settings (I simply created service proxy from URL to service) I worry about auto-generated code or any "under-the-hood" behavior of the service not knowing how to read migrated settings from csfg.
Based on what you have written above, it seems you are confused with Web Role and Web Sites. First you would need to understand the difference between these two so you can make better decision on what to choose for your application. Here are some useful links:
SO discussion on difference between Azure Web Sites and Web Role
MSDN Article on when and why to choose Azure Web Sites and Web Role and Azure VM
Windows Azure Web site, you do not have full control over IIS web server and because of that some of the settings web site specific settings are configurable and others are not. In Windows Azure websites, most of machine and system specific settings added into web.config are overwritten so these settings does not work. Also you can not RDP to your Azure Websites instance as well.
If you have to use ASP.NET MVC application which MUST need proxy configuration, you must deploy it to Windows Azure Cloud Service.