FEAT: Make Application Path Configurable through Environment Variable LB_HOMEPAGE for Flexible Deployment

[Marroquin02]

Summary Currently, the application is hardcoded to run at a specific path (e.g., domain.com/Web). This enhancement allows flexibility in the deployment path by introducing an environment variable LB_HOMEPAGE, which dynamically sets the application’s base URL. With this change, users can configure the app to run at any path they prefer, such as domain.com/reservas/Web, domain.com/booking/Web, etc.

Changes Made Dockerfile and Docker-Compose: Added LB_HOMEPAGE as an argument and environment variable, making the path customizable at build time and run time. Entrypoint Script: Modified .htaccess configuration within entrypoint.sh to dynamically update path references based on LB_HOMEPAGE. This replaces hardcoded paths with the value set in LB_HOMEPAGE, ensuring URL routing matches the specified deployment path. docker-compose.yml: Refactored to include LB_HOMEPAGE as a customizable parameter, aligning the setup with more flexible deployment requirements and enabling variable setting from .env. Benefits This change is essential for users needing flexibility in their deployments, particularly in scenarios with multiple instances or custom URL structures. It supports diverse use cases across various environments without requiring code changes for each deployment, enhancing modularity and ease of deployment.

Let me know if you'd like further help preparing this issue or additional documentation for your contribution.

[colisee]

Hola @Marroquin02 ,

thank you very much for your interest and proposal.

Just to be sure, regarding the necessity of implementing an environment variable LB_HOMEPAGE, did you try the following:

1. Copy the file .htaccess to your host and modify the RewriteCond on line-8 to meet your URL requirement
2. Run the container and override the .htaccess file of the container with the one from your host with —-volume <host_path>/.htaccess:/var/www/html/.htaccess

Saludos.

[Marroquin02]

Hola @colisee,

This method was also tested directly, but the need for adjustment arose because, in my case, I am implementing the system behind a subpath on my server, for example: domain.com/reservations/Web. This setup created an issue, as the system wasn’t configured to operate under a specific subpath. Since all files are located in /var/www/html/Web, sending requests from domain.com/reservations/Web didn’t yield the expected response, as it is behind an Nginx reverse proxy.

To simplify implementation behind subpaths, I developed this solution, which I wanted to share to facilitate its use in similar scenarios.

[colisee]

Hola @Marroquin02 ,

I am a little busy at the moment: give me a few days to better assess the situation and I shall get back to you.

For my own curiosity, what proxy are you using and do you run it through docker/podman as well?

[Marroquin02]

Hola @colisee,

I use an NGINX reverse proxy and always run it through Docker.

Let me know if you need more details.

[colisee]

Could you please give me the nginx docker image name being used, or the content of your docker-compose.yml if you have one (in which case, do not forget to remove any clear-text password)?

I will then make my tests and revert to you.

[Marroquin02]

This is the docker-compose.yml I was trying to make work in the /reservations subpath

version: '3.8'

networks: web: internal: true name: web hostnet: driver: bridge external: true

services: nginx-modsecurity: image: really/nginx-modsecurity container_name: nginx-modsecurity restart: always networks:

• web
• hostnet volumes:
• ./data/nginx/conf.d:/etc/nginx/conf.d
• ./data/letsencrypt:/etc/letsencrypt
• ./data/sitios:/var/www ports:
• "80:80"
• "443:443"

[colisee]

Hola @Marroquin02

My production sample would work, if you were routing based on the host domain (ex: https://service-1.domain.com, https://service-2.domain.com). But since you wish to route based on the path, I believe that adding a label like traefik.http.routers.librebooking.rule=PathPrefix('service-1') on the docker-compose.yml could be the answer.

If you do not intend to switch the web reverse proxy to Traefik because you wish to stay with nginx, then we could test with a combination of nginx-proxy for the web reverse proxy and acme-companion for the automated Let's encrypt certificates management.

Do you have any preferences? In the meantime, I will setup an environment for the tests

[Marroquin02]

Hello @colisee,

In my case, this project was set up internally within the organization where I work (The Central American University José Simeón Cañas) because we found it to be a very comprehensive system. For this same reason, it is quite complicated, if not impossible, for us to migrate, as the server where it is hosted already has the entire environment configured, including certificates, ModSecurity, etc.

Additionally, the image we are using (the one I shared with you) is already serving several other containers on different subdomains and subpaths, and this has been the only one to generate this issue. Looking at the discussions in the app's repository here, it seems others have experienced the same problem.

[colisee]

Hola @Marroquin02 ,

I may have found a solution that eliminates the need of building an ad-hoc image everytime a new path-prefix (what you call LB_HOMEPAGE) is needed. In a nutshell:

1. I set the server document root to /var/www instead of /var/www/html
2. I create a symbolic link to /var/www/html named after the path-prefix
3. I adapt the /var/www/html/.htacess file

I will work from my fork.

[colisee]

Hola @Marroquin02 ,

could you please make a test using the image colisee/librebooking:2.8.6.2-2.5.0 ? There is a new environment variable, named LB_PATH that contains the URL path prefix (for instance LB_PATH=reservations if the full url is https://your.domain/reservations). At this stage, I tested the changes on a 2.8.6.2 release, but not on previous ones (where .htaccess is different)

You can have an overview of what I done in my personal fork.

If you confirm it works OK on your side, then I will push my changes to the official repository.