本文介绍了Django SECRET_KEY是按实例还是按应用?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

此问题询问有关Django SECRET_KEY 值的用途.该问题的答案之一指出:它需要具有大量密码学上的Entopy(sp)(对于计算机来说很难做到)猜测),并且在所有Django实例之间都是唯一的."

This question asks about the purpose of the Django SECRET_KEY value. One of the answers to that question stated "It needs to have a cryptographically strong amount of entopy(sp) (hard for computers to guess) and unique between all Django instances."

这有点模棱两可:例如,如果我说有一个Django应用程序部署到负载均衡器后面的多个Web服务器上,则每个应用程序都应具有自己的独特 SECRET_KEY ,或者可以在所有实例之间共享SECRET_KEY 吗?

This is a bit ambiguous: if I say for example have a single Django application deployed to multiple web servers behind a load balancer, should each have it's own distinct SECRET_KEY, or should the SECRET_KEY be shared amongst all instances?

推荐答案

对于同一个Django应用程序,您应该使用相同的 secret key ,以确保在加载时相同的客户端可以正确使用该服务余额会在会话中重定向他/她的流量.否则,肯定会出现不确定的行为.更具体地说,所有这些东西都会破坏.

For the same Django application you should use the same secret key to ensure that the same client can properly use the service if the load balance redirects his/her traffic mid session. Otherwise, surely undefined behavior will arise. More specifically, all these things would break.

  • 会话,数据解码将中断,这对于任何会话后端(cookie,数据库,基于文件或缓存)均有效.
  • 已发送的密码重置令牌将不起作用,用户将不得不询问一个新的密码.
  • 注释表单(如果使用django.contrib.comments)将无法验证它是否在值更改之前被请求并在值更改之后被提交.我认为这是次要的,但可能会使用户感到困惑.
  • 消息(来自django.contrib.messages)不会在与注释表单相同的计时条件下验证服务器端.

来源.附带说明一下,我完全同意Django的 secret_key 方面是危险而神秘的,尽管这是非常容易解释的,并且文档也没有对其进行任何明确的说明.

source. As a side note, I completely agree that the secret_key aspect of Django feels dangerous and mystic, despite it being very explainable, and is not treated by the documentation with any sort of clarity.

这篇关于Django SECRET_KEY是按实例还是按应用?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

07-30 00:14
查看更多