As per the git-log, the contents of that directory were actually copied to
Bugsink from GlitchTip at GlitchTip's commit af9a700a8706, but GlitchTip itself
had copied it from Open Source Sentry, as noted in the LICENCE that they
included in their sentry directory.
(Checking Bugsink's git-log, I see that some code has since been removed from
the sentry directory, but other than that nothing substantial has been
changed).
This was probably about the making Project.objects.get(id, sentry_key)
more efficient, but
* I don't have an indication it's a bottleneck
* It may very well be turned into a get-by-id, check-for-key idiom,
in which case the index won't help.
recently introduced (e59fd3a225) caching made it so that repeated calls to
create_release_if_needed no longer work if releases have been created in the
meantime.
In actual usage create_release_if_needed is always called on a single project
so I _think_ just calling `fresh` in the tests is good way to get to green
tests again.
I thought about removing the 'no trailing slash' remark everywhere, but that
would leave people that actually care about these things guessing. (with, without, both ok?)
In the trade-off between "virality" (easy access) and security, I'd
like to err a bit more towards security for this case.
My current thinking: complete openness would be too surprising. And
at the level we're at post-commit, at least one more action must be
taken by the superuser before it's potentially out-of-control (that
action being: inviting someone who's then inviting the world)
For now, sticking to "how it actually works" is more important than "what we
might need in the future". We don't have an admin-group with actually handed
out perms yet, and we do have the recommendation to create a superuser in the
installation docs. So let's just explicity check for that.
(I found these checks while working on actual breakage in the previous commit)
We already removed this one from the place where it matters most, i.e. the
recommended template.
The key bit of info is: the hard bit is in doing this for HTTPS/SSL, because
in that case you don't have a certificate (it could be for any web address).
Details are in the website's repo, in templates/production-install.html.
This is more canonical with stuff 'elsewhere on the internet'
we already did it behind-the-scenes for 'recommended gunicorn', so the
harmonization is in having the same default for the rest.
This was copied into the conf-template from the snappea/settings.py; but never
properly integrated (and it's not something I'd like to suggest as a point of
configuration)
