We currently use Traefik IPWhiteList middleware to restrict the access to our application. If the Ip address is not on the whitelist, Traefik sends back a 403 forbidden. The user should now be redirected to another page. unfortunately I can't find a way to set this up. is there a possibility that I have missed or is this really not possible with Traefik?
First you have to create both Middlewares errors and ipwhitelist, as you can see in the image down below from line 62:
After, you have to link the Middlewares to your service, as you can see on line 108:
You must link the error Middlewares first
Then, create the endpoint which will return the response, for instance:
And you will receive the following response
Related
I deployed an Odoo instance on ECS + FARGATE as a service, which is assigned to a target group.
On ALB I have a listener on port 443 with ACM that redirects the traffic on that target group.
The connection is working, I can reach the Odoo service from the ALB.
The problem is, Odoo can respond with 3xx codes, and I can see the url changing on the browser address bar. But instead of loading the new page, I get an error.
If resend the request directly with this same url, the one resulting from the redirect, the page loads as expected.
If I connect to the service directly, without ALB, it works fine.
From what I could understand, the ALB doesn't manage the 3xx response codes from the target group, so it gives an error.
What can i do to resolve this redirect problem?
EDIT:
Problem solved, here is what i tried:
I tried setting the listener on HTTP instead of HTTPS, and it worked fine.
After that, i reconfigured the listener on HTTPS, and added an HTTP listener which returned a fixed response. Tried to click an url of the server which returns a 3xx code, and instead of an error i got the fixed response.
In practice, the server behind the ALB listens on port 80, so when it issues a redirect, it does so on HTTP. The ALB receives in as HTTP, but wasn't listening. It was configured only on HTTPS. Hence the error.
I resolved configuring two listeners:
an HTTPS listener which forwards traffic towards the target group
an HTTP listener which redirects to HTTPS
On ALB I have a listener on port 443 with ACM that redirects the traffic on that target group.
It forwards traffic to the target group. It does not redirect the traffic.
The problem is, Odoo can respond with 3xx codes, and I can see the url changing on the browser address bar. But instead of loading the new page, I get an error.
Including the details of that error in your question would be a key detail that needs to be included in your question. You need to edit your question to include the details of that error in order to get more detailed help.
If resend the request directly with this same url, the one resulting from the redirect, the page loads as expected.
If resending the exact request with no changes works, then there is some issue in your server software or something. There is nothing about using an ALB that would make sending the request a second time suddenly work.
From what I could understand, the ALB doesn't manage the 3xx response codes from the target group, so it gives an error.
That isn't correct. The ALB will happily send any response, with any HTTP response code, from the server back to the client. The only issue you may run into is if the health-check URL configured on the target group is sending something other than a 200 HTTP response. The health check requests are the only requests that the ALB/Target Group examine the response code on.
I'm attempting to use Keycloak for some future projects and it's still very new to me so I'm plugging away reading through the docs and searching for issues online but I'm currently stumped on one thing - I have a vuejs app I’ve added as a client (127.0.0.1:3001), I have a reverse proxy setup in IIS (idp.mc.local) and then a docker container on Windows with keycloak running (127.0.0.1:8080), when I attempt to login, instead of being redirected back to the vuejs client I am just getting redirected to the root of the reverse proxy with the state value in the url, as in the network logs in the screenshot below:
Network logs showing incorrected 'Location' redirect
If I don’t set a front end url for the realm and bypass the proxy / hook my vuejs client to login via Keycloak directly on 127.0.0.1:8080, it redirects to 127.0.0.1:3001/#state… correctly, as below:
Network logs showing correct 'Location' redirect
I can't spot any way to sort this issue, I thought the front end url for the realm should state the proxy address? I can't see why Keycloak would redirect to it at the end of the login process rather than to my client app url, the redirect_uri is being ignored by keycloak and for some reason taking me back to the root of my proxy domain. If I actually manually visit 127.0.0.1:3001/#state… with the state value copied in from the incorrect redirect, I log in successfully.
It's baffling me and any help would be appreciated!
The answer did turn out to be an IIS related issue with the setup of Application Request Routing / ARR being the problem. What was needed was to edit the settings for IIS Application Request Routing and uncheck the option:
Reverse rewrite host in response headers as can be seen in the image below:
IIS ARR Checkbox to untick
Hopefully this will be helpful for someone else who might have the same issue at some point!
I'm trying to use nginx to serve a custom error page using the Error Page middleware so that 404 requests to a lambda service (which I don't control) can be handled with a custom error page. I want to be able to get the context of this original request on that error page, either in Nginx for further forwarding, or else as a header for further handling e.g. in PHP or whatnot so I can provide contextual links on the 404 page.
However, right now after the redirection to Nginx in Traefik's ErrorPage middleware it seems the request has lost all the headers and data from the original service query.
The relevant part of my dockerfile:
traefik.port=8080
traefik.protocol=http
traefik.docker.network=proxy
traefik.frontend.rule=PathPrefix:/myservice;ReplacePathRegex:^/myservice/(.*) /newprefix/$$1
traefik.frontend.errors.myservice.status=404
traefik.frontend.errors.myservice.service=nginx
traefik.frontend.errors.myservice.query=/myservice-{status}
Nginx receives the forwarded 404 request, but the request URI comes through as nothing more than the path /myservice-404 specified in query (or /, if I omit traefik.frontend.errors.myservice.query). After the ReplacePathRegex I have the path of the original request available in the HTTP_X_REPLACED_PATH header, but any query arguments are no longer accessible in any header, and nginx can't see anything else about the original URI. For example, if I requested mysite.com/myservice/some/subpath?with=parameters, the HTTP_X_REPLACED_PATH header will show /myservice/some/subpath but not include the parameters.
Is it possible in Traefik to pass another service the complete context about the original request?
What I'm really looking for is something like try_files, where I could say "if this traefik request fails, try this other path instead", but I'd settle for being able to access the original, full request arguments within the handling backend server. If there was a way to send Nginx a request with the full path and query received by Traefik, that would be ideal.
tl;dr:
I am routing a request to a specific service in Traefik
If that request 404s, I want to be able to pass that request to Nginx for further processing / a contextual error page
I want Nginx and/or the page which receives the ErrorPage redirect to be able to know about the request that 404'd in the service
Unfortunately this is not possible with Traefik. I tried to achieve something similar but I realized that the only information that we are able to pass to the error page is the HTTP code, that's it.
The only options available are mentioned in their docs: https://doc.traefik.io/traefik/middlewares/errorpages/
We are implementing the SSO via the Keycloak. When an user wants to access our resources on desiredUri, he is automatically redirected to the keycloak login page{keycloakServerHostname}/auth/realms/{realmName}/protocol/openid-connect/auth?response_type=code&login=true&scope=openid&state={uuidOfStateForCSRF}&client_id={clientName}&**redirect_uri**={**desiredUri**}.
Then a login form is presented, but when I fill in the credentials and the POST call submitting the request is issued on Keycloa, the response from Keycloak is 302 FOUND, but the Location header does not contain my desiredUri+paramsForGettingTokens, but consists of keycloakServerHostname+paramsForGettingTokens instead.
The weird thing is when I manually put i.e. google.com to redirect_uri param, it works and the location header points to google.com, but as soon as I put there localhost, some IP etc. (not resolvable by a public DNS), it stops working and starts to ignore the redirect uri.
It looks like the Keycloak is validating the redirect uri with some kind of DNS lookup and when it cannot resolve that DNS, it puts the baseUrl of Keycloak there instead.
How can I turn off this behavior?
My client settings are as simple as they can be:
Keycloak settings screenshot
Thanks for any advice.
I'm attempting to test a real-time Instagram stream using the Subscription API, but am having trouble setting up subscriptions for local testing.
I attempted using localhost:8080 for the callback_url and editing my /etc/hosts file (redirecting localhost to local.machine.com)
Eventually, I was able to set up a subscription to my home's IP address to receive callbacks from Instagram.
The IP address was in the form:
xxx.xxx.xxx.xx:8080
However, this morning, I was trying from a different IP address in the form xxx.xxx.x.xx:8080 which has continuously led to Instagram returning 400: Bad Request: Invalid URL
Does anybody have any insight as to what Instagram treats as a valid URL parameter for subscriptions?
I would recommend ngrok for this.
It allows you to set up a tunnel between your local machine and the internet.
With ngrok you can on the command line do like this:
ngrok http 8080
That will give you a url like this: http://something.ngrok.io. In your terminal window you can also inspect all traffic through this tunnel.