django-xff 1.3.0

django-xff做什么

这个库提供了一个像样的、可配置的中间件来重写 将request.META['HTTP_REMOTE_ADDR']设置为正确的客户端IP。

X-Forwarded-For: phony, client, proxy1, proxy2
X-Forwarded-For: client, proxy1, proxy2
X-Forwarded-For: client, proxy

注意：

• Less proxies than expected is allowed by default, for varying lengths of proxy chains, the longest is the only one that can be trusted.
• No header set is allowed by default and the library does nothing.

什么django-xff不做

这个库不检查任何代理的IP地址 消息的路径。

待办事项

• Separate middleware that checks CIDR for the trusted proxies
• Separate middleware that checks exact IP addresses for proxies

配置

在django settings.py模块中添加以下内容以启用 预期的两个反向代理的中间件。中间商是 加工后的外观顺序。这个中间件应该在某个地方 接近顶部以避免给潜在的恶意用户机会 使用格式错误的请求验证密码：

MIDDLEWARE_CLASSES = [
   <a few middlewares here>
   'xff.middleware.XForwardedForMiddleware',
   <more middlewares here>
]

XFF_TRUSTED_PROXY_DEPTH = 2

默认情况下，不会拒绝任何尝试。有几个设置要发送 对失败请求的400（错误请求）响应。严格模式将 停止所有失败的请求：

XFF_STRICT = True

要仅防止明显的恶意请求，请使用以下命令 相反：

XFF_NO_SPOOFING = True

防止不通过足够代理的请求，请使用 以下内容：

XFF_ALWAYS_PROXY = True

前一个设置意味着在没有 X-Forwarded-For头存在。以下设置遵循 XFF_ALWAYS_PROXY和XFF_STRICT默认，但可以设置 独立：

XFF_HEADER_REQUIRED = False

即使在XFF_LOOSE_UNSAFE模式下，也需要头：

XFF_LOOSE_UNSAFE = True

对于不安全的设置，在开发过程中，您可以相信 第一个条目总是正确的，并且仍然得到假定的客户端IP 正确的位置，使用：

XFF_LOOSE_UNSAFE = True

如果您想保持X-Forwarded-For头不变，即使 还有其他条目，请使用：

XFF_CLEAN = False

白名单

在某些情况下，需要来自备用请求路径的请求。 amazon elastic loadbalancer healthcheck或其他管理 任务需要可用，即使它们不符合条件。

这个库接受uri作为正则表达式 检查。这些将免除任何验证，包括 XFF_STRICT和XFF_HEADER_REQUIRED。

定义白名单：

XFF_EXEMPT_URLS = [
    r'^healthcheck/$',
    r'^admin/',
]

这将允许从任何地方调用/healthcheck/和/admin/*。 允许每个人用更少的资源访问管理站点是个愚蠢的想法 比现场其他部分的要求。因为这个原因 当请求到达时，可以用404（未找到）响应 穿过主入口：

XFF_EXEMPT_STEALTH = True

这将假定低于XFF_TRUSTED_PROXY_DEPTH的任何内容都是 可信的。这种方法很幼稚，但很有效。

日志记录

将记录丢弃的请求。这意味着会有很多 当库配置错误或恶意程序正在执行时记录 地点。建议保留日志以便在 攻击。但是，可以通过设置将它们从开发中筛选出来：

LOGGING = {
    'loggers': {
         'xff.middleware': {
              'handlers': ['null'],
              'propagate': False,
         },
     },
}

设置

建议启用假定数量为 代理和调查日志。如果标题不存在或 中间件未配置，将有没有日志条目。如果日志 说明深度不正确，应减小。如果全部 请求被认为是欺骗，深度应该是 增加：

MIDDLEWARE_CLASSES = [
    'xff.middleware.XForwardedForMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
]

XFF_TRUSTED_PROXY_DEPTH = 2

当日志显示正确时，可以按增量增加控制：

XFF_NO_SPOOFING = True

然后：

XFF_STRICT = True

使用其他标志集定义异常是可行的。以下 可用于AWS弹性负载平衡器后面以防止进入 没有正确的头集但允许healthcheck返回 正确地。隐身还将用404屏蔽同一个uri 错误：

XFF_TRUSTED_PROXY_DEPTH = 1
XFF_EXEMPT_URLS = [r'^health/]
XFF_REQUIRE_HEADER = True
XFF_EXEMPT_STEALTH = True