example.com/* (but not example.com/sample/[0-9]*/extraUrl) should hit backend-1
example.com/sample/[0-9]*/extraUrl should hit backend-2
I couldn't find a way to setup this up. Can this be done on GCP load balancer ?
Configure:
host = example.com
path = /sample, /sample/*
Backend = backend-2
Default backend = host=any, path=any, backend=backend1
It should work. Let me know if it's not the case.
EDIT 1
With the edit of your question, I can answer that is impossible. Only prefix path is supported on Load Balancer.
Related
I'm using Cloud Tasks from GAE now.
Also, by setting GAE as the backend of the load balancer, the following processing is tested.
batch-service is a service I created.
Request to /job/test_cron from local machine
go to Load balancer
go to GAE's service（batch-servise） from Load balancer
Create Cloud Task and request /job/test_task from GAE
go to GAE's service（batch-servise）
process and complete
I made each setting assuming the above flow, but the request when creating a task in GAE does not go to batch-servise, but goes to default service.
Therefore, the actual processing is as follows.
Request to /job/test_cron from local machine
go to Load balancer
go to GAE's servise（batch-servise） from Load balancer
Create Cloud Task and request /job/test_task from GAE
go to GAE's servise（default servise）
process and complete
GAE uses dispatch.yaml to direct all requests like /job/~ to batch-servise.
Therefore, Requesting /job/test_cron directly to GAE works as expected.
When using a load balancer, I think that dispatch.yaml cannot be used because the IP of GAE is not used. Is this correct?
Also, if anyone else knows how to configure GAE dispatch, it would be very helpful if you could tell me.
To override default service you can define AppEngineRouting which defines routing characteristics specific to App Engine - service, version, and instance.
You can refer this sample which routes to the default service's /log_payload endpoint. And update to this:
const task = {
appEngineHttpRequest: {
httpMethod: 'POST',
relativeUri: '/log_payload',
appEngineRouting: {
service: 'batch-servise'
}
},
};
When using a load balancer, I think that dispatch.yaml cannot be used because the IP of GAE is not used. Is this correct?
The load balancer does not interfere or interact with routing rules in your dispatch.yaml file. The dispatch.yaml rules are not evaluated until a serverless NEG directs traffic to App Engine.
Configuring dispatch.yaml:
The root element in the dispatch.yaml file is dispatch: and contains a list of routing definitions that are specified by the following subelements.
Dispatch rules are order dependent, and only the first rule that matches a URL will be applied.
You may have a look at these Examples
For more information, see How Requests are Routed.
I've been struggling to find a solution for this issue. Basically I have web application that allows users to sign in with their azure active directory using OpenIdConnect. Everything works perfectly fine on my local. However, when deployed to azure aks, somehow the redirect url changes from https to http when user is authenticated. This causes an exception in azure ad:
AADSTS50011: The redirect URI 'http://example.abc.com/signin-oidc' specified in the request does not match the redirect URIs configured for the application 'c853f6fe-5f4a-436e-b329-ff6da9ab89ab'. Make sure the redirect URI sent in the request matches one added to your application in the Azure portal. Navigate to https://aka.ms/redirectUriMismatchError to learn more about how to fix this.
I defined the redirect URI in the application as https://example.abc.com/signin-oidc and no wonder that it does not match. However, I'm struggling to find out why it's happening and how I can resolve it. I'm using .NET 6 and AKS client version 1.22.
Any help would be greatly appreciated. Thank you
AADSTS50011: The redirect URI 'http://example.abc.com/signin-oidc' specified in the request does not match the redirect URIs configured for the application 'c853f6fe-5f4a-436e-b329-ff6da9ab89ab'. Make sure the redirect URI sent in the request matches one added to your application in the Azure portal. Navigate to https://aka.ms/redirectUriMismatchError to learn more about how to fix this.
The above error occurs usually when redirect Url in the authentication are not configured in Azure AD like.
Accessing Website from a different address than what you have defined for your application causes an error.
please check if you have made a mistake in the configuration itself.
From your case :
Please make sure you set ssl redirects url to True
Note:
By default controller redirects HTTP clients to 443 port -https ,if it has TLS is enabled
In ingress routing yaml file if it is set to false, try to set it or modify it to true
nginx.ingress.kubernetes.io/ssl-redirect: "true"
nginx.ingress.kubernetes.io/use-regex: "true"
Also as you said you are using .net make sure you have set headers to true.
Please check that header size in 32k in annotations.
nginx.ingress.kubernetes.io/proxy-buffer-size: "32k"
Reference:
Error AADSTS50011 - The reply URL specified in the request does not match the reply URLs configured for the application . - Active Directory | Microsoft Docs
I finally figured out the solution for myself. Thanks to the answer in other SOF
Since I'm using .NET 6, all I have to do is
Set the ASPNETCORE_FORWARDEDHEADERS_ENABLED = true AND
Add these two lines suggested from #Venkatesan to my ingress yml
nginx.ingress.kubernetes.io/ssl-redirect: "true"
nginx.ingress.kubernetes.io/use-regex: "true"
Everything works perfectly after that.
Thank you everyone.
My apologies if the information that I have provided is vague as I am not so experience with AWS and React.
I have a React Application being deployed on S3 and CloudFront as per what is suggested in the following link.
Use S3 and CloudFront to host Static Single Page Apps (SPAs) with HTTPs and www-redirects
So most of the things are working fine. I have 403 and 404 errors being redirected to index.html. However the issue comes in where I have query parameters in my url. eg. https://example.com/example?sample=123 when I enter the url in my browser the query string gets removed from the url. The end result I got is https://example.com/example I have read some articles about forwarding query parameters but it's not working for me.
AWS Documentation - Query String Parameters
Hope I will be able to get some advise here. Thanks in advance.
The example?sample=123 is redirected to example because S3 sees example?sample=123 as path (a folder named example?sample=123), it will throw 404 as there is no such folder.
As you have mentioned, you have configured 404 -> index.html, the browser then goes back to example, which is very likely the default page of your react app.
Overall it looks like your query string is being cleared, actually it is lost during the redirection.
The solution includes three parts:
React
You can follow these two great tutorials, one for NextJs and another for RCA.
The way it works is to detect #! in the path, keep and store the query string after redirection.
S3
As included in the two links above, you have to set the redirection rule of the S3 Bucket, to add a #!/ prefix before the path on 403 or 404, it helps React to determine which parts of the url include query string. You can configure it in Properties -> Static website hosting -> Redirection rules – optional. You need to also set index.html as the Index document and enable static web hosting with the correct permission configured.
CloudFront
In General, set Default Root Object to index.html, make sure you don't make it as /index.html.
In Origin, set Origin domain to the S3 Static Web Hosting URL (http://[bucket-name].s3-website.[region].amazonaws.com, do not choose the bucket itself.
In Behavior, change Viewer to Redirect HTTP to HTTPS, set Origin request policy - optional to AllViewer to let all query strings go through.
Hope it helps.
On configured AKS there is docker container with application that is using AAD authentication.
Based on this article there is also configured ingress. API is working well.
When I add to Azure Active Directory application registration reply URL with https prefix I receive error "The reply url specified in the request does not match the reply urls configured for the application". And I see that in browser address line redirect_uri is starting with http.
When I add reply URL that is starting with http, then I receive "Exception: Correlation failed".
What I have tried: Add to ingress.yaml setting ingress.kubernetes.io/force-ssl-redirect: "true"
May be there is some way to force ingress run https instead of http, or there might be some AAD redirect configuration? Any ideas?
UPDATE 2: Probably http redirect is because of ADAL.
PS: Was able to find similar topic without an answer
UPDATE3:
I have decided not to use nginx as ingress. Instead I am using now Load balancer. Soon it would be possible to use Azure Application Gateway Ingress Controller
Have you tried this?
By default the controller redirects HTTP clients to the HTTPS port 443 using a 308 Permanent Redirect response if TLS is enabled for that Ingress.
This can be disabled globally using ssl-redirect: "false" in the NGINX config map, or per-Ingress with the nginx.ingress.kubernetes.io/ssl-redirect: "false" annotation in the particular resource.
More information on this on the Ingress documentation link.
You have to make a decision whether to use HTTPS or not. If this is just the start of a development cycle, start without it and get auth to work - but implement HTTPS as soon as possible.
AAD supports both http and https, but of course, the reply urls must be added to the application registration respectively.
As #mihail-stancescu says, ssl-redirect must be set to false, if you choose not to use HTTPS. In addition to this, you also have to ensure that your app does not make the redirect from HTTP to HTTPS.
Using curl with -L -k and -v options will give you a lot of information on what is actually happening with your requests.
When the http/https thing is solved, you have to remove any rewrite annotations you have in your ingress. (e.g. ingress.kubernetes.io/rewrite-target: / should be removed).
Now, if your ingress path to the service in question is e.g. /myservice, then the reply-url should also have that part of the path added ([host]/myservice/signin-oidc) - both in the AAD application registration and in the configuration of your app. (The path in the config should not contain the host)
If you are using https, then you must also have a proper certificate. You can use the free LetsEncrypt (https://letsencrypt.org/) in conjunction with KubeLego (https://github.com/jetstack/kube-lego), where you can find some nice examples on how to implement it.
I'm using OAuth2WebServerFlow to get the User's Sheets credentials to use with the gdata/spreadsheets API. I'm having a really hard time diagnosing the problem because it works flawlessly when I run the application locally.
This is the snippet I'm using to get the authorization URL:
CLIENT_ID = 'my-id'
CLIENT_SECRET = 'my-secret'
SCOPE = 'https://spreadsheets.google.com/feeds'
flow_object = OAuth2WebServerFlow(CLIENT_ID, CLIENT_SECRET, SCOPE, redirect_uri=self.REDIRECT_URL, access_type='online')
authorize_url = flow_object.step1_get_authorize_url()
Locally (using REDIRECT_URL = 'http://localhost:8080/this-path/')
this produces:
https://accounts.google.com/o/oauth2/auth?redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fthis-path%2F&scope=https%3A%2F%2Fspreadsheets.google.com%2Ffeeds&client_id=my-id&response_type=code&access_type=online
On the live App Engine application (using REDIRECT_URL = 'http://my-app.appspot.com/this-path/')
this produces:
https://accounts.google.com/o/oauth2/auth?scope=https%3A%2F%2Fspreadsheets.google.com%2Ffeeds&redirect_uri=http%3A%2F%2Fmy-app.appspot.com%2Fthis-path%2F&response_type=code&client_id=my-id&access_type=online
The application configuration looks like:
CLIENT ID: my-id
EMAIL ADDRESS: my-id#developer.gserviceaccount.com
CLIENT SECRET: my-secret
REDIRECT URIS:
http://localhost:8080/
http://my-app.appspot.com
https://my-app.appspot.com
http://my-app.appspot.com/this-path
https://my-app.appspot.com/this-path
http://my-app.appspot.com/this-path/
https://my-app.appspot.com/this-path/
JAVASCRIPT ORIGINS
http://localhost:8080
http://my-app.appspot.com
Going to the locally generated version of the url I can successfully grant the application permission. But at the url generated by my live application I get a 401 that says "Error: disabled_client The OAuth client was disabled".
I feel like its probably just a configuration error. Maybe the fact that it works locally is just a red herring? Perhaps I would always be able to grant localhost these permissions? I'm genuinely out of ideas on this and any help would be appreciated.
In the application configuration, redirect URL should be like this http://localhost:8080/oauth2callback, as according to my understanding oauth2callback authorizes the token at the end of the flow. Refer to the document [1].
[1] OAUTH 2.0: https://developers.google.com/api-client-library/python/guide/aaa_oauth#OAuth2WebServerFlow