3

MediaWiki wiki と Roundup バグトラッカーを使用して、Django で作成されたアプリケーションの中央ログイン システムに取り組んでいます。現在考えている方法は、Mediawiki の AuthDjango 拡張機能 (https://bitbucket.org/toml/django-mediawiki-authentication/src) を使用し、Roundup に似たものをハックすることです。このメソッドは、セッション ID (Cookie から取得) を User インスタンスにマップする Django での SessionProfile モデルの作成に依存しており、MediaWiki/Roundup は Django データベースに直接クエリを実行してデータにアクセスします。

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

私の質問は、これらのシステムのログイン メカニズムを統合するためのより良い方法を知っている人はいますか? または、MediaWiki シェルにアクセスできる人々による悪用の可能性を最小限に抑えながら、MediaWiki/Roundup に Django データベースへの安全なアクセスを与えるにはどうすればよいでしょうか?

4

1 に答える 1

2

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

次に、Mediawiki と Roundup は、HTTP(S) 呼び出しを介して Django アプリ (ロックダウンできます。たとえば、3 つのアプリすべてが同じサーバー上で実行されている場合にのみ内部的にアクセスできます) に接続して、どのユーザーが関連付けられているかを確認します。特定のセッション。

さらに良いことに、ユーザーを Django アプリにリダイレクトして、ログインおよびログアウト機能を実行します。そうすれば、Mediawiki と Roundup はユーザー資格情報にまったくアクセスできなくなります。有効なセッション ID を提供した場合にのみ、ユーザー情報を取得できます。

于 2011-02-03T23:46:46.733 に答える