I'm writing to request support for reconsidering the wontfix of #33981 <https://code.djangoproject.com/ticket/33981>, which squelches the stack trace resulting from SuspiciousOperation DisallowedHost introduced in #13910 <https://github.com/django/django/pull/13910>.
#33981 should be reconsidered because discussion of the related issue, #13910 , focused strictly on behavioral consistency and code correctness but did not include discussion of the impact of this change. The problem of excessive logs due to vulnerability scans in production deployments of Django goes back 10 years to #19866 <https://code.djangoproject.com/ticket/19866>. The main argument for a noisy DisallowedHost exception back then was to reduce the challenge of debugging an improper production configuration of Django for production. In line with that argument, one of the arguments for closing #33981 was the desire to "see an exception when a traceback is logged." However, the concern of needing logging around *this specific exception* was seemingly handled <https://code.djangoproject.com/ticket/19866#comment:6> when SuspiciousOperation was originally downgraded to a warning: "I'm a bit concerned that changing it to a warning leaves us overly-prone to not-quickly-detected mis-configuration, but maybe we need to address that via something like #17101 <https://code.djangoproject.com/ticket/17101> instead." #17101 was the feature implementation of the --deploy option for the Django management command. This feature, combined with the clearly explained documentation in Deployment Checklist <https://docs.djangoproject.com/en/4.1/howto/deployment/checklist/#run-manage-py-check-deploy> seems to reasonably handle this concern. However, earlier this year, when PR #13910 <https://github.com/django/django/pull/13910> provided consistency to logging calls from response_for_exception(), the change added a stack trace to SuspiciousOperation, (which includes DisallowedHost) and seriously buffed the log noise from ongoing vulnerability scans. Two months ago, someone submitted a PR #33981 <https://code.djangoproject.com/ticket/33981>, suggesting the inclusion of stack traces on DisallowedHost was a mistake. #33981's author makes the following points: 1. "Requiring a user to write a custom formatter in order to eliminate an exception trace dump from the logs is, in my view, a useability mistake." 2. Edited down for brevity: "There are places in the framework where exception handlers serve as a catch-all for exceptions...tracebacks are needed when logs are written from these locations as they are so general and it's too late to find a clean way to handle them all. SuspiciousOperation, is a handled exception, handled cleanly and specifically. The probability you want a traceback is low. So why generate a traceback for this well handled exception? That just has the effect of potentially distracting from any other more urgent tracebacks." I believe both of these points have merit consideration above and beyond the historical context and objection handling provided above. The challenge of production deployment for Django comes up all too often. The --deploy option and docs reasonably deal with alerting users to ALLOWED_HOSTS configuration gotchas. SuspiciousOperation exceptions, in general, focus on user behavior around common security concerns. Warnings alone provide clear enough indication of what has been attempted with stack traces offering limited value. In the case of DisallowedHost, including these traces arguably sets every production deployment of a Django project up for logs that mostly consist of one stack trace being displayed over and over again. I want to address one other point: People have complained about the noise of DissallowedHost when it was only a Warning in the logs. In years past, I've seen these complaints about vulnerability scanning log spam deflected to developer's failure to properly configure their web server or reverse proxy. ~"Your stack is wrong. This should never reach python." These complaints persist and varying use cases make these kind of configuration changes are non-trivial <https://serverfault.com/questions/1108830/using-nginx-to-block-connections-that-arent-addressed-to-my-domain>. This solution to DisallowedHost log noise blows problem of "I just want to be able to see my Django application's debug logs" up into a new stratosphere of challenge in infrastructure configuration. The author of #33981 was referred to this mailing list to seek agreement of additional consideration from this group. Though the author seemed impassioned to express their frustration and desire for serious consideration of their points and solution, I did not see that they took this costly additional step. I have again been dealing with this default behavior interfering with good faith efforts to view debug logging on an issue on a production Django deployment. I feel the PR author's pain and hope their idea gets serious consideration. My hope is that others here do as well. Kind Regards, Rob -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/aa7c6629-7457-4af4-8275-2785115c3bdcn%40googlegroups.com.
