Deploy Web 2 on apache server?

I do understand the new Linux approach. But I have to work with the Apache server until all apps (of my suit). Can someone give an advice how to this the smart way?

I guess you will need to configure Apache as a reverse proxy to handle requests to/from Xojo Web.

Or add Nginx as the reverse proxy for Apache and Xojo Web apps.

1 Like

your apache web server have default ports for http/https
your xojo web app have it own web server build in with your choosen port.

see NGINX if you like to access your xojo app through apache.
the advantage is your xojo app not need https because they are behind apache.

1 Like

In a test env. I have configured Apache to use proxy’s. I use a WebApp on port 9001 to test. I have set up a ProxyPass and ProxyPassReverse for ip-address/test.
ip-address:9001 works fine. But ip-address/test gives a white page.
It looks like not all elements are proxyed between the front-end and the back-end.
I need to set up the test env. with load-balancing in Apache, and need this proxy architecture for that in the future also.
I have used NGINX for python projects. It works there. But I can not use NGINX for all projects. (client specifications).

I’m also seeing this behaviour with Web 2.0 and Apache.

Set up a second ProxyPass to a Web1 test app. Now I get error message:
Launching…
The application has gone off-line. Please try again later.
This application has encountered an error and cannot continue.

But when opening de port behind the proxy, the app works OK.
It looks like the proxy is not passing through all required protocol elements. There are no error logs on this, however. No apache2 errors.

The browser in web development makes clear that Xojo generated code assumes the path of the front-end is the part of the app. (not the case with a proxypass).

Loading with source ‘http://front-end-ip/framework/jquery-ui.min.js’ failed.

I am going to take a stab in the dark, as I was just reading how to do this on Microsoft IIS using Application Request Routing (I’m also used to working with Nginx on Linux).

Could it be that you are using a relative path, instead of using the domain of the Apache server within your xojo app? Your last post stating you were getting:

Loading with source ‘http://front-end-ip/framework/jquery-ui.min.js’ failed.

Seems to indicate a relative path might be used in the Xojo app.

An example of a resolution is in this article, that pertains to IIS on Windows Server, but a similar thing might be happening to you on Apache:

The solution in the article was to do outbound URL rewriting to replace any reference to the server being proxied to with the Apache server. In part 2 of that article (I linked to part 3) they talk about needing to turn off compression between the web server and proxied application server so that the outbound URL rewriter can do its job.

The easiest solution would be to let your application know (maybe in a settings config file instead of hardcoding) what the domain address of your Apache server is, and use that instead of relative paths which would eliminate the need for any outbound URL rewriting.

I apologize that this is not Apache related, but it sounds like a similar issue that you might be facing.

Hope this at least sparks an idea of getting this working on Apache for you.

-Mike

1 Like

For testing, set up another nginx server. On Web2 app I get a blank page again. And Quirks-modus error message in the browser error messages.

I’ve run Web1 and Web2 apps on Ubuntu/Apache and Let’s Encrypt for the security certificate. First, build the Xojo app using an unused port number over 1000 (helps avoid problems with reserved ports.) I used 8081 in this example. Don’t do anything for a secure site, we do that later. I like using a virtual server so I can take a snapshot before making changes. If I break anything, its quick and easy to rollback the snapshot and recover.

Disclaimer: I’m a Windows guy (and VAX/VMS before that.) I’m still learning Linux. There may be better ways to do this.

If your server already has Apache or other web servers, or other stuff, this may break things or not work. A fresh, dedicated server is best.

Make sure Apache is installed, here’s how I do it:

sudo -s
apt install apache2
adduser <username> www-data
chown -R root:www-data /var/www/html
chmod -R 775 /var/www/html
chown -R root:www-data /etc/apache2/sites-available
chmod -R 775 /etc/apache2/sites-available
# enable the proxy module
a2enmod proxy  
# enable sub-module for http proxy
a2enmod proxy_http

Copy your app files to the server. A subfolder under /var/www/html/ is the preferred place. Make sure the permissions on your subfolder and its contents is 775. And you’ll need to manually run the app, or create a cron job to start it when the server restarts.

In the sites-available folder, create a config file for your app. The file name should be something like appname.conf.

<VirtualHost *:80>
ServerName www.mydomain.com
ServerAlias mydomain.com
ProxyPreserveHost on
ProxyRequests on
ProxyPass / http://localhost:8081/
ProxyPassReverse / http://localhost:8081/
</VirtualHost>

Enable the website with this command:

sudo a2ensite /etc/apache2/sites-available/appname.conf

Now the website/app should work, but only with http (it’s not secure yet.) If it doesn’t work, fix it before moving on.

Time to install Cerbot if not already. This is the Let’s Encrypt tool that does pretty much everything for you. If its already installed, attempting to reinstall won’t hurt it.

sudo apt install certbot
sudo apt install python3-certbot-apache

Run Certbot to set up everything needed for https. Follow the prompts from Certbot.

certbot --apache

The website should now work with https.

You can run multiple websites on one server. Just create a new config file, enable the site, then run certbot again.

If you have multiple websites, certbot will create a certificate for multiple domains. This will make it difficult if you eventually need to move one of the sites. I recommend running certbot multiple times, and selecting only 1 website at a time. This creates multiple certificates, one for each website.

And if you don’t know or want to learn all the Linux stuff, see @Tim_Parnell Lifeboat product.

1 Like

Thanks, Eric.
On the test-server, I don’t have ssl on. I work from the ip-address in a private network.
I work on the 000-default domain.
Your settings confirm my settings. Still, somehow, the /framework directory is not accessible from the browser for apps behind the proxy. Given the fact that direct addressing the ports works, it has to do with the proxy not correctly pointing to the right paths.

Having a clear picture of the problem, to search on it. I found a clear analyses of it in the Caddy user forum. (have tested proxy the apps with nginx, caddy and apache2 all the same results)

I conclude Xojo Web1 and Web2 are not proxy robust. (as most web apps are not)
And proper proxy setup asks for more scripting for non proxy-robust web apps.

A possibility for subfolders … I had a web app (since converted to Wordpress, but that’s a different story) that needed to display JPG images. A database with metadata, along with the user’s selections determined which images to show. The actual image files were in a subfolder.

The way I got this to work was to create another website using a subdomain. Create a DNS entry for images.mydomain.com, pointing to the same server. Then set up that website with a config file like this:

<VirtualHost *:80>
DocumentRoot /var/www/html/myapp/images
ServerName images.myapp.com
</VirtualHost>

Use certbot to get a certificate set up for this new website.

Now you can reference something like https://images.myapp.com/myphoto.jpg and it will show the image from /var/www/html/myapp/images/myphoto.jpg.

The framework directory is never accessible from a Xojo Web app unless you specifically build something to do so in HandleURL. I would suspect this blank page you’re seeing comes with a status code of 404, because that’s how HandleURL works.

I only know what I see in the error console of the browser for the web1 app behind the proxy:
Loading failed for the with source “http://…36/framework/framework.js”. in my browser.
And:
GET
http://…36/EB05151EA2DD41997DAB48671E5A9E6D6F9718B9/styles.css
GET
http://149.210.134.36/framework/framework.js
Ans so on …
Web2 gives just a blank page. And in the browser error console a lot of:
GET
http://149.210.134.36/framework/jquery-ui.min.css [HTTP/1.1 404 Not Found 3ms]

So are you saying that during normal web app usage these files are being requested by the framework but are turning up as 404/Not Found when the browser tries to get them?

Getting a 404 code and a 0-length blank page suggests to me the ProxyPass working and the Xojo Web Framework receiving the request. By default, Apache sends a small page when it can’t find a file.

Are the web1/web2 files own by Apache user:group?
Are the rwx attributes correct? for all Xojo web files

Do you have any custom entries such as stylesheets in your app html header (maybe loading over http or https not matching the scheme you are accessing the app over)?

Unfortunetly, Xojo webapps don’t work from subfolders. They always asume they are in the ROOT directory and try to get needed js/css files from the ROOT domain. The only way to make it work, is to create a subdomain and use that for your xojo webapp.

2 Likes

That was the way to go. Subdomain switching with load balancing. Got a test env working that way for XWeb1 and XWeb2.