7

独自の認証および認可システム (独自のユーザー/権限モデル) を使用しているため、この標準アプリを から完全に無効にしたいと考えていDjangoます。

MIDDLEWARE_CLASSES関連する行をおよび から削除しようとしましたINSTALLED_APPSが、syncdb コマンドを使用すると、デフォルトの認証システムに付属するデフォルトのテーブルがまだ作成されています。これを防ぐ方法はありますか？私の主な問題は、標準テーブルが、自分の認証システムに使用したいテーブルを上書きしていることです。

INSTALLED_APPS = (
    'django.contrib.sessions',
    'form_utils',
    'org',
    'auth',
    'entities',
)

また、アプリの先頭にプロジェクト パッケージを追加しようとしましたが、これは効果がありませんでした。

私が見落としている別の設定はありますか？私の努力にもかかわらず、これらの標準アプリが有効になる可能性のある他の変数はありますか?

また、組み込みの管理システムも使用していないので、それが問題になるとは思いません。

追加情報: 最近、Django 1.2 を 1.3 にアップグレードしました。これが私の問題の原因でしょうか？

編集: どうやら、この問題は Django 1.3 の変更によって引き起こされます。関連するチケットはこちら: http://code.djangoproject.com/ticket/15735

ヒントはありますか？

4

1 に答える 1

6

認証モジュールは RequestContext によって取り込まれていると思います。

デフォルトでは、設定 TEMPLATE_CONTEXT_PROCESSORS には django.contrib.auth.context_processors.auth が含まれています。

djangoが認証データベーステーブルを作成するという問題はありませんでしたが、INSTALLED_APPSおよびMIDDLEWARE_CLASSES設定から認証モジュールを削除したにもかかわらず、AnonymousUserオブジェクトをコンテキストと「ユーザー」キーの下のセッションに挿入していました.

そのアイテムを TEMPLATE_CONTEXT_PROCESSORS から削除すると、期待どおりに機能し始めました。

あなたのケースでの 1.2 から 1.3 へのアップグレードは、クラスベースのジェネリック ビュー (素晴らしい) を使い始めたことを意味するか、通常のコンテキスト dict の代わりに RequestContext を使い始めたことを意味している可能性があります。いずれにせよ、auth がコンテキスト プロセッサとして指定されている場合、django は、実際に auth が必要かどうかに関係なく、インストールされたアプリに auth があるかのように動作するようです。

これがお役に立てば幸いです。

于 2011-11-06T01:30:54.533 に答える