Is it possible to set X-Forwarded-Proto header to https (I belive by default it's http). I have an application behind AFD that is configured with SAML that requires such header in order to properly direct call back.
I was going to use rules engine configuration to configure response header, but it's not allowed (see the picture).
Any suggestions? Much appreciated.
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'm currently running a windows azure web app behind an application gateway v2.
I would like to use header information for x-forwarded-host or x-original-host - but it does not work.
Now I'd like to trace what request headers are actually received by the web app. I'm trying network-capturing. But as the whole traffic is HTTPs - I guess I'm not seeing all the fields.
Any Idea?
You can configure application gateway to modify request and response headers and URL by using Rewrite HTTP headers and URL or to modify the URI path by using a path-override setting. However, unless configured to do so, all incoming requests are proxied to the backend.
For more details, you can read the offical document.
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.
I have a Wordpress server running on EC2 and currently it's only running HTTP and I'd rather avoid the hassle of setting up SSL on it. What I'm hoping is that I can co-opt Cloudfront to serve all requests to clients using HTTPS (using an AWS Certificate Managed SSL cert) and then refresh it's cache with HTTP calls to the origin server. This type of configuration is quite straight forward with Cloudflare but it's more of a reverse-proxy than a traditional CDN. Is this a reasonable architecture for Cloudfront?
I had originally thought that the "Behavior" for Viewer Protocol Policy could be set to "Redirect HTTP to HTTPS" but at least initially I appear to be getting the page to load over HTTPS but all assets on the page fail to load because they're still pointed to HTTP. Possibly this a different issue but I'm having an issue grokking it all.
Just for reference, here's my Behaviors dashboard:
And my origin:
You can do it via Origin Protocol Policy option in AWS Console. Select HTTP Only.
To do this select your Cloudfront configuration > choose Origins and Origin Groups tab > Choose your origin > Click Edit button
Remember that you are doing changes for Origin. You have to keep Viewer Protocol Policy to Redirect HTTP to HTTPS as indicated in the question so that traffic between browser and Cloudfront remains HTTPS whereas Cloudfront connects to your Origin via HTTP
Edit: Question description does show that origin is set to HTTP Only which should be enough to do it. Double check if your distribution is in Deployed state.
After setting up CloudFront to deal with HTTPS, you also need to configure WordPress so it generates all the links and asset sources with HTTPS. You can follow the documentation for that.
In short:
Go to Settings -> General
Change http:// to https:// in WordPress Address (URL) and Site Address (URL).
I'm working with Authentication in Azure App Service, AKA "Easy Authentication"
https://learn.microsoft.com/en-us/azure/app-service/app-service-authentication-overview
It works fine if I browse my azure web-site using it's Azure name: [myid].azurewebsites.net
But if place my web-site behind a reverse proxy, after authentication, I'm always redirected to [myid].azurewebsites.net instead of www.[mydomain].com. The reverse proxy is correctly configured to serve my pages and all work fine without authentication.
I think that the root cause is how the redirect_uri parameter is built by "Easy Authentication". Using Chrome F12 I noticed that during the initial redirect to authentication service, the browser url is built using [myid].azurewebsites.net instead of www.[mydomain].com.
https://login.windows.net/034...51/oauth2/authorize?response_type=id_token&redirect_uri=https%3A%2F%2Fmyid.azurewebsites.net%2F.auth%2Flogin%2Faad%2Fcallback&......
I can't find a way to instruct/force "Easy Authentication" to use www.[mydomain].com
Any suggestions or idea?
--- update ---
I use Nginx as reverse-proxy. The relevant fragment of the configuration file (redacted):
server {
server_name www.mydomain.com;
listen 80;
listen 443 ssl;
...
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-Host $host;
proxy_pass https://myid.azurewebsites.net/;
}
}
We need to include an extra parameter to instruct where the process should redirect to after successful authentication. We can do this with the 'post_login_redirect_uri' parameter. Without this, the process will redirect to a default 'Authentication Successful' page with a link to go back to the site.
For more details, refer to this document: https://weblogs.asp.net/pglavich/easy-auth-app-service-authentication-using-multiple-providers.
According to your description, I used URL Rewrite and Azure Functions Proxies as my reverse-proxy to test this issue, I found that I could encounter the same issue as you mentioned. I also tried to compare Headers、ServerVariables between accessing via reverse-proxy and directly accessing, and tried to override the related headers to narrow this issue, but failed in the end. I assumed that since we are using the build-in App Service Authentication / Authorization, we could not override the generating for the redirect_uri parameter.
Per my understanding, you could set the additional header(s) under your reverse-proxy, then build the authentication / Authorization in your application to pick up the additional header for generating the redirect_uri and redirect user to the related authorize endpoint. Or you could use Traffic Manager for Load Balancer, and you could follow this issue. Additionally, if you just want to customize your azure web app domain, you could follow here.