CORS says that:
A web application executes a cross-origin HTTP request when it requests a resource that has a different origin (domain, protocol, and port) than its own origin.
That been said, look at this scenario. I have two apps deployed on the azure.
https://myApp.azurewebsites.net .NET FW app that has a Angular client.
https://myMicroservice.azurewebsites.net .NET CORE API.
Since both apps are in the same site (origin) azurewebsites does that mean that I don't need to configure CORS?
Note: I already have configured CORS on the .NET CORE app to allow the https://myApp.azurewebsites.net origin.
Here, the same origin means that xxx.azurewebsites.net should be the same one(as well as xxx).
So in your case, you need to enable CORS. Otherwise, the access is not allowed.
Related
We are trying to get Azure app proxy to work and are running into CORS issues. We are using custom domains with split brain deployment.
I have read through: Azure Application Proxy CORs
and am currently on step 4 to just rewrite cors to work with out the wildcard below
var cors = new EnableCorsAttribute("*", "*", "*");
config.EnableCors(cors);
Our web application has a frontend server hosted on IIS: https://frontend.company.com with the internal and external urls mapped to be the same urls as behind our company firewall.
We also have a backend server located on premises hosted on IIS and located at https://backend.company.com
We have set up two applications in app proxy to point to the respective servers where the internal and external match the urls we are using internally to the company.
I have tried var cors = new EnableCorsAttribute("https://backend.company.com", "*", "*")
and still get the cors issue. One thing I noticed is We are not getting the Response headers when going through Azure Proxy. Here is a picture of what it looks like internally and you can see access-control-allow-origin is set to *
The end goal is to be able to access this application externally. I can get the frontend to pull up html fine, and I can go directly to the swagger pages on the backend side just fine, but the two cannot communicate cross origin.
Below is what we see when accessing externally through app proxy:
We have tried to set web.config values, and remove values with pretty much every stack overflow article we can find.
Question is Does Azure or Azure App Proxy have any settings around allowing Access-Control-Allow-Origin settings to flow through? I dont have access to App Proxy, and am having to work with our cloud team to try different things. We have tried every combination of the Translate URLS mentioned here https://stackoverflow.com/a/60560675/1879992
Below is what we see externally and has the request headers missing
We have also read the official document and whitelisted our urls with the same response.
If I disable the chrome setting related to CORs the app comes up fine.
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".
We are using Service Fabric for hosting our messaging service ASP.NET Core web API (leveraging signalr) and React web application as a client. Everything works exactly as expected on local machines but not on Azure. We have configured CORS policies for cross-origin handling since the service and the web app are hosted on different servers. Configured sticky sessions in load balancer. This CORS Policy works in local machine with the service and client hosted on different ports.
Post hosting the application on Azure, I get an Error in the browser console as
Error during WebSocket handshake: Unexpected response code: 500
The issue is very likely to be happening because of CORS.
Looking the screenshot you provided, it is possible to see the CORS exception and, as you are aware, the front-end application calling the SignalR service are hosted on different locations(The domain is the same but different ports).
The CORS settings you applied probably didn't work.
You have two solutions:
Configure CORS in the ASP.NET CORE, so SignalR can accept the call from other domains.
Host both on same domain + port to avoid CORS
Having an issue with Azure storage CDN. We have it configured for CORS, basically we allow all headers and origins (*), and GET|HEAD|
OPTIONS. Everything works fine when we are using the storage direct host. When we switch it over to use the CDN host,the OPTIONS request stops returning any of the allow headers and causes cross origin failures. On other gets I do get the allow origin header but nothing else. Anyone seen this or am I overlooking a config option somewhere? Happens locally talking to Azure and on our Azure hosted site.
Azure CDN profiles from Akamai currently do not tunnel OPTIONS requests. There is a patch currently underway to enable OPTIONS requests for cors pre-flight.
If you don't use pre-flight requests, does CORS work?
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!