2017-02-28 27 views
0

e-health関連サービスのコンテキストでは、同じ物理環境で作業し、バックエンドとやりとりするクライアントPCを1つだけ共有するエンドユーザー(保健担当者、医師、理学療法士)私は、さまざまなアカウント間で素早く切り替えるための仕組みを提供するように頼んだことがあります(LAN内での作業に慣れているためセキュリティはほとんど問題ではありませんが、時にはリモートクライアントから作業する場合もあります。認証/認可バックエンドを適所に置く)。彼らは一度だけログインしてから、Webアプリケーションを使用する前に、ログインしたアカウントをコンボボックス(sort-of)から選択します。Django複数の同時にログインしているアカウント

Gmailモデルでは、複数のログインしているユーザーアカウントを保持し、右上のアカウントセレクタで切り替えることができます。

私はdjango認証の専門家なので、これはdjangoベースのアプリケーションのコンテキストで可能かどうかを知ることさえできません。

誰でも既成のアプリケーション/ミドルウェアを知っていますか?または、既存のコードを拡張または変更する必要がある場合は、正しい方向に私を向けるでしょうか?

ありがとうございます。

答えて

1

私はこのための既存のソリューションを探していないので、これを最初からやり直す方法です。

複数のユーザーを保持するには、ユーザーセッションにストレージを追加する必要があります。現在、それははるかに次のようになります。

{'_auth_user_backend': 'membership.auth_backends.MyCustomAuthenticationBackend', 
'_auth_user_hash': 'e2c8ecf1e7ecdbd<snip>', 
'_auth_user_id': '3806'} 

と私はセッションに配列を追加します。あなたの「スイッチのユーザーは」、そのユーザの認証の詳細を移動するには、セッションオブジェクトを編集するときに(そして、

logged_in_users = [{'_auth_user_backend': ... }, {}, {}] # one auth dict per user 

IDを、ハッシュ、バックエンド)をセッション内のトップレベルのものに変換します。

また、ログインをlogged_in_users arrayに保存するカスタムログイン機能を作成し、current login functionのビットを取り出して、そのキーがログインしている別のユーザーのセッションと同じ場合はセッションをフラッシュします。同様に、あなたはログアウトするときに何が起こるか考える必要があります。

+0

これはかなり意味があります。私は提案されたアプローチに従って、それがうまくいくかどうかを知らせます。どうもありがとう。 – Blazor

+1

私は最初の草案の実装を完了しました。私は、リストの代わりに辞書のキーとなった 'logged_in_users'を除いて、あなたの戦略をかなり採用しました(IDを使って既にログインしているユーザーを探すことができます)。 唯一の明らかな欠点は、あなたが言ったようにセッションをフラッシュするのを防ぐために私がプライベートなdjangoファイル(最後にリンクした '__init __。py')を修正しなければならないということです。私はそのようなアプローチの巨大なファンではないので、私はあなたを受け入れる前にクリーンなソリューションを待つでしょう。 ありがとう、それは本当に素晴らしい答えです。 – Blazor

+0

その変更の良いアイデア、はい、私は完全にはっきりしていませんでした。 'django.contrib.auth'を変更したくない場合(あなたはそうしてはいけません!)、独自のログイン/ログアウト関数を作成する必要があります(既存のものをコピーしてセッションレクリエーションビット)、あなたのビューの代わりに新しい関数を使用してください。これは、すべて再配布可能なアプリにうまく組みこまれます。 – neomanic

関連する問題