Is CORS supported in Standard edition of Azure CDN or is it only available in premium tier. I am looking for "wildcard or single origin scenario"
This is what they mention in the below link
CORS on Azure CDN will work automatically with no additional
configuration when the Access-Control-Allow-Origin header is set to
wildcard (*) or a single origin.
https://learn.microsoft.com/en-us/azure/cdn/cdn-cors#wildcard-or-single-origin-scenarios
#juunas, As the comment, the document states that, standard Azure CDN allows for multiple origins is to use query string caching.
Enable the query string setting for the CDN endpoint and then use a
unique query string for requests from each allowed domain. Doing so
will result in the CDN caching a separate object for each unique query
string. This approach is not ideal, however, as it will result in
multiple copies of the same file cached on the CDN.
So, the best way is to use Azure CDN Premium from Verizon, which exposes some advanced functionality. If so, you will need to create a rule to check the Origin header on the request. If it's a valid origin, the Access-Control-Allow-Origin header with the origin provided will be set in the request. If it's not, this header will be omitted by the rule and the browser also will reject the request.
Just set the Access-Control-Allow-Origin on your origin server. Standard Azure CDN will respect your CORS header. Its working just fine for me. I am glad I tried setting the header on the origin server instead of upgrading to the Premium CDN.
Related
I want to add caching to the application we have exposed over APIM. My preferable way would be to add cache-control headers to the responses from the client. Can I configure Azure APIM to respect Cache-Control headers that are part of the response from the underlying service? All the documentaition I can find is how to configure all caching policies and rules in APIM, where I just want a simple rule that says "respect the headers from the underlying service".
There is no built-in policy just for that, but you can craft such mechanism yourself using the policies you have available. Here is the example how to control API Management response cache duration with Cache-Control headers sent by the backend service.
By looking at the example above you can try to handle other directives.
I have a problem configuring my Open Auth ID .net Core 2 application as an App Service behind a Web Application Firewall using a Path based routing.
My application is myapp.azurewebsites.net with a network restriction making it inaccessible from the public internet. I have deployed a WAF in the same VNET and allowed traffic between the WAF and App Service using a Path based route "/Admin*".
The effect is that https://myapp.azurewebsites.net is not internet accessible but https://myWAF/Admin is accessible and maps to the app service.
This setup works fine, but when I introduce Open ID auth to my .net core application the outgoing Location header includes its myapp.azurewebsites.net/signin-oidc as the reply URI.
This doesn't work because the host is not accessible from the internet. I have attempted several approaches;
I have added the WAF URL (https://myWAF/Admin/signin-oidc) in the application registration URL in Azure App Registrations to allow AAD to accept the modified URL (as legitimate
I have coded app.UseForwardedHeaders (forcing reuse of all X-Forwarded headers) in my startup.cs. This doesn't seem to have any affect on the Location header being sent by my App Service.I presume the WAF is sending X-Forwarded headers, but if it is, the Open Auth ID stack isn't using them.
I have coded a header rewrite in the WAF to replace the myapp.azurewebsites.net with the WAF URL. This does replace the URL correctly and allows the callback, but then fails with a Correllation Error (which seems to be a generic Open ID stack error meaning "the nonce does not match". Its possible that the nonce is predicated on the URL being called back to - which in my case changes due to the WAF redirection, but that's a guess).
It seems to me like I should be able to use the X-Forwarded headers in my app to get around the need to code up header re-writes in the WAF, but I can't find an example where this is used successfully to alter the Reply URI being sent out by Open ID.
My question it; is using the X-Forwarded header the correct approach to handling proxies in an OAuth context, or is header-rewriting in the WAF the correct approach ?
I have set
After much investigation I found the following;
WAF does not send the standard X-Forwarded-Host to App Services but sends X-Original-Host instead. Documented here https://feedback.azure.com/forums/217313-networking/suggestions/33657763-add-the-x-forwarded-host-header-to-application-gat
The ForwardedHeaderOptions that ASP.net Core 2 uses in its ForwardedHeaders middleware have an option to replace the expected and supported "X-Forwarded-Host" with an arbitrary other host header name. This behaviour can be triggered as follows to replace the use of the x-Forwarded-Host with the WAF specific X-Original-Host.
options.ForwardedHostHeaderName = "X-ORIGINAL-HOST";
WAF does not pass the Path of the Path Based Route down the Http Header stack as expected in the PathBase header. This must be added to the Request Headers either in the WAF via a Header Rewrite, or inside the app as follows (in this case the apps Path Route is /Admin);
app.Use((context, next) =>
{
context.Request.PathBase = new PathString("/Admin");
return next();
});
I have created an API using AWS Lambda functions. I need to give access for the API only to a particular domain.
I have tried out replacing my own domain in the formats like example.com, www.example.com, https://www.example.com in the access control allow origin box. But when I hit the API from outside it is accessible.
Does anyone have some solution for the problem mentioned above?
Only my domain name for eg...www.example.com should have access to the api and other domain names like www.exampl-one.com should not have access
you can set access-control-allow-origin to the required domain. When webpage hosted under the domain call the API the preflight call will be performed. if referring domain and access-control-allow-origin cors documentation
I am working on web application that has angular 4 on frontend and WEB API on backend. This application is hosted on MS Azure and until now we didn't have any issues.
Currently we need to integrate with one payment provider. During payment user is redirected to his payment page, and if everything goes well user is redirected back to our web site. Beside the browser redirect (which may fail) payment provider supports server to server call (HTTP GET). In this way they make sure we get information about the transaction. The problem here is that instead of one call to our Web API backend we get always two calls. After checking the request origin IP addresses I concluded that there is two origins (one is payment provider address and another is IP located in USA, which I assume belongs to MS). This looks to me like a routing problem, but I am not very experienced at this.
Did anybody have similar problem on Azure while hosting web application ?
According to your decription, it seems that fails for cross domain request. Azure website is supposed to manage CORS for you.
I think you missed a handy Azure website blade: Specify the origins that should be allowed to make cross-origin calls (for example: http://example.com:12345). To allow all, use "*" and remove all other origins from the list. Slashes are not allowed as part of domain or after TLD.
Cross-Origin Resource Sharing (CORS) allows JavaScript code running in a browser on an external host to interact with your backend. Specify the origins that should be allowed to make cross-origin calls (for example: http://example.com:12345). To allow all, use "*" and remove all other origins from the list. Slashes are not allowed as part of domain or after TLD.
ETags are required to be quoted but Azure CDN generates ETags that are not quoted. Has anyone seen or do you expect problems with intermediate caches because of this?
How do you distribute your CDN content? Are you using a Windows Azure Web Role or just CDN configuration? It would be interesting to see how do you verify the ETAG does not have quote.
I just check with both the sources and in the HTTP header they both shows within the quote so would u please check the HTTP Headers and verify how it is listed.