See image below of vaadin 7, nginx. What could be wrong?
web.xml
sample config:
server {
listen 80;
server_name crm.komrus.com;
root /home/deploy/apache-tomcat-7.0.57/webapps/komruscrm;
proxy_cache one;
location / {
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_pass http://127.0.0.1:8080/komruscrm/;
}
}
As it seems (because you don't provide enough info about your problem) you are using nginx as reverse proxy for tomcat/jboss/jetty, and you are deploying a Vaadin application in it.
Just when you enter in the application, session expired message appears.
I had this problem 3 months ago. In my escenario Nginx was 1.0 and Vaadin 7.0+. The issue comes because of the cookies. I know that nginx must set or rewrite something in the cookies, but, you must set it manually in nginx.conf file, else, you will get that error.
Sadly, in my nginx version I wasn't able to pass cookies in the right way, so, I wasn't able to deploy my application under that scenario.
After some issues, I've decided to use Apache's reverse proxy, and never saw that issue again. Hope you can write a rule that enables to pass the cookies in the right way.
EDIT: I remembered this post How to rewrite the domain part of Set-Cookie in a nginx reverse proxy?, this is the case!
Related
I have a flask application using nginx for a reverse proxy/ssl termination, but I'm running into trouble when using url_for and redirect in flask.
nginx.conf entry:
location /flaskapp {
proxy_pass http://myapp:8080/;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
The idea is that a user navigates to
https://localhost:port/flaskapp/some/location/here
and that should be passed to flask as
http://localhost:8080/some/location/here
This works reasonably well when navigating to a defined route, however if the route has redirect(url_for('another_page')), the browser is directed to
http://localhost:8080/another_page
And fails, when the URL I actually want to go to is:
https://localhost:port/flaskapp/another_page
I have tried several other answers for similar situations, but none have seemed to be doing exactly what I am doing here. I have tried using _external=True, setting app.config['APPLICATION_ROOT'] = '/flaskapp' and many iterations of different proxy_set_header commands in nginx.conf with no luck.
As an added complication, my flask application is using flask-login and CSRF cookies. When I tried setting APPLICATION_ROOT the application stopped considering the CSRF cookie set by flask-login valid, which I assume has something to do with origins.
So my question is, how do I make it so that when flask is returning a redirect() to the client, nginx understands that the URL it is given needs flaskapp written into it?
I managed to fix it with some changes.
Change 1. Adding /flaskapp to the routes in my flask application. This eliminated the need for URL-rewriting and simplified things greatly.
Change 2. nginx.conf changes. I added logc in the location block to redirect http requests as https, new conf:
location /flaskapp {
proxy_pass http://myapp:8080/;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# New configs below
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
# Makes flask redirects use https, not http.
proxy_redirect http://$http_host/ https://$http_host/;
}
While I didn't "solve" the issue of introducing conditional rewrites based on a known prefix, since I only need one prefix for this app it is an acceptable solution to bake it into the routes.
In your situation I think the correct thing would be to use werkzeug's ProxyFix middleware, and have your nginx proxy set the appropriate required headers (specifically X-Forwarded-Prefix).
https://werkzeug.palletsprojects.com/en/0.15.x/middleware/proxy_fix/#module-werkzeug.middleware.proxy_fix
This should make url_for work as you would expect.
Edit: Snippet from #Michael P's answer
from werkzeug.middleware.proxy_fix import ProxyFix
app = Flask(__name__)
app.wsgi_app = ProxyFix(app.wsgi_app, x_for=1, x_host=1)
I'm pretty unexperienced using reverse proxy, so my question can be really lame, sorry for that.
I'm trying to reach my owncloud server through nginx reverse-proxy, but it can't load perfectly.
I have an NGINX reverse-proxy server using multiple locations. I would like to make a new public access to my owncloud server located in another machine with apache.
I would like to use _https://my_public_url/owncloud_ to reach my owncloud server, so I made the location block like this:
Whem I'm using
location / {
proxy_pass http://my_owncloudserver_url/;
everything is fine.
But in this case:
location /owncloud/ {
proxy_pass http://my_owncloudserver_url/;
I get the index.php/login page without any formatting, as /apps, /core, etc. requests are still requested from "https://my_public_url/apps/...", "https://my_public_url/core/...", etc. instead of "https://my_public_url/owncloud/core/..." where the files are located, as these requests don't match with /owncloud/ location and aren't proxied.
I guess I should use rewrite to change the urls of these requests, putting the "/owncloud/" part into the url.
If I'm using a separate location to match with "/core/..." requests, like:
location /core/ {
rewrite ^/core/(.*)$ /owncloud/core/$1 permanent;
}
then it seems to be OK, but I won't make a lot of different locations to match with all various requests.
How could I fix this?
I'm running out if ideas, although it must be pretty easy.
Thanks,
sanglee
I'm not sure about Owncloud. But in Nextcloud you have to configure some proxy parameters in the config.php https://docs.nextcloud.com/server/16/admin_manual/configuration_server/config_sample_php_parameters.html#proxy-configurations
Please consider to use Nextcloud because it is faster than Owncloud, if fully open source, more features and is actively maintained by the community.
Update OWNCLOUD_SUB_URL” to “/owncloud” when running the container, or find the subtitute config if running not using containers
And on nginx config
location /owncloud {
proxy_pass http://my_owncloudserver_url/owncloud;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_redirect off;
proxy_buffering off;
}
I'm running an application inside Tomcat on port 2211 and all is well. However I would like to serve this application whenever anyone browses to site.com/service and for that I came up with this Nginx proxy pass setup.
location /service {
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Ssl on;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Frame-Options SAMEORIGIN;
proxy_pass https://127.0.0.1:2211;
}
But when I browse to site.com/service I can only see my jetty application in plain HTML. For some reason all files even though they exist on Tomcat the browser receives a 404 reply for all of them.
I've looked into how the browser is requesting the file, for example:
<img src="/themes/logo.png">
This image instead of being requested at site.com/service/themes/logo.png is being asked at site.com/themes/logo.png, which obviously doesn't work and therefore 404 not found. The same happens to all other files, it should be looking for them at site.com/service not on the root folder site.com.
Surely Nginx is missing some configuration parameters, could you point towards it?
Both nginx and the image are behaving correctly, the proxy is returning the html just as it is, the problem is that the tomcat server thinks that it's the root, so it returns all the assets relative to the root, you can fix this in a couple of ways
Either change the subfolder /service to a subdomain service.domain.com this way the assets will truely be in the root.
Somehow configure the tomcat server to return all it's links relative to the /service folder, an easy way would be adding a base inside the head tag
<base href='http://domain.com/service'>
This way the urls will all be absolute, but that will only make the urls functional under that proxy
Instead of modifying your tomcat application, you can tell nginx to add that header by it self, by doing some replacement in the returned html using sub_filter, it would insert in inside the head tag
sub_filter '</head>' '<base href='$scheme://$server_name/service></head>';
I am feeling that I have searched the complete internet and tried nearly everything to solve my problem. Now I decided to ask you and hope that there is anybody out there who is able to help me.
I have a node application running on sub2.domain.tld:3000. Now I want to proxy this application to port 80 with nginx in the way that I am able to reach the app with sub.domain.tld. But that is not the problem. I am able to reach the first site.
The problem follows by an authentification routine with OAuth-API to verify the user for the application.
When surfing to sub2.domain.tld:3000 the process works fine. But when I change the url in the configs and try to surf to sub.domain.tld the authentification process runs into an error (error=redirect_uri_mismatch&error_description=The+redirect_uri+MUST+match+the+registered+callback+URL.....).
So I guess I am making a mistake in the redirecting of the url with nginx.
I am using nginx 1.4.7 and node 0.10.26
My nginx configuration file looks like that:
server {
listen 80;
access_log /var/log/nginx/access_log_sub;
server_name sub.domain.tld;
location / {
include proxy_params;
proxy_pass http://IP:3000;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Client-IP $remote_addr;
proxy_set_header X-Forwarded-for $remote_addr;
}
}
But I belive OAuth is verifying sub2.domain.tld:3000 and that it gets in conflict with sub.domain.tld
I hope you are able to help me, solving this issue.
The error isn't coming from nginx, it's coming from your OAuth provider:
The redirect_uri parameter is optional. If left out, GitHub will redirect users to the callback URL configured in the OAuth Application settings. If provided, the redirect URL's host and port must exactly match the callback URL. The redirect URL's path must reference a subdirectory of the callback URL.
-- https://developer.github.com/v3/oauth/#redirect-urls
This is an old question, but...
Try changing your Host header to
proxy_set_header Host $host:$server_port
This may or may not work depending on your application.
As an aside, X-Forwarded-For should include a comma-separated list of the originating client and any proxies it passes through.
To give you a bit of background on my problem:
I have an app that installs software and serves it publically. When it installs:
Installs base files to root path (i.e. /var/www/{site})
Creates a new nginx configuration file and places it in /etc/nginx/sites-available/{site}
Creates a symlink to that file from /etc/nginx/sites-enabled/{site}
Reloads the nginx configuration: service nginx reload
Sends an API call to CloudFlare to direct all requests from {site}.mydomain.com to the server's IP address
After that, {site}.mydomain.com should work, except... it doesn't!
... Until you wait ~5 minutes, and then it magically starts working. Is there a delay before proxying comes into effect with nginx?
If I delete {site} and readd it (same process as above), even if it was working before, it stops working for awhile before starting to work again.
I'm at a loss to explain what's happening!
nginx config (where {site} is foobar)
upstream mydomain_foobar {
server 127.0.0.1:4567;
}
server {
listen 80;
server_name foobar.mydomain.com;
root /var/www/mydomain/foobar/;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_set_header X-NginX-Proxy true;
proxy_pass http://mydomain-foobar/;
proxy_redirect off;
# Socket.io Support
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
}
After looking at this issue on and off over the past month, it turns out the issue was not related to nginx at all.
When a rec_new API call is sent to CloudFlare, it takes roughly five minutes (300s TTL) for their records to update. The same can be said for any other DNS related API call to CloudFlare.
This explains the five minute gap.
From Cloudflare:
Hi,
DNS updates should take place after about five minutes (the ttl is 300 seconds). It may take a little longer to propagate out everywhere on the web (recursive DNS caching by your ISP, for example).