starred/papermerge

Fork 0

mirror of https://github.com/ciur/papermerge.git synced 2026-04-25 12:05:58 +03:00

[GH-ISSUE #244] Horror with Docker & Reverse Proxy because of all the paths #196

New issue

Closed

opened 2026-02-25 21:31:25 +03:00 by kerem · 7 comments

kerem commented

2026-02-25 21:31:25 +03:00

Owner

Originally created by @Baton4986 on GitHub (Dec 4, 2020).
Original GitHub issue: https://github.com/ciur/papermerge/issues/244

hey guys,
it's very hard to configure a reverse proxy with docker because nearly every function in papermerge has it's own path (/upload/, /static/, /nodes/ etc.). It's even harder if you are running other apps that shares a path with papermerge like /upload/.

My Apache Config looked like:

ProxyPass /papermerge/ http://127.0.0.1:8000/ retry=0
ProxyPassReverse /papermerge/ http://127.0.0.1:8000/

ProxyPass /alltags/ http://127.0.0.1:8000/alltags/ retry=0
ProxyPassReverse /alltags/ http://127.0.0.1:8000/alltags/

ProxyPass /automate/ http://127.0.0.1:8000/automate/ retry=0
ProxyPassReverse /automate/ http://127.0.0.1:8000/automate/

ProxyPass /breadcrumb/ http://127.0.0.1:8000/breadcrumb/ retry=0
ProxyPassReverse /breadcrumb/ http://127.0.0.1:8000/breadcrumb/

ProxyPass /browse/ http://127.0.0.1:8000/browse/ retry=0
ProxyPassReverse /browse/ http://127.0.0.1:8000/browse/

ProxyPass /upload/ http://127.0.0.1:8000/upload/ retry=0
ProxyPassReverse /upload/ http://127.0.0.1:8000/upload/

...

And some functions still doesn't work. Best solution would be a top-level path like /papermerge/ and then sub-paths for all other functions. This makes Reverse-Proxy configs very easy with 2 lines like this:

ProxyPass /papermerge/ http://127.0.0.1:8000/papermerge/ retry=0
ProxyPassReverse /papermerge/ http://127.0.0.1:8000/papermerge/

I have tested this with many other apps, some of them support Docker Environment Variables to configure this path.

regards

Originally created by @Baton4986 on GitHub (Dec 4, 2020). Original GitHub issue: https://github.com/ciur/papermerge/issues/244 hey guys, it's very hard to configure a reverse proxy with docker because nearly every function in papermerge has it's own path (/upload/, /static/, /nodes/ etc.). It's even harder if you are running other apps that shares a path with papermerge like /upload/. My Apache Config looked like: ``` ProxyPass /papermerge/ http://127.0.0.1:8000/ retry=0 ProxyPassReverse /papermerge/ http://127.0.0.1:8000/ ProxyPass /alltags/ http://127.0.0.1:8000/alltags/ retry=0 ProxyPassReverse /alltags/ http://127.0.0.1:8000/alltags/ ProxyPass /automate/ http://127.0.0.1:8000/automate/ retry=0 ProxyPassReverse /automate/ http://127.0.0.1:8000/automate/ ProxyPass /breadcrumb/ http://127.0.0.1:8000/breadcrumb/ retry=0 ProxyPassReverse /breadcrumb/ http://127.0.0.1:8000/breadcrumb/ ProxyPass /browse/ http://127.0.0.1:8000/browse/ retry=0 ProxyPassReverse /browse/ http://127.0.0.1:8000/browse/ ProxyPass /upload/ http://127.0.0.1:8000/upload/ retry=0 ProxyPassReverse /upload/ http://127.0.0.1:8000/upload/ ... ``` And some functions still doesn't work. Best solution would be a top-level path like /papermerge/ and then sub-paths for all other functions. This makes Reverse-Proxy configs very easy with 2 lines like this: ``` ProxyPass /papermerge/ http://127.0.0.1:8000/papermerge/ retry=0 ProxyPassReverse /papermerge/ http://127.0.0.1:8000/papermerge/ ``` I have tested this with many other apps, some of them support Docker Environment Variables to configure this path. regards

kerem

2026-02-25 21:31:25 +03:00

closed this issue
added the
docker

help wanted
labels

kerem commented

2026-02-25 21:31:25 +03:00

Author

Owner

@whysthatso commented on GitHub (Dec 19, 2020):

i'm curious why you encounter these problems. are you trying to run an apache2 instance infront of the running container setup? or are you trying to replace the apache2 instances inside the docker-compose setup as it's being run as an application server via mod_wsgi-express?
in the latter case i don't know, in the former case i'm not sure why you would need all these routes?

tbh i don't know the apache setup, the corresponding nginx vhost for my setup looks like that:

  upstream papermerge_server {
    server app.example.net:42551 fail_timeout=0;
  }

  server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name papermerge.example.net;
    
  <snip ssl stuff>

    client_max_body_size 20M;
    keepalive_timeout 5;
    root /var/www;
    try_files $uri/index.html $uri.html $uri @app;

    location @app {
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
      proxy_pass http://papermerge_server;
    }

}

@whysthatso commented on GitHub (Dec 19, 2020): i'm curious why you encounter these problems. are you trying to run an apache2 instance infront of the running container setup? or are you trying to replace the apache2 instances inside the docker-compose setup as it's being run as an application server via mod_wsgi-express? in the latter case i don't know, in the former case i'm not sure why you would need all these routes? tbh i don't know the apache setup, the corresponding nginx vhost for my setup looks like that: ``` upstream papermerge_server { server app.example.net:42551 fail_timeout=0; } server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name papermerge.example.net; <snip ssl stuff> client_max_body_size 20M; keepalive_timeout 5; root /var/www; try_files $uri/index.html $uri.html $uri @app; location @app { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_pass http://papermerge_server; } } ```

kerem commented

2026-02-25 21:31:25 +03:00

Author

Owner

@Baton4986 commented on GitHub (Dec 29, 2020):

i'm curious why you encounter these problems. are you trying to run an apache2 instance infront of the running container setup? or are you trying to replace the apache2 instances inside the docker-compose setup as it's being run as an application server via mod_wsgi-express?
in the latter case i don't know, in the former case i'm not sure why you would need all these routes?

tbh i don't know the apache setup, the corresponding nginx vhost for my setup looks like that:
  upstream papermerge_server {
    server app.example.net:42551 fail_timeout=0;
  }

  server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name papermerge.example.net;
    
  <snip ssl stuff>

    client_max_body_size 20M;
    keepalive_timeout 5;
    root /var/www;
    try_files $uri/index.html $uri.html $uri @app;

    location @app {
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
      proxy_pass http://papermerge_server;
    }

}

This only happens if running reverse-proxy without using a subdomain (mydomain.com/papermerge/ instead of papermerge.mydomain.com)

@Baton4986 commented on GitHub (Dec 29, 2020): > i'm curious why you encounter these problems. are you trying to run an apache2 instance infront of the running container setup? or are you trying to replace the apache2 instances inside the docker-compose setup as it's being run as an application server via mod_wsgi-express? > in the latter case i don't know, in the former case i'm not sure why you would need all these routes? > > tbh i don't know the apache setup, the corresponding nginx vhost for my setup looks like that: > > ``` > upstream papermerge_server { > server app.example.net:42551 fail_timeout=0; > } > > server { > listen 443 ssl http2; > listen [::]:443 ssl http2; > server_name papermerge.example.net; > > <snip ssl stuff> > > client_max_body_size 20M; > keepalive_timeout 5; > root /var/www; > try_files $uri/index.html $uri.html $uri @app; > > location @app { > proxy_set_header Host $host; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > proxy_set_header X-Forwarded-Proto $scheme; > proxy_pass http://papermerge_server; > } > > } > ``` This only happens if running reverse-proxy without using a subdomain (mydomain.com/papermerge/ instead of papermerge.mydomain.com)

kerem commented

2026-02-25 21:31:25 +03:00

Author

Owner

@whysthatso commented on GitHub (Jan 1, 2021):

ah right, that makes sense.

to be honest, i've never really understood the idea of separating services by means of path rather than subdomain. i strictly follow the principle: one service = one subdomain, and i think that was the actual intention of the domain name structure; which by its virtue avoids complexities like these kind of routing issues. maybe a way to go after all?

i do understand that there are limitations in choice and amount of subdomains depending on the dns provider situation, maybe a good reason to switch :)

@whysthatso commented on GitHub (Jan 1, 2021): ah right, that makes sense. to be honest, i've never really understood the idea of separating services by means of path rather than subdomain. i strictly follow the principle: one service = one subdomain, and i think that was the actual intention of the domain name structure; which by its virtue avoids complexities like these kind of routing issues. maybe a way to go after all? i do understand that there are limitations in choice and amount of subdomains depending on the dns provider situation, maybe a good reason to switch :)

kerem commented

2026-02-25 21:31:25 +03:00

Author

Owner

@Baton4986 commented on GitHub (Jan 20, 2021):

the main issue is that you will need a ssl-cert that is valid for every subdomain. using letsencrypt means you have to set an a-record for each subdomain and then issue a cert. i'm using univention corporate server with its built in letsencrypt-app and it's much more comfortable to setup a new service there with just a new apache config file than all the other steps needed for the way with subdomains. with a path it is also possible to deploy this as a docker based app with just a click in different systems like univention corporate server, nas-systems etc. because nothing outside the docker host has to be configured (like a-records or new certs). so i always prefer the path-based-way if possible :)

@Baton4986 commented on GitHub (Jan 20, 2021): the main issue is that you will need a ssl-cert that is valid for every subdomain. using letsencrypt means you have to set an a-record for each subdomain and then issue a cert. i'm using univention corporate server with its built in letsencrypt-app and it's much more comfortable to setup a new service there with just a new apache config file than all the other steps needed for the way with subdomains. with a path it is also possible to deploy this as a docker based app with just a click in different systems like univention corporate server, nas-systems etc. because nothing outside the docker host has to be configured (like a-records or new certs). so i always prefer the path-based-way if possible :)

kerem commented

2026-02-25 21:31:25 +03:00

Author

Owner

@whysthatso commented on GitHub (Jan 20, 2021):

i understand your use case, of course. just for sake of completeness:

letsencrypt offers wildcard certificates
one would probably prefer cname records over a records, but that depends on the underlying infrastructure

and - of course - one avoids a bunch of "horrible" routing issues :D

but i do acknowledge that there are different scenarios.

@whysthatso commented on GitHub (Jan 20, 2021): i understand your use case, of course. just for sake of completeness: - letsencrypt offers wildcard certificates - one would probably prefer cname records over a records, but that depends on the underlying infrastructure and - of course - one avoids a bunch of "horrible" routing issues :D but i do acknowledge that there are different scenarios.

kerem commented

2026-02-25 21:31:25 +03:00

Author

Owner

@ciur commented on GitHub (Mar 8, 2021):

Is this ticket still relevant ? Can I close it ?

@ciur commented on GitHub (Mar 8, 2021): Is this ticket still relevant ? Can I close it ?

kerem commented

2026-02-25 21:31:25 +03:00

Author

Owner

@Baton4986 commented on GitHub (Mar 15, 2021):

hi, as this is more a feature-request than an issue, you can close this. but still would be nice to have this option for deployment :)

@Baton4986 commented on GitHub (Mar 15, 2021): hi, as this is more a feature-request than an issue, you can close this. but still would be nice to have this option for deployment :)

kerem referenced this issue

2026-02-25 21:32:15 +03:00

[PR #216] [MERGED] Fix automates ACL and other #564