问题
前段时间，做了一次服务器减负的同时，也把所有的遗留网站都加上了 HTTPS 支持，让客户免受推荐 HTTPS 证书销售公司的电话骚扰（他们的话术很吓人，客户听了以后会害怕地找我，这就很让我烦心了）。
因为遗留的都是企业官网，很少人会登陆更新内容，所以很久以后，客户才来联系我说后台登陆不上了。我一试，发现出现了 403 错误：
禁止访问 (403)
CSRF验证失败. 请求被中断.
您看到此消息是由于HTTPS站点需要浏览器发送 'Referer HTTP头'，但是目前没有被发送。出于安全考虑，浏览器必须发送该HTTP头，以确保您的浏览器没有被第三方劫持。
如果您已经设置浏览器禁用 'Referer' 头，请重新启用，至少针对这个站点，全部HTTPS请求，或者同源请求（same-origin）启用发送该HTTP头。
更多信息请设置选项DEBUG＝True。
探索
奇哉！我记得我们的Django项目一直是有做 CSRF 验证的。但不管三七二十一，先爬上服务器看看。配置文件里的corsheaders.middleware.CorsMiddleware和corsheaders都好好地躺在MIDDLEWARE和INSTALLED_APPS配置项里。
重新看出错信息，有一段如果您已经设置浏览器禁用 'Referer' 头，请重新启用，这很是奇怪。都不知道浏览器还能禁用 Referer 头，搜索也找不到相关配置。搞得一头雾水，好不头大！
复制CSRF验证失败. 请求被中断.去搜索，也是一些关于开启Cookies和需要在form表单中增加{% csrf_token %}字段之类的常规方法，根据没有和Referer HTTP头 相关的片段，而这些提及的方向我们都已经做好了。
端倪
看来只能使用找Bug的根本大法：看源代码了。打开目录发现重载了页码模板，打开页面模板搜索referer关键字，并无收获。再仔细看，发现还重载了base.html这个基础页面，再找开就发现里面有一行：
html
<meta name="referrer" content="never">一看这行，就知道是控制了当发送 HTTP 请求的时候，不要发送Referer头了！
把这一行去掉，再测试，果然解决问题。然后查阅参考文档，发现这个 meta 项的默认值是：strict-origin-when-cross-origin，于是重新改回：
html
<meta name="referrer" content="strict-origin-when-cross-origin">测试可用，提交代码。收工。
小结
不知道为什么会出现这样的错误，想来可能是之前的同事从别处直接复制了一个文件，遗留了快十年吧。估计也不会有其他人遇到同样的情况，在此记之以自娱矣。