596cf2580b
django.security.DisallowedHost is only one of a set of exceptions that are "SuspiciousOperation" exceptions; all return a 400 to the user when they bubble up[1]; all of them are uninteresting to Sentry. While they may, in bulk, show a mis-configuration of some sort of the application, such a failure should be detected via the increase in 400's, not via these, which are uninteresting individually. While all of these are subclasses of SuspiciousOperation, we enumerate them explicitly for a number of reasons: - There is no one logger we can ignore that captures all of them. Each of the errors uses its own logger, and django does not supply a `django.security` logger that all of them feed into. - Nor can we catch this by examining the exception object. The SuspiciousOperation exception is raised too early in the stack for us to catch the exception by way of middleware and check `isinstance`. But at the Sentry level, in `add_context`, it is no longer an exception but a log entry, and as such we have no `isinstance` that can be applied; we only know the logger name. - Finally, there is the semantic argument that while we have decided to ignore this set of security warnings, we _may_ wish to log new ones that may be added at some point in the future. It is better to opt into those ignores than to blanket ignore all messages from the security logger. This moves the DisallowedHost `ignore_logger` to be adjacent to its kin, and not on the middleware that may trigger it. Consistency is more important than locality in this case. Of these, the DisallowedHost logger if left as the only one that is explicitly ignored in the LOGGING configuration in `computed_settings.py`; it is by far the most frequent, and the least likely to be malicious or impactful (unlike, say, RequestDataTooBig). [1] https://docs.djangoproject.com/en/3.0/ref/exceptions/#suspiciousoperation
Zulip overview
Zulip is a powerful, open source group chat application that combines the immediacy of real-time chat with the productivity benefits of threaded conversations. Zulip is used by open source projects, Fortune 500 companies, large standards bodies, and others who need a real-time chat system that allows users to easily process hundreds or thousands of messages a day. With over 500 contributors merging over 500 commits a month, Zulip is also the largest and fastest growing open source group chat project.
Getting started
Click on the appropriate link below. If nothing seems to apply, join us on the Zulip community server and tell us what's up!
You might be interested in:
-
Contributing code. Check out our guide for new contributors to get started. Zulip prides itself on maintaining a clean and well-tested codebase, and a stock of hundreds of beginner-friendly issues.
-
Contributing non-code. Report an issue, translate Zulip into your language, write for the Zulip blog, or give us feedback. We would love to hear from you, even if you're just trying the product out.
-
Supporting Zulip. Advocate for your organization to use Zulip, write a review in the mobile app stores, or upvote Zulip on product comparison sites.
-
Checking Zulip out. The best way to see Zulip in action is to drop by the Zulip community server. We also recommend reading Zulip for open source, Zulip for companies, or Zulip for working groups and part time communities.
-
Running a Zulip server. Use a preconfigured DigitalOcean droplet, install Zulip directly, or use Zulip's experimental Docker image. Commercial support is available; see https://zulip.com/plans for details.
-
Using Zulip without setting up a server. https://zulip.com offers free and commercial hosting, including providing our paid plan for free to fellow open source projects.
-
Participating in outreach programs like Google Summer of Code.
You may also be interested in reading our blog or following us on Twitter. Zulip is distributed under the Apache 2.0 license.