Development config was pretty much same as reverse-proxy and can be easily confusing which should be
used. Now we make distinction just if you have something in front of nginx or does nginx handle the
ssl traffic.
If you use ssl certificates in docker-compose nginx, use https mode, if you have something in front of nginx, use revese-proxy mode
Instead of allowing all image files anywhere, and disallowing non-image file under /images/, only
allow image files under /images/ and don't match non-image files elsewhere. They get proxied to web
instead and result in a 404 there.
For example, the old config allowed /exports/foo.jpg to be served, while the new config does not.
- improve nginx config
- fix DATA_UPLOAD_MAX_MEMORY_SIZE default not being an int
- translate fallback value in id_to_username template tag
- make location of setting to turn on user exports easier to locate for admins
fixes#3227fixes#3231fixes#3232fixes#3236
- new setting to enable user exports defaults to False
- add setting to enable and disable user exports
- do not allow user exports when using s3 storage
- do not serve non-image files from /images/ (requires update to nginx settings)
- increase default file upload limit to 100MB to enable user exports to be imported (can be changed in .env)
This copies over the changes Trammell added to the development file. I
also realized that I think it's fine to only commend out the https
redirect, rather than commenting out the entire server block for
listening on port 443? If this works it makes the file a lot easier to
read.
Co-authored-by: Trammell Hudson <hudson@trmm.net>
For people installing an instance with only the reverse proxy server, the hidden trailing `}` at the end of the second server block is quite hard to catch and it took me a good while to figure it out. Having the entire server commented out makes the whole process more understandable in my opinion.
