複数のサブドメインでDjangoセッションを共有する際の短所

Question

私はSites Frameworkを使用してDjangoサイトを構築し、異なるサブドメインに4つのサイトを持っています。それらをone.mydomain.comと呼ぶことができます。 two.mydomain.com ...など

3つのサイトは製品サイトであり、1つはストアです。サイト間でセッションを共有できるようにするため、ユーザーはいずれかの製品サイトから店舗に移動するときに再度ログインする必要はありません。私はcasを使用してシングルログインを実現することができたことは分かっていますが、それは私の目的をすべて満たしているとは思いません。

サブドメイン間でセッションを共有するとthis postとthis postと表示されていますが、コンセンサスは悪い考えです。

私の場合、ユーザーは1つのサブドメインのカートにアイテムを追加し、カートに進んでチェックアウトすることができます。私はセッションを共有せずにこれを行う方法を見ることができません。ユーザーは別の製品サイトから自分のカートに追加することもできます。チェックアウトすると、one.mydomain.comの製品、two.mydomain.comの製品などが表示されます。

私の質問は、潜在的な葛藤を除いて悪い考えですか？私は、発生する唯一の競合（そして起こるべきである）がユーザーのログイン情報であることを保証していると仮定します。

セットアップでは、すべてのサイトでSECRET_KEYが共有され、SESSION_COOKIE_DOMAIN = '。mydomain.com'が設定されています。この設定で私が見逃す重大なセキュリティ上の欠陥はありますか？あなたは試してみて、サイト間の共有セッション場合は、バグを追跡するためにいくつかの非常に困難を作成することのように私はそれが悪いアイデアと考えられている読んでいる事柄の多くから

Answer 1

./w

おかげで、それはそうです。私が知る限り、ステートレスなものを可能な限り作成す​​る方が一般的には良いです。

Answer 2

特定のドメインのすべてのサブドメインを制御しない場合は、セキュリティ上の欠陥と思われます。たとえば、one.mydomain.comとtwo.mydomain.comがありますが、設定にSESSION_COOKIE_DOMAIN = '。mydomain.com'が設定されているため、ブラウザはbad.mydomain.comというウェブサイトにもCookieを渡します。

開発環境をサブドメインの1つ（例：dev.mydomain.com）にしておくと、もう一つの潜在的な問題が発生します。その場合、あなたは孤立しません。

私が主題を研究している限り、最悪の場合のシナリオは不正なサブドメインにあなたのクッキーを与えるので、潜在的に誰かがこのクッキーを使用して実際のセッションをハイジャックする可能性があります。

この時点で私は別のサブドメイン（Djangoの同じインスタンスによって制御される）をより良い方法で分離する方法をさらに研究していますが、SessionMiddlewareを書き換えることを除いてこれを行う本当の方法はないようです。