Django-guardian: user.has_perm（ "perm"、obj）が予期しない動作をする

もう少し掘り下げてみると、各パーミッションバックエンドは独立して機能するはずなので、上記のような状況はないはずです。 しかし、何らかの理由でオブジェクトインスタンスを提供するuser.has_permを呼び出すと、オブジェクトレベルのアクセス許可のみがチェックされ、グローバルアクセス許可のチェックがスキップされます。 その振る舞いの理由は何なのか、私にはわかりません。 私はDjango1.2.5を使用しています。

ねえ、_AUTHENTICATION_BACKENDS_設定を貼り付けることができますか？

Djangoのドキュメントをすでに読んでいるので、指定されたバックエンドの順序が重要であることをご存知でしょう。

アプリケーションに次のようなものがあると思います。

AUTHENTICATION_BACKENDS = (
    'guardian.backends.ObjectPermissionBackend',
    'django.contrib.auth.backends.ModelBackend',
)

またはこれ：

from django.conf import global_settings
AUTHENTICATION_BACKENDS = (
    'guardian.backends.ObjectPermissionBackend',
) + global_settings.AUTHENTICATION_BACKENDS

デフォルトのバックエンドが最初に指定されていることを確認してください。

これが問題であることを確認できますか？ そうでない場合は、さらに情報を追加してください（おそらく、他のバックエンドも使用するか、_User.has_perm_メソッドを使用する他のアプリモンキーパッチを使用しますか？）。

わかりました、私はあまりにも疲れているようです。 順序は_has_perm_の結果に影響を与えないようにする必要があります。 したがって、使用しているアプリケーション設定に関する詳細情報を追加してください。 さらに、テストスイート（_python manage.py test guardian_）を実行することで、保護者が正しく機能することを確認できます。

ああ、わかりました、私はあなたの問題をもう一度読みました。 デフォルトの_auth.ModelBackend_は_supports_object_permissions_をサポートしていません（その属性は_False_です）。 Djangoのドキュメントによると、1.4からデフォルトのバックエンドのサポートが追加されます。

したがって、あなたの状況では、行動は絶対的に正しく、期待されています。 デフォルトのバックエンドは単に省略されています。

アプリでオブジェクトレベルの権限を確認する前に、グローバル権限を確認する必要があります。 それは私が考えることができる最も簡単な解決策です。

_invalid_として終了しますが、新しいコメントで再度開きたい場合は、お気軽に行ってください。

わかりました、あなたが正しいように見えます。 しかし、グローバル権限をチェックしないと、私にとって深刻な問題が発生します。 たとえば、 guardian.decorators.permission_requiredの場合、これは、私が想定したように、追加のオブジェクトレベルのアクセス許可チェックを使用して、通常のdjango.contrib.auth.decorators.permission_requiredの機能を拡張する必要があります。
問題は、グローバルパーミッションを使用する実用的なアプリケーションがあり、それにオブジェクトレベルのパーミッションを追加したかったので、デフォルトのpermission_requiredデコレータをdjango-guardianからオブジェクトレベルのデコレータに変更したことです。その後、ユーザーはグローバル権限に基づくアクセス権を失いました。

私には予期しない動作のように見えますが、コードを調べないと明らかではないため、少なくともこのケースをドキュメントに追加してください。

私の場合、これは設計上の欠陥であり、コード全体で余分なチェックが行われ、グローバルとオブジェクトごとの両方でアクセス許可を確認する必要があります。

@コアギュラント：Djangoの認証から実際にデコレータを_拡張_することは柔軟ではありません。 このアプリは、元の権限を拡張するのではなく、_オブジェクトの権限_を実装することを目的としています。 つまり、保護者とオブジェクトレベルの権限のみを使用する他のアプリを使用したい場合はどうなりますか？ 管理者のみでグローバル権限を使用し、通常のユーザーに付与されるアプリでオブジェクトレベルの権限を使用する場合はどうなりますか？ ユーザーがオブジェクトに対して何らかのアクションを実行できるようにするために、アプリがグローバル権限とオブジェクトレベルの権限の両方を必要とする場合はどうなりますか？ 多くの場合、保護者はそれらすべてをカバーすることはありません。

一方、この特定のユースケースは他のユースケースよりも一般的である可能性があることを認めることができます。 これに興味のある人は、要件を指定して別の問題を提出してください。 これは、バックワードの非互換性なしに、つまり新しい構成設定を使用して簡単に実現できると思います。

オブジェクトレベルのパーミッションとグローバルパーミッションの両方をチェックするpermission_requiredデコレータがもう1つ追加された場合は、私にとって便利です。 それは私の問題をカバーするでしょう。

@Dzejkob 、最後のコミットをチェックして、これで十分かどうかを教えてください（グローバル権限を受け入れるためのフラグを追加しました）。 また、デコレータ自体でdocstringを拡張するだけで十分かどうか、またはより多くの例/より説明的なドキュメントを追加する必要があるかどうかを教えてください。

注：コミットは新しいブランチにあります：_feature / add-accept_global_perms-flag-for-decorators_

@lukaszbはい、プロジェクトにGuardianの新しいブランチバージョンをインストールし、 permission_requiredデコレータaccept_global_perms=Trueにパラメータを追加しましたが、正常に機能しているようです。 この機能を作成していただきありがとうございます。 トランクにマージするのは良い考えだと思います。
ドキュメントについては、私には非常に明確なので、それで十分だと思います。

これはずっと前に修正されました。

こんにちは、私はjango-guardianを試しているときにこの問題を見つけましたが、この動作はバグが多く、非常に混乱していることがわかりました。

ユーザーにグローバル権限（ view_userと呼びましょう）を追加し（ joeと呼びましょう）、Joeが特定のユーザーを表示できるかどうかを確認しました（ other_userと呼びましょう）。 ）そして驚くべきことにそれはFalseを返しました。

joe = User.objects.get(username="joe")
other_user = User.objects.get(username="other_user")
assign_perm("myapp.view_user", joe)
joe.has_perm("myapp.view_user") # True as expected
joe.has_perm("myapp.view_user", other_user) # False, whaaaat?

REST_FRAMEWORK/DEFAULT_PERMISSION_CLASSESとAUTHENTICATION_BACKENDSがsettings.pyにあるため、ビューセットが権限を「自動的に」チェックしているため、 permission_requiredデコレータを明示的に使用していません。 。 その場合、保護者に期待どおりに動作するように指示するにはどうすればよいですか？

（私が本当に愚かな何かを見逃している場合はお詫びします、これはジャンゴランドの2/3日目のようなものです）

今日の騒ぎで申し訳ありませんが、 guardian.shortcuts.get_objects_for_user()がデフォルトでauth / global権限（ accept_global_perms ）を尊重することはさらに興味深い/混乱を招きます。

accept_global_perms: if True takes global permissions into account. 
[...]
Default is True.

この問題は別の問題を優先してクローズされましたが、ここには多くの洞察があるので、会話を再びかき立てるためにここに書いています。 PythonのZenは次のように述べています。

それを行うための明白な方法は1つ、できれば1つだけである必要があります。

そして私にとって、それは_ローカル（オブジェクトレベル）が指定されていないときにグローバルにフォールバックすることです_。 順序によって結果が変わることはありませんが（Django returns False if obj is not None以降）、パフォーマンスが変わる可能性があります。

私は、コード全体をダブルチェックすることは良い設計ではなく、ある意味でDRYの原則にも反することに同意します。 ただし、Djangoのデフォルトのバックエンド内で利用可能なガーディアン実装機能もDRYではありません。 そのDjangoは複数のバックエンドを許可し、順番に1つずつチェックすることは、バックエンドが互いに置き換えられるのではなく、一緒に再生されることになっていることを示しています。 これが正しければ、 obj is not Noneが_間違っている_場合、Djangoはグローバルのチェックを拒否します。 Djangoがobjを無視した場合、それはオブジェクトチェッカーのグローバルフォールバックである可能性があります。

Djangoでチケットを開き、承認バックエンドが相互に連携するかどうか、またどのように連携するかを尋ねてから、そこから進む必要があると思います。

そうは言っても、Djangoがその動作を変更する可能性は非常に低いと思います（私はまだ尋ねるべきだと思いますが）ので、現状は、ガーディアンがどちらを望むかに応じて両方を提供できるように進化する必要があることを示しています（設定または関数の引数を介して設定できます）。 しかし、私が思うデフォルトの動作は、全面的にfalseの場合の_ローカルからグローバルへのフォールバックです。

Djangoがトライステートパーミッションシステム（True、False、None）を好むなら、私はむしろそれが好きです。 その場合、ローカルチェッカーはFalseを介してグローバルを_オーバーライド_できます。 そして、 Noneを介して、各バックエンドは「わかりません。次の行に質問してください」と言うことができます。 その場合、Djangoはバックエンドの1つでTrue or Falseを取得した後、チェックを停止し、処理能力の浪費を停止します。

これにより、各バックエンドにより多くの力が与えられます。決定的な答えを与えたり、他の人を参照したりできます。

@doganmeh Djangoは、トライステート権限システムを実装しています（少なくとも1.10以降）。 オプションは、True、None、およびPermissionDeniedの発生です。 後で実行すると、Djangoはチェックを停止し、Falseを返します。

当面の問題については、Contrib.Authの問題だと思います。 これは、「グローバル権限」を処理するバックエンドです。 問題は、obj = Noneのhas_permが「テーブルのアクセス許可」のみをチェックし、objのhas_permが「行のアクセス許可」のみをチェックするという間接的な規則を確立していることです。 彼らがそれを変更する可能性は低いですが、両方のチェックをサポートするためにAPIを拡張することを受け入れる必要があります。

（少なくとも、両方をチェックするための動作を追加することを受け入れてくれることを願っています。彼らのシステムには明らかな欠陥があるようです。）

「両方をチェックする」APIについてのあなたの提案は何ですか？ 私が考えることができる最高のものはkwargです。

私は、PermissionテーブルにNullBooleanFieldがある明示的なトライステートシステムについて話していました。 確かに、 Trueの欠如（または許可の欠如）をNoneと見なすと、トライステートと見なされる可能性があります。 その場合、保護者によって指定されていない権限はNoneと見なされ、決定はグローバルに委任される必要があります。 ただし、選択肢があれば、明示的なデザインを採用します。

@airstandley次のようにuser.has_permにkwargを追加することを意味していると思います。

def has_perm(self, perm, obj=None, fallback=False)

それが役立つと思います。 fallback=Trueの場合、保護者はDjangoバックエンドを呼び出してグローバルを返します。 ただし、選択肢があれば、Djangoへのフォールバックは、内部を乗っ取るのではなく、フレームワークによって自然に処理されることを望んでいます。

@doganmeh申し訳ありませんが、私はミスポークしました。 「True、 False 、およびPermissionDeniedの発生」と読む必要があります。 いいえ：

オプションは、True、None、およびPermissionDeniedの発生です。

後者は私の頭の中のリターンについてどう思うかです...

私もあなたが意味することを誤解したかもしれないと思います

Djangoがトライステート許可システムを好むなら、私はむしろそれが好きです

明確にするために、システム全体ではなく、パーミッションモデルの実装について具体的に話していましたか？

私のポイントは、認証バックエンドシステムがあなたが説明した正確なショートカットを許可するということでした（少なくともhas_perm 、 has_module_perms apiについて）。 単純ではないにしても、それは明白です。
すべてのバックエンドは、それ自体で決定を行う（TrueまたはPermissionDeniedを返す）か、チェーン内の次のバックエンドに決定を委任する（Falseを返す）ことができます。 これは実装固有の決定であり、システム自体の品質ではありません。

明示的なObjectPermissionBackendは私のプロジェクトの問題になるため、明示的にしないことを選択します。 （「明示性」は、他のパーミッションチェックバックエンドとの統合を面倒にします。）あなたのように、他の人はそれが明示的であることを好むと思います。 したがって、設定として「明示性」を持つことは私には理にかなっています。

@doganmeh
それで、クワーグについて。

まず最初に、authのバックエンドシステムの動作がどのように機能することを意図していたかについて、私たちが同じページにいないことを心配し続けます。 明確にするために：
私の理解では、バックエンドが連携することが意図されていました。 アプリがauthのパーミッションシステム（つまり、「グローバルパーミッション」、技術的には「テーブルパーミッション」であるが、potatoe、potato）を使用したい場合は、authModelBackendをAUTH_BACKENDSにインストールします。 そのアプリが保護者のObjectPermissionシステム（つまり「行のアクセス許可」）を使用したい場合、AUTH_BACKENDSに保護者のObjectPermissionBackendはありません。
ModelBackendはグローバル権限を処理します。
ObjectPermissionBackendは、オブジェクトのアクセス許可を処理します。
ユーザーがオブジェクト権限しか持っていない場合、ModelBackendはhas_permに対してTrueを返すことはありません。 ユーザーがグローバル権限しか持っていない場合、ObjectPermissionBackendはhas_permに対してTrueを返すことはありません。 どちらの場合も、user.has_perm（perm、obj）の呼び出しはtrueを返す必要があります。これは、ユーザーがインストールされたバックエンドの_one_に対する権限を持っているためです。 （これは、ModelBackendがこのアカウントで失敗したために問題が発生したためです）

さて、それをすべて与えてください。

互換性が問題にならない理想的な世界では、私もcontrib.authのModelBackendに単純な変更を加えることを好みます。 ModelBackend.has_perm(user_obj, perm, obj=None)は、ユーザーがpermで指定された「グローバル権限」を持っている場合にTrueを返す必要があります。 objがNoneであるかどうかに関係なく。

ただし、互換性が問題であるため、問題の解決策があるかどうかを尋ねます。

私が考えることができる唯一の_下位互換性のある_ソリューションは、APIにkwargを追加するか、AUTH設定を追加することです。

だからkwargs：
それをobj_shortcutと呼びましょう。それは、頭のてっぺんから思いつくことができる最高のものだからです。 object_shortcutはデフォルトでTrueになります。 object_shortcutがTrueの場合、バックエンドはModelBackendと同じように動作する必要があります。objがNoneの場合、バックエンドは「テーブル/グローバル」権限を_only_チェックする必要があります。それ以外の場合は、「行/オブジェクト」権限を_only_チェックする必要があります。 ただし、 object_shortcutがFalseの場合、バックエンドは両方が好むように動作する必要があります。オブジェクトがNoneでない場合、バックエンドはグローバル権限とオブジェクト権限の両方をチェックします。 そうすれば、Guardianのようなアドオンは、デフォルトとしてobject_shortcut=Falseを使用したhas_permメソッドのミックスインを常に提供できます。 user.has_perm(perm, obj, object_shortcut=False)は、permで表されるパーミッションがUserに割り当てられている場合、正しくTrueを返しますが、 user.has_perm(perm, obj)へのレガシー呼び出しは引き続きFalseを返します。

設定は同じ結果になりますが、基本的にはModelBackend._get_permissionsに切り替わります。

if not user_obj.is_active or user_obj.is_anonymous or obj is not None:
    return set()

次のようになります：

if not user_obj.is_active or user_obj.is_anonymous or (obj is not None and legacy_behaviour_setting_is _on):
    return set()

どちらが良いかわからない。 設定はよりクリーンだと思いますが、Djangoの開発者はそれを決定する資格があると確信しています。

ポイントは、問題を修正できることです。この問題は、GuardianではなくDjangoのバグであると強く信じています。

@airstandleyそうです、 FalseまたはNoneは関係ありません。 どちらも私にはわからないという意味です。 最終的に誰も知らない場合、許可は与えられません。

私は一般的にあなたと同じページにいますが、djangoがバックエンドを何らかの方法で動作させるように強制すると、緩い結合性が低下するようです。 各バックエンドが仕事を遂行するために必要な情報を取得できるようにするメカニズムが必要だと思います。 私はキーワードの議論についてあなたと一緒にいますが、何らかの方法で強制するだけではありません。

この会話は時間の無駄のように思えますが、保護者に許可が与えられていないことは否定ではなく、単に情報が不足していることを私自身に明確にするのに役立ちました。

とにかく、プルリクエスト＃546をしました。 ぜひチェックして、感想を聞かせてください。

私はdjangoでチケットを作成しました： https ：//code.djangoproject.com/ticket/29012、そして彼らは何と言うだろうかと思います。

djangoには他にもいくつかのチケットがあったようです： https ：//code.djangoproject.com/ticket/20218

私は私のものを閉じました。

@doganmeh
私はあなたが＃546に向かっている方向が好きです。 それが助けになるなら、私は残りのユニットを調べて、今週末にこれらのフォールバックのためにいくつかのテストを書く時間があるはずです。

接線上。 「Djangoのバックエンドの強制」についてのあなたのコメントは、私を混乱させますが、それはまた私に考えを与えました。 バックエンドは好きなように動作できます。 GuardianのObjectPermissionBackendに関する最初の懸念は、AuthのModelBackendと一緒に実行するように設計されていることを示唆するドキュメントに由来しています。 Guardianは、複数のバックエンドを提供できます。1つはModelBackendで動作するように設計されており、もう1つは単独で動作するように設計されています。 （つまり、1つはGuardianのUserObjectPermission / GroupObjectPermissionテーブルをチェックするだけで、もう1つはUserObjectPermission / GroupObjectPermissionテーブルとAuthのPermissionテーブルの両方をチェックします。）
個人的には、設定とkwargsを使用した現在のアプローチを好みます。 マルチバックエンドアプローチの主な欠点は、ショートカットと便利な関数がどのように動作するかが不明確になることだと思います。

Djangodevメーリングリストへの投稿を見ました。 彼らがそれを受け入れるか、互換性のない方法で動作を変更することに同意することを願っています。 APIの現在の制限は、不格好です。

そこでサポートしてもらえますか？ 😊

Mail for Windows10から送信

差出人：airstandley
送信日：2018年1月12日金曜日12:06 PM
宛先：django-guardian / django-guardian
Cc：Mehmet Dogan; 言及
件名：Re：[django-guardian / django-guardian] user.has_perm（ "perm"、obj）が予期しない動作をする（＃49）

Djangodevメーリングリストへの投稿を見ました。 彼らがそれを受け入れるか、互換性のない方法で動作を変更することに同意することを願っています。 APIの現在の制限は、不格好です。
—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示するか、スレッドをミュートしてください。

この問題に約1週間対処した後、各バックエンドが1つのこと、つまりGuardianのオブジェクト権限を実行するだけでよいと確信するようになりました。 そのためには、Djangoはobjをより適切に処理する必要があります。

そのためにDjangoに送信したパッチがあります： https ：//github.com/django/django/pull/9581（可能であればコメントしてください）。 それを実現するものは、Guardianにあるところならどこでもモデル権限の取得をクリーンアップし、デフォルトのバックエンドを呼び出すだけです。