Sadly, when using a SearchVector, Django will introduce a COALESCE
that will then prevent our index to be used. So we need to add
this COALESCE in the index to make psql happy.
fix#1414
Here's a summary of the changes and why
* added 'apt update' before the install -- only _needed_ on a completely fresh VM, but never hurts
* added an install of the virtualenv package, because it is used later but: do you still need it AND python3-venv? I'm assuming it was done that way for a reason.
* changed indentation on the mkdir so it will format correctly
* added `-D ~postgres` to the commands executed as postgres user because the postgres user does not, by default, have permission to read into real user's home directories (at least in 22.04) and so the commands would error out
* change `source <activate>` to `. activate` because the line `sudo -u umap -i` launches `sh`, not `bash`, and `sh` does not recognize the source command. `.` works in either.
* remove the instructions to change STATIC_ROOT and MEDIA_ROOT because they are already defaulted to those values in the current version sample of local.py
* added a notice to change the SECREY_KEY and ADMINS list just because it seemed like a good idea.
Side note: I have not seen any docs anywhere that explains exactly what the secret Key does, or where it is used. It's used a magic variable in the config file.. ?
I am not currently messing with nginx or wsgi, so I can't comment on those parts.
uMap allows to use remote URL as data sources, but those URLs
are not always CORS open, so this is why there is this "ajax-proxy"
feature, where the URL is passed to the backend.
Additionally, there is a caching feature, which duration is configurable
through frontend settings. Valid values are: disabled, 5 min, 1 hour,
1 day.
Initially, I wanted this to be totally handled by Nginx, but I never
found a wayt to set the proxy_cache_valid value from a query string.
Since then, at least in OSM France servers, the ajax-proxy is still
handled by a Django view, which then opens the remote URL and transfert
the data. This is not optimal. And I suppose this is what is causing
hicups on the OSM France servers lately.
This PR provides a mix option, where python deals with validating the
URL and parsing the TTL parameter, and then it passes the hand to
nginx which will serve the remote content.
So, roughtly:
- the client calls /ajax-proxy/?url=xxx&ttl=300
- python will validate the URL (not internal calls…)
- if UMAP_SENDFILE_HEADER is set, then the python returns an empty
response with the path /proxy/http://url plus it will set the
cache ttl through the header X-Accel-Expires
- this /proxy/ location is then handled by nginx
