This reverts course on 4201fbd778, and restores event.schema.json from that
commit. In that commit we said: 'this is not used'. Not true: it's used in a
test, though this test used the validity check to silently skip.
In this commit:
1. Do _not_ just silently skip invalid samples. Since we have a way of properly
validating, let's use that so that we know how useful the samples that we have
actually are.
2. Deal with "_meta", a field that we sometimes see in the "private samples" (data
that ultimately comes from running a somewhat recent python-sdk against my
actual codebase). The need for this was exposed by [1]
3. Add a test for the up-to-date-ness of event.json.schema
4. remove special-cased attribute-checks in `is_valid`; `send_json` was, at the
time, an opportunistic way to just get my hands on some sample data. the
approach at validation reflected that: I just did some tests on the existence
of certain attributes to determine which json files were even events. But in
the end I did a full validation using an API schema, which kinda made the
whole business useless. This commit cleans up the individual checks.
I briefly considered making this a separate job, but I can't really justify that;
the 'separate' job would have to do all kinds of similar setup (pip install), and
to what end really? Broken is broken, I just want a notification. I'll see quickly
enought that it's about makemigrations
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.
