Azure Application Gateway rule for url not found - azure

We are migrating our old site on prem to a new one hosted on Azure but we need to maintain the old site online.
So imagine the following scenario:
new site: www.site.com
old site: www.oldsite.com
This is what we need:
if a user enter www.site.com/somepath and "/somepath" doesn't exist (url not found), it must be redirected to the onprem www.oldsite.com/somepath
Is it possible? How to write the Azure application gateway rule for url not found?
Thank you in advance, Marco

URL path based rules support notion of default path which is used when none of the path rules match. In your scenario you could set a default backend pool which redirects user to oldsite.com/somepath for any request received. You can then configure path based routing so that site/somepath goes to new pool, site.com/somepath2 goes to another pool.. if none of the url paths match the request would be sent to default pool from where it could be redirected to oldsite.

I believe you are use a URL Redirect to achieve this.
Create an application gateway with URL path-based redirection using Azure PowerShell
https://learn.microsoft.com/en-us/azure/application-gateway/tutorial-external-site-redirect-powershell
In addition, if you open the links provided and look to the left you will see even more options. Some of which you might find useful.

Related

DocuSign error "The redirect URI is not registered properly with DocuSign" with proper & valid redirect uri registered in application

We have docusign integrated in our platform & all of a sudden we are getting error from DocuSign
"The redirect URI is not registered properly with DocuSign".
We have proper & valid redirect uri configured in the application.
Please Note that exsisting setup is working fine, for newer apps or newer accounts, it is throwing the above-mentioned error Here is the screenshot of the same .
The redirect uri is valid as it's working for other app.
Has something changed at DocuSign end recently?
Update:
As asked, Please find the redirect uri screenshots below (I've masked the host url),
DocuSign Redirect URI configuration - Please note that both URI are same with difference in host url.
Complete Oauth request url
Redirect window
Make sure to compare the URL you see in the browser to the one in the IK. Make sure it's the same IK, in the same env (production vs. developer env is different!). Even a tiny difference between the two URLs will fail this. You need to URL decode the redirecUri from the main URL and then use that by copy/pasting it into the apps and keys page.
Then wait about 1-2 minutes before trying again.
Edit: confirmed that the URLs DO NOT MATCH, and that is the issue. The URLs must match 100% for this to work
Redirect URIs are specific to each integration key (application) and do not get copied over if you make a new integration key. Based on your description it sounds like you have created a new integration key. I would recommend visiting the Apps and Keys page on your DocuSign Admin settings and adding the redirect URI to the new integration key. Here is a support centre article which outlines this including the steps for how to add a new redirect URI
Nothing in this area has changed on DocuSign AFAIK.
Check that the redirect URI specified in your initial OAuth redirect is the exact same as the URI you set in the Integration Key's settings page.
The redirectURI cannot include any dynamic data including query parameters, etc.
You can use the settings tool's Apps and Keys page to delete and then re-add the RedirectURI. Check carefully that it doesn't include any trailing spaces, etc.
After you've made a change via the Apps and Keys pages, wait 5 minutes before attempting to use the Integration Key.
Ensure that you're using the right Apps and Keys page. If your app has passed go-live then:
For the production systems, use the apps and keys page from docusign.net
For the developer (demo) system, use the apps and keys page from demo.docusign.net

Restrict access for website to Front Door only without custom domain - is it possible?

I would like your feedback and opinion about using { FrontDoor + Appservices + Authentication + restrict access to FD only }
I do confirm I can set up all of this thanks to all contribution/ forums / blog found on the net. I can use my custom domain which request AD authentication and I am correctly redirect to my appservices (in browser: I see my custom domain name and never see any *.azurefdnet or *azurewebsites.net as expected).
The only problem is that I needed to use a custom domain to make it works. For production purpose it is acceptable to have a custom domain but for dev or test I wonder if we can do it without custom domain by simply keeping original address like *.azurefd.net and *.azurewebsites.net
I struggle to make it works without custom domain. I keep getting “too many redirection” message or ‘403 sites blocked’.
Does anyone success to do it ? My general configuration looks like
My backend is linked with my appservices
Details of my backend is:
I think my problem is with BackendHostHeader but not sure. When i used custom domain for my production it works. But remind i do not want to use custom domain for dev and test.
My route looks like
And finally my appservices is secure to allow frontdoor only
When my user goes to stackoverflo.azurefd.net they get AD authentication which is good but just after i get redirection to xxx.azurewebsites.net with 403 forbidden (which looks normal because of restriction to FD only).
I tried to change the backend host header by replacing by FD value but in this case i get a error with loop redirection.
Is it a feasible scenario without custom domain ?
Regards
PS: i configured Azure ADApp to allow reply url to my FD like stackoverflo.azurefd.net/.auth/login/aad/callback
Yes, you can Restrict the access to website without using Custom Domain.
Goto the Application you want to restrict the access in Azure Portal and select the Networking from left Pane, now click on Access Restrictions.
For complete information you can go through this Microsoft Documentation.

Azure applicationgateway: How can I rewrite the url so the user still sees user.mysite.net, but application gateway redirects to test.mysite.com/user1

Can't seem to pin down the correct order of operations here if it exists...
Current setup:
I have user.mysite.net pointing at application gateway public ip. test.mysite.com/user1 is pointing at a VM hosting a hello world application. This VM exists in the same tenant but different subscription. The app is just a simple hello world app.
Target state:
I want to configure the rewrite or redirection, so that when I hit user.mysite.net in my browser it should send me to test.mysite.com/user1, but at the same time, within the browser I don't want to change the url, I want to preserve the original url: user.mysite.net
Is this possible? If so, how would I even go about configuring it or order operations? i.e what would the rewrite rules look like and then do I attach it to a routing rule with redirection or backend?
In the case of a URL rewrite, Application Gateway rewrites the URL before the request is sent to the backend. This will not change what users see in the browser because the changes are hidden from the user.
Please check if you can do pattern matching with the location header matching eg. IF contains mysite.net and Perform an action to rewrite the location header appGW -rewrite-http-headers-url.
Other wise it may not be possible with rewrite,if it is external site url and the original site has to appear in address bar .See Reference -Stack Overflow
NOTE: URL rewrite feature is only available on Application Gateway v2
SKU. You can follow the documentation here to implement rewrite
URL path.
Reference:
Rewrite URL and query string with Azure Application Gateway - Azure portal | Microsoft Docs

How to block crawling of the origin when Azure CDN is configured

something is not clear using Azure CDN.
I explain step by step what I have done since my website has been created. Call my website www.mypublicwebsite.com. So:
I created a web app on Azure. The website has the following url: https://mypublicwebsite.azurewebsites.net;
I created a custom domain www.mypublicwebsite.com
I redirected all the request from https://mypublicwebsite.azurewebsites.net to www.mypublicwebsite.com. So I solved the problem of duplicated contents for crawlers.
Everything is fine. Then, I decided to create CDN, according the documentation. Here the confusion starts.
I created the CDN profile
I created the endpoint. The endpoint has a new url https://mypublicwebsite.azureedge.net
I deleted the custom domain from web app;
I created the custom domain in cdn profile.
So the current state is this:
This situation is really problematic for SEO!! It cannot be the correct configuration. My contents are triplicated.
I partially solved the situation:
I redirected all the request from https://mypublicwebsite.azureedge.net to www.mypublicwebsite.com. So I solved the problem of duplicated content for crawlers.
But crawler (and perhaps users?) can still navigate the origin web site. I have been looking for different solutions:
Make a redirect from https://mypublicwebsite.azurewebsites.net to www.mypublicwebsite.com. But this create a infinite redirects loop between the CDN and the origin.
Try to hide the origin, but how?
I am honestly starting thinking this is not the correct way to manage cdn.
Can anyone help me please?
Thank you

Azure B2C accepting different domains in Redirect URIs: Bug or Feature

When adding Reply URLs in an Azure B2C Application, the UI shows the following information:
Redirect URIs must all belong to the same domain
And until recently this was enforced by the UI: no way to save a list with multiple different URLs with the exception of localhost.
But just today I found out that right now it's possible to add any domain as Reply URL, which is pretty awesome for my use case. Is this going to stay and the info is outdated or is this a bug (which would be a shame, because this makes multi-domain apps a lot easier)?
BTW, it's not just that the list can be saved, the redirects work as one would expect.
Yes, the restriction has been removed. But the tip on Azure portal hasn't been updated.

Resources