Raising an exception triggers an email-to-admin-action, and the whole
reason we have this NUL check is to *avoid* triggering those emails...
Hopefully explicitly returning a 400 HttpResponse will maek them go
away.
This would already not work at a lower layer, but would typically
generate an internal server error exception instead of just an error
message.
Instead, put an explicit check in the middleware that's already
validating the query parameters and reject them with a 400 error.
Require each view to declare which query parameters it wants, and filter
out any other parameters.
We have very few views that actually take query parameters, and random
additional query patterns will have no effect on the view. However, they
will break frontend caching (in making them look like different pages).
This will be extended into an implementation in the caching frontends as
well, btu it's needed in the backend to ensure that local testing will
have tbe same effect as the caches.
If an xkey tag is already set on a response when it reaches the
middleware, add it to the set of automated xkeys generated from the
templates instead of overwriting it.
We don't have non-ascii characters in any of our correct URLs, but
people can still specify them on the URL. In this case the xkey isn't
going to match anything anyway, so it is not critical how we handle it,
especially since the generated page is going to be a 404 anyway. So just
use the simple built-in replace function.
The following security policy headers are set:
X-XSS-Protection: 1; mode=block -- always set
X-Frame-Options: DENY is set for all pages except for the documentation
pages, primarily because pgadmin4 loads them in an iframe which would
break.
Content-Security-Policy: <x>-src
Is set to allow the default of self only, then allowing scripts for
google analytics and fonts for google fonts. Images are allowed from everywhere.
frame-ancestors 'none' is set by the same rules as X-Frame-Options
This also adds a decorator for @script_sources to have a single view
allow extra sources, and this is used for recaptcha. A generic decorator
is also made for other types of exclusions, though we don't have any at
this point.
If the setting SECURITY_POLICY_REPORT_ONLY is set to True then the policy
will be report-only and not enforced (for testing), otherwise enforcing
mode is enabled.
The setting SECURITY_POLICY_REPORT_URI sets where to send security
policy reports, if any.
This adds an xkey header to all outgoing requests with the hash of the
name of all templates loaded. In the future we will be able to use this
to purge "all pages that included a specific template", regardless of
where in the hierarchy it was loaded.
Do this by faking a template loader that never finds anything -- but it
will record the path of the template that it tried to load, and then
leave it to another template loader to actually load it. Store this in
thread local storage (it's a bit ugly, but it's the only thing Django
supports for storing things at the request level from a template
loader), and fetch it from the middleware.
This can break things (d'uh).
Do this by introducing a new decorator, @ssl_optional. When this is
present, no SSL redirection will happen, regardless of whether the
access comes in over http or https.
This decorator overrides @ssl_required, but for redability's sake,
never use both at the same time.
