PythonTip >> 博文 >> Django

使用apache+mod_wsgi方式部署完成后,访问网站时400(Bad Request)

zihua 2014-03-08 18:03:49 点击: 852 | 收藏



        在所有工作部署工作完成后,通过域名访问网站,发现提示:400(Bad Request)



        苦尽甘来,经过一番折腾,终于发现了一篇文章, (这是谢谢这哥们了,心情无以附加,无以言表)


DEBUG = False      # 由True到False,这个我也做对了

# 下面这个,忘记了,高了半天,废了老大劲才知道是这的问题
    '', # Allow domain and subdomains
    'localhost', # Also allow FQDN and subdomains]





Host header validation

Django uses the Host header provided by the client to construct URLs in certain cases. While these values are sanitized to prevent Cross Site Scripting attacks, a fake Host value can be used for Cross-Site Request Forgery, cache poisoning attacks, and poisoning links in emails.

Because even seemingly-secure web server configurations are susceptible to fake Host headers, Django validates Hostheaders against the ALLOWED_HOSTS setting in the django.http.HttpRequest.get_host() method.

This validation only applies via get_host(); if your code accesses the Host header directly from request.META you are bypassing this security protection.

For more details see the full ALLOWED_HOSTS documentation.


Previous versions of this document recommended configuring your web server to ensure it validates incoming HTTP Host headers. While this is still recommended, in many common web servers a configuration that seems to validate the Host header may not in fact do so. For instance, even if Apache is configured such that your Django site is served from a non-default virtual host with the ServerName set, it is still possible for an HTTP request to match this virtual host and supply a fake Host header. Thus, Django now requires that you set ALLOWED_HOSTSexplicitly rather than relying on web server configuration.

Additionally, as of 1.3.1, Django requires you to explicitly enable support for the X-Forwarded-Host header (via theUSE_X_FORWARDED_HOST setting) if your configuration requires it.




Default: [] (Empty list)

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. ''), in which case they will be matched against the request’sHost header exactly (case-insensitive, not including port). A value beginning with a period can be used as a subdomain wildcard: '' will match, and any other subdomain of 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).


If you want to also allow the fully qualified domain name (FQDN), which some browsers can send in the Host header, you must explicitly add another ALLOWED_HOSTS entry that includes a trailing period. This entry can also be a subdomain wildcard:

    '', # Allow domain and subdomains
    '', # Also allow FQDN and subdomains]

If the Host header (or X-Forwarded-Host if USE_X_FORWARDED_HOST is enabled) does not match any value in this list, thedjango.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.





作者:zihua | 分类: Django | 标签: django | 阅读: 852 | 发布于: 2014-03-08 18时 |