Reverse-Proxy-Server

Good to hear it Lars! Something else you can do is change the permissions on your config file to prevent writing (assuming you have root/sudo access). Then Plesk will not be able to overwrite it.

I’ll bring up this thread cause I’ve spend my weekend and monday on similar problem bringing my OnlyOffice App Server to work behind Apache2 reverse proxy. Finally the trick was to use on both ends https encryption. Regardless if it’s a private or public cert. The combination of http in the intranet and https to the world may cause headaches.

If somebody is interesed in more details: https://help.nextcloud.com/t/onlyoffice-behind-reverse-proxy-doesnt-work-please-help

Call me Apache-Woodoo-Master… and now I am proud to have my own and secure cloud solution. Nextcloud and OnlyOffice. A strong combination! And by the way: Bye Bye iCloud! :slight_smile:

[quote=322093:@Patrick Lim]Having said that, I am struggling with trying to do the same as you (instead of connecting directly to a port other than 80 or 443).
I always get the Xojo “Server disconnected” text (but without any images). It’s like Xojo loads the framework but is then unable to talk to it.[/quote]
I am having the exact same issue. I have multiple web app instances running on a server. I want to use relative paths to route traffic to different webapps depending on the path.

[code]…location / {
proxy_pass http://127.0.0.1:800/;

}

location /manage {
	proxy_pass http://127.0.0.1:8070/;
}...[/code]

The first one works fine, but the /manage path behaves as described above.

Any ideas?

Edit: subdomains aren’t an option as service will be deployed to many different domains and IPs.

First: I would recommend that you only use port numbers above of 9000. Under this, there is a high chance, that another software is using this already.

Second: Do I get you right, that the App on port 900 works, but not the app on port 8070? Did you tried another port for the second app?

Third: Is the app on port 8070 really running? Did you checked this with ‘top’?

Last: Is your app daemonized? Do you use the unhandledException event? It seems that your app crashes on startup. Is that possible?

After this clearifications we can start to inspect your nginx settings and behaviour :wink:

Perhaps the xojo app is sending data that has URLs in it that are not coded for your app directory proxy setup. For instance, when someone hits https://yourserver.com/manage the server includes responses with links like this “/framework/some.file” or the like. Paths that don’t include the “/manage/” part - so those requests are being routed elsewhere. That may explain why the bare root path works and the subfolder root path does not.

So you might need nginx to rewrite URLs in the RESPONSES from the xojo app to correct the directory.

something like:

location /manage {
		proxy_pass http://127.0.0.1:8070/;
		sub_filter 'href="/' ''href="/manage/';
		sub_filter 'src="/' ''src="/manage/';
		sub_filter_once off;
	}

This will require some playing around to get just right, but I think you understand the basic problem. The output from the app contains root-based links that do not include your /app/ directory. Note, the substitutions module may or may not be enabled by default in your nginx installation.

Thanks Lars,

Thanks for the advice. Is this true if you have complete control over the server the software is running?

location / { proxy_pass http://127.0.0.1:800/; }
This works as like John mentioned, Xojo doesn’t route request via the path it was loaded from. (does that make sence?)

I did check that the app was working by entering http://127.0.0.1:8070 into my browser.

Thanks John! I was hoping there was a way, I’ll test that and let you know how it goes.

[quote=413315:@John Joyce]something like:

location /manage {
proxy_pass http://127.0.0.1:8070/;
sub_filter ‘href="/’ '‘href="/manage/’;
sub_filter ‘src="/’ '‘src="/manage/’;
sub_filter_once off;
}
[/quote]
Xojo compresses it’s requests so this doesn’t seem to work yet. I tried setting the “Accept-Encoding” to prevent encoding but Xojo ignores it.

Compressed responses do not affect the urls themselves.

I think your best hope is either proxy_set_header Accept-Encoding “”; or the gunzip module - so:

location /manage {
     proxy_pass http://127.0.0.1:8070/;
     proxy_set_header Accept-Encoding ""; <----- either this one
     gunzip on; <----- or this one
     sub_filter 'href="/' ''href="/manage/';
     sub_filter 'src="/' ''src="/manage/';
     sub_filter_once off;
}

*requires gzip module

He is trying to change the URLs in the compressed responses.

OK so I did a little testing and I was not able to make Xojo (2018r3) NOT compress the response, even with the most bare request or with Accept-Encoding removed, set to blank, identity or gzip;q=0 or multiple other variations.

I also found this thread which seems to discuss the problem as well. Leaving out the Accept-Encoding header is supposed to prevent the compression but it seems that IRL it compresses it anyway.
https://forum.xojo.com/37602-disabling-response-compression/0

So if you can’t prevent it you will need to unzip it in nginx, do the substitutions, then return the modified response.

Here is an example of a base request still receiving a compressed response even with no “Accept-Encoding” header whatsoever.

REQUEST

> GET / HTTP/1.1
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_1) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0.1 Safari/605.1.15
> Host: localhost:10003

RESPONSE

< HTTP/1.1 200 OK
< Content-Type: text/html
< Date: Thu, 15 Nov 2018 14:36:52 GMT
< X-Content-Type-Options: nosniff
< Connection: close
< X-Frame-Options: SAMEORIGIN
< Cache-Control: no-cache
< Content-Encoding: gzip
< Content-Length: 1304
<
?V?n?6}?W??8@$;?????$N?-???&?SAKc?Y?TI???=?|?/Al????9s?????O~z`?+??d??"??N???|J?6/?b?y??B?i?$?vs?dP??p????,?q??L?wb,)b?V??K?w)?]?V???iY?4q?pm????.??$???P??4?	?W???"wE??Ld??db?q?,U?	
...

Thanks John, appreciate your help! I did try gunzip the other day but I don’t think I have the correct module installed. I was just hoping there was another option. I’ll figure out how to install it and report back.

I was finally able to get Xojo Web to work behind a reverse proxy using a path. Thank you community! This is useful for hosting two differnet xojo web instances on one server. WebApp1 can redirect you two WebApp2 using a relative path regardless of the server or client IP/DNS name. In my case, I need WebApp1 to show WebApp2 in an iframe.

I could see from running nginx -V the module was already installed. Apparently it is installed on nginx-full and nginx-extra by default. You need to run gzip_disable "."; to make it actually work though.

It was a bit painful, and this will probably break when the framework updates, but this works for me. This could also break if you use some parts of XojoWeb that my app doesn’t use.

[code]server {
listen 80 default_server;

listen 443 ssl;

root /config/www;
index index.html index.htm index.php;

server_name _;

ssl_certificate /config/keys/cert.crt;
ssl_certificate_key /config/keys/cert.key;

client_max_body_size 0;

location / {
	proxy_pass http://127.0.0.1:8090/;
}

location /manage/framework {
	gunzip on;
	gzip_disable ".";
	sub_filter_once off;
	sub_filter_types *; #allows sub_filter to edit js and css
	sub_filter '"/'  '"/manage/';
	sub_filter '/framework'  '/manage/framework';
	rewrite /manage/(.*) /$1  break;
	proxy_pass http://127.0.0.1:8070/;
	proxy_redirect     off;
	proxy_set_header   Host $host;
}

location /manage {
	gunzip on;
	gzip_disable ".";
	sub_filter_once off;
	sub_filter_types *; #allows sub_filter to edit js and css
	sub_filter 'url(/framework'  'url(/manage/framework';
	sub_filter '/framework'  '/manage/framework';
		sub_filter '="/'  '="/manage/';
		sub_filter 'setSource('  'setSource(\\'manage\\' + ';
		#sub_filter 'setSource("'  'setSource("/manage';
		sub_filter '/_files'  '/manage/_files';
	rewrite /manage/(.*) /$1  break;
	proxy_pass http://127.0.0.1:8070/;
	proxy_redirect     off;
	proxy_set_header   Host $host;
}
	....

}[/code]

It’s probably a good idea re-compress the requests before sending them on. I don’t think this would be very difficult.

Nice - you got it!!

Excellent I am glad you were able to work it out and thanks for posting this solution for reference.

A correction to the code above (can’t seem to edit it)

		sub_filter '/framework'  '/manage/framework';

=

#		sub_filter '/framework'  '/manage/framework';

How is this implemented on Apache?
thanks.