我正在项目中使用Django remote user authentication。我实际使用的是没有中间件的django.contrib.auth.RemoteUserBackend，并在与后端确认用户合法之后手动调用authenticate。
阅读中间件的来源，似乎它只是从请求中的标头中获取用户名，然后针对通过此用户名的后端对用户进行身份验证。反过来，远程用户后端只是使用传递的任何用户名轻松地将用户登录。然后，用户可以访问需要有效登录的每个区域。
这不只是一个巨大的安全漏洞吗？这是怎么使用的？
就我而言，我应该很安全，因为对authenticate的唯一调用是在成功进行远程身份验证之后进行的，但是我想知道引入中间件的原因。
[让我转过来解决这个问题：如果您认为这是一个安全漏洞，请尝试编写一个利用该漏洞在应用程序的请求中设置REMOTE_USER标头的漏洞，然后看看会发生什么。
REMOTE_USER可以追溯到Web的早期时代，那时CGI页面是作为您访问该Web页面的用户在本地执行的。 REMOTE_USER实际上是表示活动用户的UNIX环境变量的名称。随着Web服务器安全模型的更改，保留了此方案以保持兼容性。现在，即使IIS也支持它来透明地处理Active Directory登录。
所有用户传递的标题均以HTTP_开头。否则，您将无法相信任何标头信息，例如SERVER_NAME，那将是一团糟。
Django'轻松登录用户'，因为您的网络服务器已检查访问者是否具有该用户名的有效凭据，并相应地设置了标题。
如果您信任您的网络服务器（例如Apache）正确设置REMOTE_USER（或其他）标头，则不是安全缺陷。
您可以参阅文档here。用户无法发送带有REMOTE_USER的客户标头的请求。
警告
如果将RemoteUserMiddleware子类与自定义HTTP标头一起使用，请非常小心。您必须确保前端Web服务器始终根据适当的身份验证检查设置或剥离该标头，决不允许最终用户提交伪造（或“欺骗”）标头值。由于HTTP标头X-Auth-User和X-Auth_User（例如）都标准化为request.META中的HTTP_X_AUTH_USER键，因此，您还必须检查Web服务器不允许使用下划线代替破折号的欺骗标头。
此警告不适用于标头='REMOTE_USER'的默认配置下的RemoteUserMiddleware，因为请求中的密钥不是以HTTP_开头。META只能由您的WSGI服务器设置，而不能直接从HTTP请求中设置标头。