I run icCube behind an nginx acting as a reverse proxy and force https requests. icCube as a backend server is then called through http.
Requests received by jetty (icCube) are currently not https.
I need a well formatted request URI scheme (containing https) as it is used for my SSO authentication made in a custom servlet filter installed in icCube.
I presume an issue with Jetty's configuration because as described in Jetty's document regarding forwarded request: https://www.eclipse.org/jetty/javadoc/9.4.8.v20171121/org/eclipse/jetty/server/ForwardedRequestCustomizer.html
The reverse proxy (nginx) passes the following headers to jetty:
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Ssl on;
proxy_set_header X-Proxied-Https on;
proxy_set_header X-Forwarded-Proto $scheme;
I've looked in the icCube configuration class handling the jetty configuration:
crazydev.iccube.server.http.IcCubeHttpComponentConfiguration
And nothing about forwarded requests.
Jetty is shipped with default configuration files and one fits my needs: https://github.com/eclipse/jetty.project/blob/jetty-9.4.x/jetty-server/src/main/config/etc/jetty-http-forwarded.xml
How could I apply forwarding configuration ?
Thanks in advance for your help.
Prior to icCube 6.8.5, there is no way to configure an instance of ForwardedRequestCustomizer.
From icCube 6.8.5, the icCube.xml configuration file will contain a new entry for that purpose:
<forwardedRequestConfiguration>
<forwardedOnly>...</forwardedOnly>
<proxyAsAuthority>...</proxyAsAuthority>
<forwardedHeader>...</forwardedHeader>
<forwardedHostHeader>...</forwardedHostHeader>
<forwardedServerHeader>...</forwardedServerHeader>
<forwardedProtoHeader>...</forwardedProtoHeader>
<forwardedForHeader>...</forwardedForHeader>
<forwardedHttpsHeader>...</forwardedHttpsHeader>
<forwardedSslSessionIdHeader>...</forwardedSslSessionIdHeader>
<forwardedCipherSuiteHeader>...</forwardedCipherSuiteHeader>
</forwardedRequestConfiguration>
Related
I have a Nginx server with reverse proxy for my API. How can I return the website host URL instead of returning the API URL api.example.com, because when I make a request from website it returns the API URL not the website URL app.example.com.
location /api/1 {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Forwarded-Port 443;
proxy_set_header Connection 'updgrade';
proxy_set_header Host $host;
proxy_pass https://api.example.com/rest;
proxy_ssl_server_name on;
}
p/s: sorry for my bad english
if you want to change url in returned your application code and your application behind the proxy makes references to api.example.com instead of app.example.com, you need to change your application logic to return correct URL in this use case.
Or use sub_filter module, But you need to check your nginx was built with this module.
I have the standalone version of GeoServer 2.21.0 running behind an NGINX reverse proxy. Whenever I attempt to do anything with the web UI, Wicket is redirecting me to HTTP when I need it to send me to HTTPS.
The server does serve up map tiles correctly. It's just that the web UI is completely dysfunctional as it's running over HTTPS and GeoServer redirects everything to HTTP for some reason.
I also have the CSRF whitelist set but I'm having problems before CSRF comes into play. If I do so much as go to https://myserver/geoserver it redirects me to http://myserver/geoserver/web/?0 which doesn't work.
I have a GeoServer instance running behind NGINX. NGINX is configured like this:
location / {
proxy_pass http://127.0.0.1:9191/; proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_redirect off;
}
I have the Proxy Base URL configured to https://myserver/geoserver and Use headers for Proxy URL is enabled.
What might be causing this? A Google search wasn't very helpful.
The answer was proxy_redirect ~*http://[^/]+(/.*)$ $1;
This rules tells NGINX to remove everything from the beginning http all the way up through the hostname in the redirect so that the redirect sends the user to the reverse proxy's (i.e. NGINX) host.
relevant answer
I have an application running in Kubernetes with the following topology:
Some-ingress-controller--> nginx reverse proxy -->dynamically generated services.
I have set the NGINX reverse proxy with the following test configuration
location /mysite1/ {
proxy_set_header Host $host;
proxy_set_header Referer $http_referer;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto http;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Host $remote_addr;
proxy_pass http://myservice1.default.svc:9000/;
}
So far everything works fine - when I go to my website http://example.com/mysite1/ I see what I expect from the myservice1 application hosted at http://myservice1.default.svc:9000/. However, the application myservice1 issues requests to various internal (internal meaning they are part of the same container) resources on /get_resourceX. When the myservice1 application tries to access these resources they will be accessed at http://example.com/get_resourceX/ and not at http://example.com/mysite1/get_resourceX as they should - and that is my problem.
What could work is to simply reverse proxy all the relevant resource names as well. However, then I would need to do the same for http://example.com/mysite2, http://example.com/mysite3 etc. which is impractical since these are generated dynamically.
Another possible solution is to check the http Referrer header and see whether it originates from mysite1 - but that seems awfully hackish.
How can I easily have myservice1 requests issued to /get_resourceX served by itself? Is there a generic way to set the root path for the myservice1 application to myservice1?
I have NGINX set up to route requests to example.com to nodejs server on port 3000 which serves the front end and example.com/api to nodejs api server on port 3001.
I try to connect to the socket on port 3001 like:
const socket = openSocket('example.com/api');
But I get an error in the console:
polling-xhr.js:265 POST https://example.com/socket.io/?
EIO=3&transport=polling&t=MWPLGiL 404 (Not Found)
It looks like socket.io is still trying to connect to only example.com.
Any idea why the /api is being ignored? I need this to go to example.com/api since that server is configured to handle the socket connections. Would be grateful if some one can help me. Thank you!
I solved the problem by adding the following in NGINX config:
location ~ ^/(api|socket\.io) {
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://localhost:3001;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_read_timeout 900s;
}
Sorry for asking the question without digging in more. Hope this helps some one else.
We are nginx newbies and trying to replace httpd with it.
We have the following nginx configuration:
location /auth {
proxy_pass http://keycloak_server$request_uri;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
}
This works in providing access to the administrator portal. However we use also keycloak for authentication for our applications, and the problem is that keycloak responds with a 302 redirect however nginx treats it as a 502 bad gateway error.
The apache httpd works without any problems.
What are we doing wrong ? Any pointers or specific configuration guidance would be appreciated.
The issue was resolved. It was because the upstream was sending too big a header. Modifying the buffer size for proxy worked.