Django:是否有一种安全可靠的方法来允许帐户持有者在您的应用程序上拥有单独的域?

发布于 2024-08-20 14:56:28 字数 294 浏览 6 评论 0原文

如果我希望我的帐户持有人能够拥有自己的子域,甚至完全拥有自己的域。使用 NGINX 作为我的代理服务器,我应该为我的 NGINX conf 中的每个服务器创建域,并让我的客户将他们的域指向那里,还是有原因导致这种情况不好?另外,如果我这样做,如何将特定于帐户(Django DB 中的帐户)信息与请求一起传递(即从 www.spamfoosaccount.com 到我的服务器的请求,因此我将请求代理回 Apache,但是如何我的应用程序是否知道它来自 spamfoo 的帐户,除非我查看 request.HTTP_HOST (这可能是最好的方法,但在我询问之前我不知道)。

If I want my account holders to be able to have their own sub-domains and even their own domains altogether. Using NGINX as my proxy server, should I create domains for each one in my NGINX conf and have my clients point their domains there or is there reasons why this would be bad? Also, if I do that, how can I pass account-specific (account in Django DB) information in with the request (ie, request from www.spamfoosaccount.com to my server, so I proxy the request back to Apache, but how does my application know that it came from spamfoo's account unless I look at request.HTTP_HOST (which might be the best way, but I don't know until I ask). Thanks in advance.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

硬不硬你别怂 2024-08-27 14:56:28

要了解请求来自哪个域,您必须使用 request.META["HTTP_HOST"]

但是,不要依赖该值进行身份验证,它很容易被伪造。身份验证应使用 django.contrib.session 以通常的方式完成。来自特定域/子域的请求不应拥有更多特权/权利,即使请求包含经过身份验证的会话也是如此。权限应授予用户/用户组,而不是域。

请注意,浏览器会话不能跨二级域(例如,来自 foo.com 的会话 cookie 不会发送到 bar.com),但它可以是所有子域的 *.foo.com cookie(如果您明确设置它) )。

让您的用户将他们的 DNS 记录指向您服务器的 IP,让 NGINX 将基于域的请求路由到您的后端,并在 Django 中进行正常的身份验证。

你的问题:

我的应用程序如何知道它
来自 spamfoo 的帐户

我不知道您的应用程序的具体情况,但请求来自何处并不重要,重要的是谁发出了请求(例如经过身份验证的用户)。您应该有一个模型/字段将您的用户链接到他们各自的域。当用户仅链接到一个域时,应用程序应假设该用户来自该域。当用户连接到多个域时,您可以查看 request.META["HTTP_HOST"]。如果该值与任何域匹配,则用户被链接到,没关系,该值可能是伪造的,但仍然是由链接到该域的用户伪造的。

To know from which domain a request is coming from, you have to use request.META["HTTP_HOST"].

However, do not rely on this value for authentication, it can be forged easily. Authentication should be done in the usual way with django.contrib.session. A request from a specific domain/subdomain should not have more privileges/rights, even when the request contains an authenticated session. Privileges should be given to users/groups of users, not to domains.

Note that browser sessions cannot cross second-level-domains (e.g. session cookie from foo.com wil not be sent to bar.com), it can however be a *.foo.com cookie for all subdomains (if you explicitly set it so).

Let your users point their DNS records to the IP of your server, let NGINX route the request based on the domain to your backend and do normal authentication in Django.

Your question:

how does my application know that it
came from spamfoo's account

I don't know the specifics of your application, but it shouldn't matter where the request came from, but who issued the request (e.g. an authenticated user). You should have a model/field that links your users to their respective domains. When a user is linked to only one domain, the application should assume the user came from that domain. When a user is connected to more than one domain, you can look at request.META["HTTP_HOST"]. If this value matches any of the domains, the user is linked to, it's alright, the value may be forged, but by a user that is linked to that domain nonetheless.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文