Path-based routing without ending slash Azure Application Gateway - azure

I'm currently working on Azure Application Gateway to redirect request to 2 WebApi using Path-based rule as below:
"/foo/*" -> FooApi
"/bar/*" -> BarApi
And a default backend api that does nothing for now.
When I request to http://mygateway.azure.com/foo/, it works fine.
But if I missed an ending slash, so with the URL http://mygateway.azure.com/foo, it returns 500 URL Rewrite Module Error.
Current ApplicationGatewayBackendHttpSettings I set -Path to "/".
I tried to add few more routes to the rule liked "/foo", "/foo/", but it doesn't work.
Any advises, please?

Related

I am getting a URI Redirect error for an Azure Application even though the URIs match

I am building my first Azure application and am getting this error when I try to authenticate
AADSTS50011: The redirect URI 'http://127.0.0.1:5000/getAToken' specified in the request does not match the redirect URIs configured for the application
When I go into Azure and look at the redirect URI this is what the value is set to:
http://localhost:5000/getAToken
The app is running locally on http://127.0.0.1:5000
What am I missing here? The URIs match exactly right? So why am I getting this error?
The redirect URI is matched as a string, not as a DNS-resolved URL. That means that localhost does not equal 127.0.0.1 in this case.
As Gaurav said you would have to use the same value in both places — either localhost or 127.0.0.0, but it has to be the same string value.
It doesn't matter how you access your app, you can still access it through localhost or 127.0.0.1. The thing that matters is the value that you send in the redirect_uri parameter. So, if in Azure you have the value http://localhost:5000/getAToken then send http://localhost:5000/getAToken in the redirect_uri parameter.

Azure Application Gateway does not process request but just redirect

My issue
I installed an Azure Application Gateway (AAG) in front of an App Service.
Amethystegw and amethysteweb1 repectively. The AAG is on the VNET1.
amethysteweb1 is a real .NET application, not just the default IIS page.
When browsing from the AAG IP, say 20.223.179.174, it redirect on the app service url:
https://amethysteweb1.azurewebsites.net/
So if I set an access restriction on Amethystegw for VNET1 I get a 403:
NOTE: I also tried to set only my public AAG IP
If I activate WAF rules it does not work because everything seem not to pass through AAG.
What I need
What can I do to have a normal behaviour?
Why Backend Health shows 307 code:
Other infos
Yes I tested the app service that works fine.
Standard V2 Tier
Listener type: Basic
No custom domain
HTTP (80) port
Rules:
Settings:
probe
I successefully tested it.
I read this that is quite similar to my issue:
Azure App Service behind Azure Application Gateway
You need to handle the redirect substitution in the application, at least for .net 5 or 6 we have done it like this in the Startup. That configuration value contains the desired redirect, something like "https://{your url from app gateway}/signin-oidc"
services.Configure<OpenIdConnectOptions>(OpenIdConnectDefaults.AuthenticationScheme,
options => {
Task RedirectToIdentityProvider(RedirectContext ctx) {
var redirectUri = Configuration.GetValue<string>("AzureAdB2C:RedirectUri");
if (!string.IsNullOrWhiteSpace(redirectUri)) {
ctx.ProtocolMessage.RedirectUri = redirectUri;
}
return Task.FromResult(0);
}
var previousEvent = options.Events.OnRedirectToIdentityProvider;
options.Events.OnRedirectToIdentityProvider = (context) => { previousEvent(context); return RedirectToIdentityProvider(context); };
});
I found the solutions.
The web apps was a .NET application that forced an HTTP to HTTPS redirection.
I just removed:
app.UseHttpsRedirection();
And it is working now.
Thank you for all those helped me here.

Azure API Management - dynamic urls issue

I have a frontend url say - 'https:\test.helloweb.com\account' which is defined a post request /person and I want to direct any request that comes on that url to a backend url like so
'https:\secure.hiddenapi\vi\api\person'.
The above scenario is easy and works now the place where I'm stuck is if there is a request for
Say -
/person/<id>/membership
/person/<id>/membership/<memid>
/person/<id>/accountdetails/
these requests needs to be directed to
https:\\secure.hiddenapi\vi\api\person\<id>\membership
https:\\secure.hiddenapi\vi\api\person\<id>\membership\<memid>
https:\\secure.hiddenapi\vi\api\person\<id>\accountdetails.
I tried defining the operation as /person/* then if i make a request to /person/<id>/membership then the backend url called is https:\\secure.hiddenapi\vi\api\person\membership without the id.
Seems like a simple issue but cannot make any progress!
Here is how APIM maps URLs. Consider:
An API with:
API URL suffix set to "myapi"
Web service URL set to "https://contoso.com/api"
An operation with:
URL template: "/myoperation"
When APIM receives a request it will split it into two parts:
https://service.azure-api.net/myapi/myoperation
^ ^
API base URL operation path
It will then replace API base URL with "Web service URL" specified for matched API and this will become request to backend:
https://contoso.com/api/myoperation
In your case, given that you end up with "person/person" it is likely you have "person" in both Web service URL and operation URL template. So you have two options.
First option is to configure Web service URL as "https://secure.hiddenapi/vi/api" and let all your operation templates start with "/person".
Another way is to set service URL as "https://secure.hiddenapi/vi/api/person" and do not include "/person" into your operation URL templates. It's perfectly fine if operation URL template starts with a variable like "{id}/membership/{memid}".
It's a good practice to split your whole backend API into different APIs in APIM for control and management. So personally I'd prefer first option, and if later there would be a need to make request to backend with prefix different than "/person" I'd create another API.
Try using rewrite URL policy to route to different backend URL for specific operation as follows:
<inbound>
<base />
<rewrite-uri template="/accountdetails/" />
</inbound>

AAD app registration not accepting the query string parameter

I have registered the app in Azure AAD with reply urls. Enable id_token and auth token. If i give the exact url as the parameter it works fine. but if I add the query string as a parameter in reply url it is not working and throws error
AADSTS50011: The reply url specified in the request does not match the
reply urls configured for the application: ''.
Below is my sample URL format generated by ADAL.js file.
https://login.microsoftonline.com/.onmicrosoft.com/oauth2/authorize
?response_type=id_token &client_id=
&redirect_uri=?p1=123&p2=456
&state=62439108-d296-4a0d-91cc-4f6580656e83
&client-request-id=1a5ad90a-26fc-4e60-bbcc-8d58bbbcc1f7
&x-client-SKU=Js &x-client-Ver=1.0.13
&nonce=a4a6215c-0706-4fbc-91a9-36e4cd3a262e
If i remove this ?p1=123&p2=456 query string from the redirect_url, it works fine. The other workaround i see is if i go to legacy app registration and add "" at the end of the url it is working. But the new app registration does not allow "" in the reply_url while registration.
Anyone else also faced the same issue and fixed without adding "*" in the reply_url registration? please let me know.
This is an issue with ADAL.js (and MSAL.js) setting the redirect URI to the current URL by default.
You can get around it with an approach like this:
Set redirect URI as window.location.origin + "/aad-callback" (or anything else)
When requiring login, store current URL in sessionStorage (or local storage or a cookie)
Trigger login redirect
When your app gets a callback to /aad-callback, handle the tokens from the URL fragment
Load the local redirect URL from sessionStorage
Redirect user there
I wrote an article related to this but for MSAL.js: https://joonasw.net/view/avoiding-wildcard-reply-urls-with-msal-js.
The concepts are the same for ADAL.js.

ServiceStack Metadata Redirect behind a Azure App Gateway not working

My api is hosted on Azure as an App Service with an Azure App Gateway in front of that.
I have set the webhosturl in my startup and that is working as when I view the metadata page, i see the links pointing to the correct location. And those links work. However when I navigate to the base url for my api, it redirects me to the app service url.
Here is a snippet of my startup...
SetConfig(new HostConfig
{
WebHostUrl = "https://api-dev.hsawaknow.net/link/",
DefaultRedirectPath = "/metadata",
DebugMode = AppSettings.Get(nameof(HostConfig.DebugMode), false)
});
Please see the links below and see the differences.
https://api-dev.hsawaknow.net/link/metadata
vs
https://api-dev.hsawaknow.net/link/
You will get an https error as I am using a self signed cert, until I get this figured out. I have seen other posts that say to make this change and that it works, but not for me.
Please help!
I have this figured out. There were a couple things that I had to do.
First thing I had to do was setup the forwarded headers middleware to recognize and process the correct headers coming from the Azure Application Gateway.
services.Configure<ForwardedHeadersOptions>(options =>
{
options.ForwardedHostHeaderName = "X-ORIGINAL-HOST";
options.ForwardedHeaders = ForwardedHeaders.XForwardedHost | ForwardedHeaders.XForwardedProto | ForwardedHeaders.XForwardedFor;
});
This allowed my site to work with links to the correct pages without setting the WebHostUrl. The only caveat about using the Azure App Gateway is that it uses X-ORIGINAL-HOST instead of the standard X-FORWARDED-HOST.
Next, I had to set the DefaultRedirectPath on the HostConfig dynamically based on settings in appsettings.json. In the case of the Azure App Gateway, my public url was https://api-dev.hsawaknow.net/link/, I had to set the redirect to /link/metadata, instead of just metadata, because of how the host header was getting set in the previous step.
It took a few tries, but this configuration works well, when hosting on Azure App Services fronted with an Azure Application Gateway.
Kudos to the mythz for the quick response, which pointed me in the right direction.
Enable the Request Logger so you can see what requests ServiceStack receives.
Does it work when not specifying a WebHostUrl?

Resources