"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
Having this as a model field is "annoying" because each added language
will trigger a (potentially costly) migration even though no real database
work is actually done for it.
Also implements a selector that shows languages in both their own language
and the currently activated language.
Correct spelling to "zh-hans" (lowercase); see https://stackoverflow.com/a/7729311
See #161
we only support one kind: files.
(in the past it was useful to send-to-self already uploaded items,
but this idea is never used in practice, and the whole idea of having to supply a
'kind' on the cmdline is confusing)
Using patterns here to play well with our excellent dogfood error
tracker:
When the non-validating value is displayed in the exception value, this makes
grouping not work (every event is its own issue); the approach has no upside,
because in a dogfooded setup the local vars are known anyway.
