app_container not reachable after restart of app_container if using $path-Variable

[tebarius]

entrypoint.sh rewrites the .htaccess every time the container is started when using the $path-variable,
for example:
if I set APP_PATH=lb1

the .htaccess inside the container has the following lines:

first start of container:
...
RewriteCond %{REQUEST_URI} !^/lb1/Web(/|$)
RewriteRule ^(.*)$ /lb1/Web/$1 [R=301,L]
....

second start (first restart):
...
RewriteCond %{REQUEST_URI} !^/lb1/lb1/Web(/|$)
RewriteRule ^(.*)$ /lb1/lb1/Web/$1 [R=301,L]
...

third start (second restart):
...
RewriteCond %{REQUEST_URI} !^/lb1/lb1/lb1/Web(/|$)
RewriteRule ^(.*)$ /lb1/lb1/lb1/Web/$1 [R=301,L]
...

so this container only works as long it is not restarted

[tebarius]

one possible solution for this bug can be just change the following lines in entrypoint.sh:

  ## Modify the .htaccess file
  sed \
    -i /var/www/html/.htaccess \
    -e "s:\(RewriteCond .*\)/Web:\1/${APP_PATH}/Web:" \
    -e "s:\(RewriteRule .*\)/Web:\1/${APP_PATH}/Web:"

to

  ## Modify the .htaccess file
  grep -q "/${APP_PATH}/Web" /var/www/html/.htaccess || \
  sed \
    -i /var/www/html/.htaccess \
    -e "s:\(RewriteCond .*\)/Web:\1/${APP_PATH}/Web:" \
    -e "s:\(RewriteRule .*\)/Web:\1/${APP_PATH}/Web:"

so it will not change if already changed

[colisee]

I confirm the issue: well done!

I believe we can skip the grepstatement by fixing the regular expression associated with the RewriteCond.

By the way, I need to check the regular expression associated with the RewriteRule, for I have a doubt now

[colisee]

Also, I am not 100%-sure that using APP_PATH properly works, for I have encountered issues with images and capcha not being displayed. I suspect the problem lies with the upstream repo (librebooking/librebooking) because some paths are being hard-coded...

If you forked this repo and made the above change, could you please confirm you experience the image/capcha issue as well? I am wondering whether it is not the responsibility of a reverse-proxy to handle an application path rather than the container itself...

[tebarius]

i never tested images nor captcha before because I don't need it, but now ... ;)

the trick for my local-test-setup that all works was not overwriting the defaults for LB_UPLOADS_IMAGE_UPLOAD_URL and LB_UPLOADS_RESERVATION_ATTACHMENT_PATH as it was done in the example. ;)

But because this can be various reasons in proxy or docker-setup made a simplyfied Version of my Test-Setup and put it in this Archive.

testing_2.zip

This docker-compose.yml/Dockerfile does take the librebooking/librebooking:4.3.0-3.3.2 build a patched Version which replaces in the entrypoint.sh the line ## Modify the .htaccess file by grep -q "/${APP_PATH}/Web" /var/www/html/.htaccess || \ and than starts up two librebooking-instances and an nginx wich displays a simple startpage and works as reverse-proxy for the instances.

[colisee]

Could you please confirm that my fix works for you as well?

[tebarius]

good job, looks fine to me

[tebarius]

Sorry, but with image 5.0.2-3.3.5 this bug is still back... every restart of the container extends the rules in the .htaccess-file when using APP_PATH

[colisee]

My apologies: I removed a cp that I should have left