python – 在多个子域上共享Django会话的缺点

概述我使用Sites Framework构建了一个Django站点,并在不同的子域上有四个站点.让我们称之为one.mydomain.com; two.mydomain.com …等 其中三个网站是产品网站,一个是商店.我希望能够跨站点共享会话,以便用户在从任何产品站点移动到商店时不必再次登录.我意识到我可以使用cas来实现单一登录,但我不认为这符合我的所有目的. 我已经阅读了关于子域共享会话的thi 我使用Sites Framework构建了一个Django站点,并在不同的子域上有四个站点.让我们称之为one.mydomain.com; two.mydomain.com …等

其中三个网站是产品网站,一个是商店.我希望能够跨站点共享会话,以便用户在从任何产品站点移动到商店时不必再次登录.我意识到我可以使用cas来实现单一登录,但我不认为这符合我的所有目的.

我已经阅读了关于子域共享会话的this post和this post,并且共识似乎是一个坏主意.

在我的情况下,我希望用户能够将项目添加到一个子域中的购物车,然后前往购物车结帐.没有共享会话,我无法看到这样做的方法.用户还应该能够从其他产品站点添加到他们的购物车中,当退房时会看到来自one.mydomain.com的产品,来自two.mydomain.com等的产品.

所以我的问题是为什么除了潜在的冲突之外,分享会议是一个坏主意？假设我确保发生(并且应该发生)的唯一冲突是用户登录信息.

我的设置为所有网站共享了SECRET_KEY,并且SESSION_cookie_DOMAIN =’.mydomain.com’.这个设置是否存在严重的安全缺陷？

谢谢./w

解决方法 在我看来,当你不控制特定域的所有子域时,这是一个安全漏洞.例如,您有one.mydomain.com和two.mydomain.com,但浏览器会将您的cookie也提供给名为bad.mydomain.com的网站,因为您的设置有SESSION_cookie_DOMAIN =’.mydomain.com’.

如果将开发环境保留为子域之一(例如dev.mydomain.com),则会发生另一个潜在的漏洞.如果是这样的话,你就不会被孤立.

就我研究过的主题而言,似乎最坏的情况会将你的cookie发给流氓子域,所以有人可能会使用这个cookie劫持一个真正的会话.

此时我正在进一步研究如何以更好的方式隔离不同的子域(由相同的Django实例控制),但似乎除了重写SessionMIDdleware之外没有真正的方法.

总结

以上是内存溢出为你收集整理的python – 在多个子域上共享Django会话的缺点全部内容，希望文章能够帮你解决python – 在多个子域上共享Django会话的缺点所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。