Reverse-Proxy-Server

  1. ‹ Older
  2. 3 years ago

    Lars L

    22 Mar 2017 Pre-Release Testers, Xojo Pro Europe (Germany, Chemnitz)

    Is there a xojo staff member, which can help?

    How can we map thru the UUIDS for the comms?

  3. Kevin W

    22 Mar 2017 Pre-Release Testers, Xojo Pro

    Sounds like you need to use "location /" in your settings. You don't want to be trying to piece together every url, just forward everything to the xojo app.

  4. John J

    22 Mar 2017 Pre-Release Testers, Xojo Pro Cleveland, Ohio

    I would recommend you set up a separate subdomain for the app instead of routing by a directory name - is that an option for you?

  5. Lars L

    23 Mar 2017 Pre-Release Testers, Xojo Pro Europe (Germany, Chemnitz)

    Yes, I brought it to live while using an own supdomain for the app. That works.

    Plesk only supports the proxy-configuration for subfolders. So I had to change the nginx.conf file by my self, which is originally generated by Plesk. Unfortunately everytime I make some changes on the subdomain, I have manually reconfigure this file again because Plesk overwrites it.

    But yea, subdomains working!

    also with ssl!

  6. Tomas J

    23 Mar 2017 Pre-Release Testers, Xojo Pro Europe (Germany)
    Edited 3 years ago

    Nice to hear this! congrats and yes in such cases plesk or other admin tools like webmin (my favorite) are at their limits. For direct editing I am using mc / mcedit instead of vi or other editors... hounting shadows of my past MSDOS and Norton Commander times ;-)

  7. John J

    23 Mar 2017 Pre-Release Testers, Xojo Pro Cleveland, Ohio

    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.

  8. Tomas J

    10 Apr 2017 Pre-Release Testers, Xojo Pro Europe (Germany)
    Edited 3 years ago

    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! :-)

  9. 11 months ago
    Edited 11 months ago

    @Patrick L 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.

    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.

    ...location / {
    		proxy_pass http://127.0.0.1:800/;
    
    	}
    
    	location /manage {
    		proxy_pass http://127.0.0.1:8070/;
    	}...

    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.

  10. Lars L

    8 Nov 2018 Pre-Release Testers, Xojo Pro Europe (Germany, Chemnitz)

    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 ;-)

  11. John J

    8 Nov 2018 Pre-Release Testers, Xojo Pro Cleveland, Ohio

    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.

  12. Thanks Lars,

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

    @Lars L 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?

    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.

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

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

  13. Daniel W

    14 Nov 2018 Australia

    @John J 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;
    }

    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.

  14. Greg O

    15 Nov 2018 Xojo Inc

    Compressed responses do not affect the urls themselves.

  15. John J

    15 Nov 2018 Pre-Release Testers, Xojo Pro Cleveland, Ohio
    Edited 11 months ago

    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

    @Greg OLone Compressed responses do not affect the urls themselves.

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

  16. John J

    15 Nov 2018 Pre-Release Testers, Xojo Pro Cleveland, Ohio
    Edited 11 months ago

    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�	
    ...
  17. Daniel W

    15 Nov 2018 Australia

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

    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.

  18. Daniel W

    15 Nov 2018 Australia

    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.

    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;
    	}
    		....
    }
  19. Daniel W

    15 Nov 2018 Australia

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

  20. John J

    15 Nov 2018 Pre-Release Testers, Xojo Pro Cleveland, Ohio

    Nice - you got it!!

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

  21. 9 months ago

    Daniel W

    26 Jan 2019 Australia

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

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

    =

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

or Sign Up to reply!