Django-guardian: user.has_perm("perm", obj)이 예기치 않게 작동합니다.

조금 더 파고들어보니 각 권한 백엔드가 독립적으로 작동해야 하므로 위에서 설명한 것과 같은 상황이 발생해서는 안 됩니다. 그러나 어떤 이유로 개체 인스턴스를 제공하는 user.has_perm 를 호출하면 개체 수준 권한만 확인하고 전역 권한 확인은 건너뜁니다. 그 행동의 이유가 무엇인지 모르겠습니다. 저는 Django 1.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의 개체 수준 데코레이터로 변경했지만 그런 다음 사용자는 전역 권한을 기반으로 액세스 권한을 잃었습니다.

나에게 예기치 않은 동작처럼 보입니다. 코드를 살펴보지 않고는 명확하지 않기 때문에 최소한 이 경우를 문서에 추가해 주시겠습니까?

저에게 이것은 설계 결함으로 인해 전역 및 개체별 권한을 모두 확인해야 하는 코드 전체에 대해 추가 검사가 필요합니다.

@coagulant : 실제로 Django의 인증에서 데코레이터를 _확장_하는 것은 유연하지 않을 것입니다. 이 앱은 원래 권한을 확장하지 않고 _객체 권한_을 구현하려고 합니다. 예를 들어 보호자 및 개체 수준 권한만 사용하는 다른 앱을 사용하려면 어떻게 해야 합니까? admin에서만 전역 권한을 사용하고 일반 사용자에게 부여된 앱에서는 개체 수준 권한을 사용하려면 어떻게 해야 합니까? 앱이 사용자가 개체에 대해 일부 작업을 수행할 수 있도록 전역 권한 과 개체 수준 권한을 모두 요구한다면 어떻게 될까요? 많은 경우가 있으며 보호자가 모든 경우를 다루지는 않습니다.

반면에 이 특정 사용 사례가 다른 사례보다 더 일반적일 수 있음을 인정할 수 있습니다. 이에 관심이 있는 사람은 요구 사항을 지정하는 다른 문제를 제출하십시오. 나는 이것이 백워드 비호환성 없이, 즉 새로운 구성 설정으로 쉽게 달성될 수 있다고 믿습니다.

객체 수준 권한과 전역 권한을 모두 확인하는 또 다른 permission_required 데코레이터가 추가되면 나에게 유용할 것입니다. 그것은 내 문제를 다룰 것입니다.

@Dzejkob , 마지막 커밋을 확인하고 이것이 충분한지 말해 주시겠습니까(전역 권한 수락을 위한 플래그를 추가했습니다). 또한 데코레이터 자체에서 독스트링을 확장하는 것으로 충분한지 알려주십시오. 아니면 더 많은 예제/설명적인 문서를 추가해야 합니까?

참고: 커밋은 새 분기: _feature/add-accept_global_perms-flag-for-decorators_에 있습니다.

@lukaszb 예, 내 프로젝트에 Guardian의 새 분기 버전을 설치하고 permission_required decorators 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?

이제 $#$ settings.py $#$의 REST_FRAMEWORK/DEFAULT_PERMISSION_CLASSES 및 AUTHENTICATION_BACKENDS 때문에 뷰 세트가 "자동으로" 권한을 확인하므로 permission_required 데코레이터를 명시적으로 사용하지 않습니다. . 그러면 보호자에게 예상대로 행동하도록 어떻게 말합니까?

(정말 어리석은 것을 놓치면 사과드립니다. 이것은 djangoland에서 일종의 2/3일입니다)

오늘 소란을 일으켜 죄송합니다 guardian.shortcuts.get_objects_for_user() 가 기본적으로 인증/전역 권한을 존중한다는 점이 훨씬 더 흥미롭고/혼란스럽습니다( accept_global_perms ).

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

비록 이 문제가 다른 문제로 인해 종료되었지만 여기에는 많은 통찰력이 있으므로 대화를 다시 일으키기 위해 여기에 씁니다. Python의 Zen은 다음과 같이 말합니다.

이를 수행하는 확실한 방법이 하나 있어야 합니다.

그리고 나에게 그것은 _로컬(객체 수준)이 지정되지 않았을 때 전역으로 대체하는 것입니다_. 순서는 결과를 변경하지 않지만(Django returns False if obj is not None 이후) 성능을 변경할 수 있습니다.

코드 전체에 대해 이중 확인을 하는 것은 좋은 디자인이 아니며 어떤 의미에서는 DRY 원칙에도 어긋난다는 데 동의합니다. 그러나 Django 기본 백엔드 내에서 사용할 수 있는 기능을 구현하는 보호자도 DRY가 아닙니다. Django는 여러 백엔드를 허용하고 순서대로 하나씩 확인하면 백엔드가 서로를 대체하지 않고 함께 재생되어야 함을 나타냅니다. 이것이 맞다면 Django는 obj is not None 가 _wrong_일 때 전역 검사를 거부합니다. Django가 obj 를 무시했다면 객체 검사기에 대한 전역 대체가 될 수 있습니다.

나는 우리가 Django로 티켓을 열어 인증 백엔드가 서로 어떻게 작동하는지 묻고 거기에서 가야 한다고 생각합니다.

즉, Django가 동작을 변경하는 것은 거의 불가능하다고 생각하므로(여전히 물어봐야 한다고 생각하지만) 현상 유지는 가디언이 원하는 것에 따라 두 가지를 모두 제공할 수 있도록 진화해야 함을 나타냅니다. 설정이나 함수에 대한 인수를 통해 설정될 수 있음). 그러나 기본 동작은 보드 전체에서 false_일 때 _local fallback to global이어야 한다고 생각합니다.

Django가 True, False 및 None의 3가지 상태 권한 시스템을 선호한다면 더 좋아할 것입니다. 이 경우 로컬 검사기는 False 를 통해 전역을 _재정의_할 수 있습니다. None 를 통해 각 백엔드는 "모르겠습니다. 다음 줄에 물어보세요"라고 말할 수 있습니다. 이 경우 Django는 백엔드 중 하나에서 True or False 를 얻은 후 확인을 중지하고 처리 능력 낭비를 중지합니다.

이렇게 하면 각 백엔드에 더 많은 권한이 부여됩니다. 최종 답변을 제공하거나 다른 사람을 참조할 수 있습니다.

@doganmeh Django는 tri-state 권한 시스템을 구현합니다(최소 1.10 이상). 옵션은 True, None 및 PermissionDenied 올리기입니다. 나중에 수행하면 Django가 검사를 중지하고 False를 반환합니다.

당면한 문제는 Contrib.Auth 문제라고 생각합니다. 그것이 '전역 권한'을 다루는 백엔드입니다. 문제는 obj=None이 있는 has_perm이 '테이블 권한'만 확인하고 obj가 있는 has_perm이 '행 권한'만 확인하는 간접 규칙을 설정했다는 것입니다. 그들은 그것을 변경할 것 같지 않지만 _should_는 둘 다 확인을 지원하도록 API를 확장할 수 있어야 합니다.

(적어도 나는 그들이 두 가지 모두를 확인하기 위해 행동을 추가할 수 있기를 바랍니다. 그들의 시스템에 명백한 결함이 있는 것 같습니다.)

'둘 다 확인' API에 대한 제안은 무엇입니까? 내가 생각할 수있는 최선은 kwarg입니다.

나는 Permission 테이블에 NullBooleanField가 있는 명시적으로 tristate 시스템에 대해 이야기하고 있었습니다. 사실, 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가 tri-state 권한 시스템을 선호한다면 더 좋아할 것입니다.

명확히 하자면, 시스템 전체가 아니라 구체적으로 권한 모델 구현에 대해 말씀하신 것입니까?

내 요점은 인증 백엔드 시스템이 귀하가 설명한 정확한 바로 가기를 허용한다는 것입니다(적어도 has_perm , has_module_perms api의 경우). 간단하지 않더라도 명시적입니다.
모든 백엔드는 자체적으로 결정을 내리거나(True 또는 PermissionDenied 반환) 결정을 체인의 다음 백업에 위임할 수 있습니다(False 반환). 이는 시스템 자체의 품질이 아니라 구현에 따른 결정입니다.

명시적 ObjectPermissionBackend는 내 프로젝트에 문제가 될 수 있으므로 명시적으로 선택하지 않습니다. ("명시성"은 다른 권한 검사 백엔드와의 통합을 어렵게 만듭니다.) 귀하와 마찬가지로 다른 사람들도 명시적 방식을 선호할 것이라고 생각합니다. 따라서 설정으로 '명확성'을 갖는 것이 나에게 의미가 있습니다.

@doganmeh
그래서 kwarg에 대해.

먼저 인증 백엔드 시스템의 동작이 의도된 방식에 대해 동일한 페이지에 있지 않다는 점에 대해 계속 걱정하고 있습니다. 그래서 명확하게 :
내 이해는 백엔드가 함께 작동하도록 의도했다는 것입니다. 앱이 인증의 권한 시스템(예: '전역 권한', 기술적으로는 '테이블 권한'이지만 감자, 감자)을 사용하려는 경우 AUTH_BACKENDS에 인증 ModelBackend를 설치합니다. 해당 앱이 보호자의 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인지 여부에 관계없이.

그러나 호환성이 문제이므로 문제에 대한 해결책이 있는지 묻습니다.

내가 생각할 수 있는 유일한 _backwards compatible_ 솔루션은 API에 kwarg를 추가하거나 AUTH 설정을 추가하는 것입니다.

그래서 콰르그:
obj_shortcut 라고 부르겠습니다. 그게 제가 생각해낼 수 있는 최선의 방법이기 때문입니다. object_shortcut 는 기본적으로 True로 설정됩니다. object_shortcut 가 True이면 백엔드는 ModelBackend가 지금 하는 것처럼 동작해야 합니다. obj가 None이면 '테이블/전역' 권한을 _만_ 확인해야 하고, 그렇지 않으면 '행/개체' 권한을 _만__ 확인해야 합니다. 그러나 object_shortcut 가 False이면 백엔드는 둘 다 선호하는 대로 동작해야 합니다. 즉, 객체가 None이 아닐 때 전역 및 객체 권한 _모두_를 확인합니다. 그런 다음 Guardian과 같은 추가 기능은 항상 object_shortcut=False 를 기본값으로 사용하여 has_perm 메서드로 믹스인을 제공할 수 있습니다. perm이 나타내는 권한이 사용자에게 할당된 경우 user.has_perm(perm, obj, object_shortcut=False) 는 올바르게 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 forcing backends"에 대한 귀하의 의견은 저를 혼란스럽게 하지만 또한 저에게 생각을 주었습니다. 백엔드는 원하는 대로 작동할 수 있습니다. Guardian의 ObjectPermissionBackend에 대한 나의 초기 우려는 이것이 Auth의 ModelBackend와 함께 실행되도록 설계되었음을 제안하는 문서에서 비롯됩니다. Guardian은 ModelBackend와 함께 작동하도록 설계된 백엔드와 단독으로 작동하도록 설계된 여러 백엔드를 제공할 수 있습니다. (가디언의 UserObjectPermission/GroupObjectPermission 테이블만 확인하는 IE, 다른 하나는 UserObjectPermission/GroupObjectPermission 테이블과 Auth의 권한 테이블을 모두 확인합니다.)
개인적으로 나는 설정과 kwargs가 있는 현재 접근 방식을 선호합니다. 다중 백엔드 접근 방식의 주요 단점은 바로 가기 및 편의 기능이 어떻게 작동해야 하는지가 불분명해진다는 것입니다.

Django dev 메일링 리스트에 대한 게시물을 보았습니다. 나는 그들이 그것을 받아들이거나 양립할 수 없는 방식으로 행동을 바꾸는 데 동의하기를 바랍니다. API에 대한 현재 제한 사항은 투박합니다.

거기에 지원할 수 있습니까? 😊

Windows 10용 메일에서 보냄

보낸사람: 에어스탠들리
보낸 날짜: 2018년 1월 12일 금요일 오후 12:06
받는 사람: django-guardian/django-guardian
참조: Mehmet Dogan; 언급하다
제목: Re: [django-guardian/django-guardian] user.has_perm("perm", obj)이 예기치 않게 작동합니다(#49).

Django dev 메일링 리스트에 대한 게시물을 보았습니다. 나는 그들이 그것을 받아들이거나 양립할 수 없는 방식으로 행동을 바꾸는 데 동의하기를 바랍니다. API에 대한 현재 제한 사항은 투박합니다.
—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 보거나 스레드를 음소거하세요.

약 일주일 동안 이 문제를 처리한 후, 각 백엔드는 Guardian에 대한 개체 권한이라는 한 가지만 수행해야 한다는 것을 더 확고하게 믿게 되었습니다. 그렇게 하려면 Django는 obj 를 더 멋지게 다루어야 합니다.

내가 Django에 보낸 패치가 있습니다: https://github.com/django/django/pull/9581 (가능하면 댓글을 달아주세요). 그것을 만드는 것들, 우리는 Guardian에 있는 모든 곳에서 모델 권한 검색을 정리하고 기본 백엔드를 호출하기만 하면 됩니다.