SECRET_KEY 到底用来做什么?与其背文档,不如换一次密钥看什么会坏、什么不会。这篇用 override_settings 在同一个项目里切换密钥,逐项验证,并试 SECRET_KEY_FALLBACKS 做平滑轮换。
签名串(前 40 字符): eyJvcmRlciI6N30:1xC3rf:RTxlt1FQSgoBiWAlN…
同一个密钥 A → loads 得到 {'order': 7}
换成密钥 B → BadSignature: Signature "RTxlt1FQSgoBiWAlNaT3SiyQ3KVADU9gtL-dNQY
密钥 B + SECRET_KEY_FALLBACKS=[A] → loads 得到 {'order': 7}Django 的很多功能都建立在 django.core.signing 之上,密钥泄漏就意味着别人能伪造这些签名。
登录(密钥 A): True /who/ → user=ann 换成密钥 B → /who/ → user=anonymous 密钥 B + fallback A → /who/ → user=ann 数据库里的会话行数(换密钥没有删除它们): 1
密钥 A → check_token = True 密钥 B → check_token = False 密钥 B + fallback A → check_token = True
换密钥 B 后用密码登录: True 密钥 A 下拿到的 CSRF 令牌,在密钥 B 下 POST → 200
CSRF 令牌不依赖 SECRET_KEY 这一点,只是在本实验的设置下观察到的。
登录: True 密钥 A:/who/ → user=ann cookie 长度 227 密钥 B:/who/ → user=anonymous 读取空的 SECRET_KEY → ImproperlyConfigured: The SECRET_KEY setting must not be empty.