A list of strings representing the host/domain names that this Django site can serve. This is a security measure to prevent an attacker from poisoning caches and password reset emails with links to malicious hosts by submitting requests with a fake HTTP Host header, which is possible even under many seemingly-safe web server configurations.
Values in this list can be fully qualified names (e.g. 'www.example.com'), in which case they will be matched against the request’s Host header exactly (case-insensitive, not including port). A value beginning with a period can be used as a subdomain wildcard: '.example.com' will match example.com, www.example.com, and any other subdomain of example.com. A value of '*' will match anything; in this case you are responsible to provide your own validation of the Host header (perhaps in a middleware; if so this middleware must be listed first in MIDDLEWARE_CLASSES).
Changed in Django 1.7:
In previous versions of Django, if you wanted to also allow the fully qualified domain name (FQDN), which some browsers can send in the Host header, you had to explicitly add another ALLOWED_HOSTS entry that included a trailing period. This entry could also be a subdomain wildcard:
复制代码
ALLOWED_HOSTS = [
'.example.com', # Allow domain and subdomains
'.example.com.', # Also allow FQDN and subdomains
]
复制代码
In Django 1.7, the trailing dot is stripped when performing host validation, thus an entry with a trailing dot isn’t required.
If the Host header (or X-Forwarded-Host if USE_X_FORWARDED_HOST is enabled) does not match any value in this list, the django.http.HttpRequest.get_host() method will raise SuspiciousOperation.
When DEBUG is True or when running tests, host validation is disabled; any host will be accepted. Thus it’s usually only necessary to set it in production.
This validation only applies via get_host(); if your code accesses the Host header directly from request.META you are bypassing this security protection.