This more exactly expresses semantics by itself, and is also in preparation of
creating releases through the API (which have no triggering event)
See #146
In settings-code I want to import as little as possible,
as doing it may trip up things, especially in the context
of transitive/circular imports. Better to put the 3 utils
that are used in settings into a separate module.
connection.vendor reflects the actual backend of the connection in use,
not just the ENGINE string in global settings. This makes the check more
robust when multiple databases are configured (e.g. main DB on MySQL,
snappea DB on SQLite). The sqlite-specific handling now only applies to
the relevant connection.
See #117
had me surprised for a little bit while debugging another issue (of which I
thought it might have been caused by whitenoise). Better to have something
to grep for
"In principle" setting `SCRIPT_NAME` is enough. The way we do this is [1] using
`FORCE_SCRIPT_NAME` (which does not depend on messing with reverse proxy
settings and [2] by deducing the correct value from `BASE_URL` (which must be
set anyway) automatically.
By works I mean: `reverse` and `{% url` pick it up from there.
However, there are subtleties / extra work:
* `STATIC_URL` is needed too b/c https://code.djangoproject.com/ticket/34028
* in many pre-existing code I just created a path manually in the html. Such
hrefs are obviously not magically fixed for script_name. Rather than doing
the "full rewrite" (into `{% url`) this commit just prepends the
`script_name` in those cases. That's the way forward that will least likely
break and it gives us something to grep for if we ever want to 'do it
right'.
* `LOGIN_REDIRECT_URL` and `LOGIN_URL` needed to use a view-name for this to
work (using a view-name gets revolved using the thing that introduces
`script_name`)
Checked, no work needed:
* views (`redirect` and `HttpResponseRedirect`)
* html uses of action="..."
Fix#93
In principle, Python 3.9 has ~1 month of life in it (its own EOL).
I'm OK with that in practice for main (we haven't released Bugsink yet),
as well as considering the following overview of popular Linux distros
and their Python versions (which will have a much stronger influence
on practical Python deployment in the wild than whatever the PSF says):
Not affected:
* Ubuntu 22.04 LTS (EOL Apr 2027) has Python 3.10
* Ubuntu 24.04 LTS (EOL Apr 2029) has Python 3.12
* Debian 12 Bookworm (EOL Jun 2028) has Python 3.11
* RHEL 9 (EOL May 2032) default 3.9 but also offers 3.11 and 3.12
* The Docker image we use has Python version configurable (we use 3.12)
Affected:
* Debian 11 Bullseye (EOL Aug 2026) has Python 3.9
Given Bugsink's own age my guess is "no one's on Bullseye".
Defends against certain forms of local privilege escalation, i.e.
understood to be defense in depth rather than a security issue given
the recommended ways of deploying (docker container or in a single-use
single-server)
Fix#174
See https://github.com/python/cpython/pull/23901
