2011-02-03 3 views
3

私はMediaWiki wikiとRoundup bugtrackerを使って、Djangoで書かれたアプリケーションのセントラルログインシステムに取り組んでいます。現在、私が考えている方法は、Mediawiki(https://bitbucket.org/toml/django-mediawiki-authentication/src)のAuthDjango拡張機能を使って、Roundupと同様のものをハックアップすることです。このメソッドは、セッションID(Cookieから取得)をUserインスタンスにマップするDjangoのSessionProfileモデルの作成に依存し、MediaWiki/RoundupはDjangoデータベースに直接問い合わせてデータにアクセスします。Django、MediaWiki、Roundupのユーザのデータを侵害することなくセントラルログインできますか?

この利点は、3つのアプリケーションすべてのログイン、セッション、およびログアウトプロセスが簡単に統合されることです。しかし、私が持っている問題は、MediaWiki/RoundupがDjangoデータベースの資格情報を保存していることに依存しており、MediaWikiまたはRoundupシェルアカウントにアクセスするための要件は、主なDjangoアプリケーションの場合よりも厳しく制限されています(現在のところ、 Djangoのプロダクションアクセス権を持っています)。そのため、MediaWiki/Roundupインスタンスの管理者(つまりシェルアクセス権を持つ)、またはリモートエクスプロイトで侵入した人は、メインサイトのユーザーアカウントをハイジャックする可能性があります。

私の質問です:これらのシステムのログインメカニズムを統合するより良い方法を知っている人はいますか?またはMediaWikiシェルにアクセスする人の虐待の可能性を最小限に抑えながらMediaWiki/RoundupにDjangoデータベースへの安全なアクセスを与える方法を教えてください。

答えて

2

直接DBアクセスを提供する代わりに、Djangoを使用して、必要なアクション(ログイン、クエリセッションの有効性とユーザーのログアウト)を実行する(JSON/XML/whatever)Webサービスを作成できます。この方法でDjangoはデータベース内のデータを編集することができます。

Mediawikiのとラウンドアップは、その後(すべて3つのアプリケーションが同じサーバ上で実行されている場合、それは内部でのみアクセスすることができます例えば、あなたがロックダウン可能性がある)あなたのDjangoアプリケーションに接続しますHTTP(S)経由では利用者をチェックするために呼び出します特定のセッションに関連付けられています。

さらに、ユーザーをDjangoアプリにリダイレクトして、ログインとログアウト機能を実行してください。そうすれば、MediawikiとRoundupはユーザーの資格情報にアクセスすることは一切できません。ユーザーが有効なセッションIDを入力した場合にのみユーザー情報を取得できます。

+0

お返事ありがとうございます。私たちはログイン時にユーザをDjangoにリダイレクトする最後の提案に似ていますが、ユーザがログインしているかどうかを判断するために、直接DBアクセスルートを使用することにしましたが、厳格なアクセス許可が設定されています。その方法では、そのアカウントを通じてアクセスできる唯一のデータは、サイト上に公開されていたデータでした。 – pythonian4000

関連する問題