Django-guardian: 역할 추가

+1 하지만 역할은 django로 작성된 대부분의 앱에서 거의 필요하지 않은 것입니다.
가끔 우리 같은 사람이 django가 실제로 만들어지지 않은 앱(사용자 지정 문서 관리 시스템)을 구현하려고 하고, 파마가 많을 때 역할에 대해 생각하기 시작합니다. 역할과 상속 v1.1로 만들어야 하는 두 가지

옵션 부분은 쉽습니다. django를 사용한다고 그룹을 사용하지 않는 것처럼 사람들이 역할을 정의하도록 만들지 마십시오.

thx 앱용 btw.
금연 건강 증진 협회

구현에 따라 역할에 대해 +1.

역할 및 상속에 대해 +1

나는 역할에 대해 "권한 그룹"이라고 생각합니다. 이것이 당신에게도 동일한지 모르겠습니다. 이 역할 클래스를 사용하면 많은 권한을 더 쉽게 할당할 수 있습니다. 한 역할을 다른 역할로 빼거나 교차점 등을 얻기 위해 Python 세트를 사용하여 이것을 구현하는 것이 좋습니다.

http://docs.python.org/library/stdtypes.html#set -types-set-frozenset
http://en.wikibooks.org/wiki/Python_Programming/Sets

역할, 상속 및 선택 사항에 대해 +1

안녕하세요 여러분,
저는 역할 기반 개체 권한이 필요하거나 갖고 싶은 사람 중 한 명입니다.

나는 이 토론에서 아주 좋은 이유로 django-guardian의 우선 순위가 아님을 이해합니다. 그래서 나는 나만의 앱을 만들 것이다. 그러나 django-guardian의 대부분의 기능과 구성 요소는 괜찮다고 생각하며 가능하면 바퀴를 다시 발명하지 않고 재사용하고 싶습니다. 그래서 제 질문은 django-guarding을 조금 더 연결 가능하게 만들 의향이 있는지입니다. 예를 들어(코드를 진행하는 동안 내 마음에 가장 먼저 떠오른 것): ObjectPermissionChecker에 대한 설정을 지정하면 다른 앱이 Checker 클래스를 역할을 처리하는 것으로 대체할 수 있습니까?

여러분은 어떻게 생각하세요?

감사 해요
위르겐

Hej @schacki , 그것은 실제로 꽤 좋은 생각입니다. 테스트는 기본이 아닌 검사기 클래스에 대해 실패할 가능성이 높지만 이를 표시하거나 기본 검사기로만 실행되도록 할 수 있습니다. 특정 작업을 생성할 수 있습니까?

나는 기본이 아닌 검사기 클래스를 django-guardign의 일부가 아니라 "기타" 앱의 일부로 만들 것이므로 기본이 아닌 검사기 클래스에 대한 다른 앱의 작업입니다. 작업을 시작하기 전에 조정 및 변경해야 할 사항에 대한 보다 철저한 분석을 수행하겠습니다. "작업"을 사용하면 별도의 문제를 의미한다고 가정합니까? btw: 이 작업이 진행되기까지 몇 주가 걸릴 수 있습니다.

this[1] 프로젝트에 도움이 되셨나요?

[1] https://github.com/vintasoftware/django-role-permissions

#330에서 @suriya 가 다음 텍스트를 복사했습니다.

지난 #23에서 django-guardian에 역할 지원을 추가하는 것에 대한 논의가 있었습니다. 그러나 멀리 움직이지 않았습니다. 이것은 아마도 django-guardian에 역할을 추가하는 것이 매우 복잡한 작업처럼 보이기 때문일 것입니다.

아주 간단한 제안이 있는 것 같아요. 내세우고 관심이 있다면 시행하고 싶습니다. 현재, 나는 이 기능이 있는 django-guardian의 내 자신의 포크를 가지고 있습니다. 다른 사람들도 이것을 사용하는 것을 보는 것이 좋습니다.

뷰에 대한 django-guardian의 권한 검사의 핵심은 get_403_or_None() 함수에서 구현됩니다. 이 기능은 사용자에게 필요한 모든 권한이 있는지 확인합니다. https://github.com/lukaszb/django-guardian/blob/112c373f213a19d93baa81fa4a941a41333115b5/guardian/utils.py#L98

has_permissions = all(request.user.has_perm(perm, obj) for perm in perms)

지원 역할은 사소한 변경입니다. 사용자에게 all 권한이 있는지 확인하는 대신 사용자가 하나 이상의 권한을 충족하는지 확인하기만 하면 됩니다. 같은 것

if require_all_permissions:
    has_permissions = all(request.user.has_perm(perm, obj) for perm in perms)
else:
    has_permissions = any(request.user.has_perm(perm, obj) for perm in perms)

그것을해야합니다. 이 지원을 추가하려면 get_403_or_None() 에 새 플래그를 정의하고 모든 권한을 충족할지 아니면 일부 권한만 충족할지 지정하는 호출자를 정의하기만 하면 됩니다.

나는 #386을 열었고 이것이 아마 같다는 것을 깨닫고 있다. 내가 필요한 것은 권한을 확인하는 코드에서 "이 사용자에게 이 개체에 대한 편집 권한이 있습니까?"라고 할 수 있지만 사용자에게 권한을 할당할 때 "조정자" 권한을 할당하는 것입니다. "편집" 권한을 포함한 여러 권한의 상위 집합입니다. 이를 통해 나중에 모든 사용자에게 수동으로 권한을 할당하지 않고도 "조정자"에게 더 많은 권한을 추가할 수 있습니다.

이 권한 계층의 이름을 역할로 지정할 수 있습니다.

역할, 상속 및 선택 사항에 대해 +1

다음과 같은 역할 개념을 구현했습니다.

get_40x_or_None 사용자 정의

from django.conf import settings
from django.contrib.auth import REDIRECT_FIELD_NAME
from django.core.exceptions import ObjectDoesNotExist, PermissionDenied
from django.http import HttpResponseForbidden, HttpResponseNotFound
from django.shortcuts import render
from guardian.conf import settings as guardian_settings


def get_40x_or_None(request, perms, global_perms, obj=None, login_url=None,
                    redirect_field_name=None, return_403=False,
                    return_404=False):
    """check if the given perms and global_perms are both granted by the user in combination"""
    login_url = login_url or settings.LOGIN_URL
    redirect_field_name = redirect_field_name or REDIRECT_FIELD_NAME

    # Handles both original and with object provided permission check
    # as ``obj`` defaults to None

    has_permissions = False
    if not has_permissions:
        has_permissions = all(request.user.has_perm(perm, obj) for perm in perms) and \
                          all(request.user.has_perm(perm) for perm in global_perms)

    if not has_permissions:
        if return_403:
            if guardian_settings.RENDER_403:
                response = render(request, guardian_settings.TEMPLATE_403)
                response.status_code = 403
                return response
            elif guardian_settings.RAISE_403:
                raise PermissionDenied
            return HttpResponseForbidden()
        if return_404:
            if guardian_settings.RENDER_404:
                response = render(request, guardian_settings.TEMPLATE_404)
                response.status_code = 404
                return response
            elif guardian_settings.RAISE_404:
                raise ObjectDoesNotExist
            return HttpResponseNotFound()
        else:
            from django.contrib.auth.views import redirect_to_login
            return redirect_to_login(request.get_full_path(),
                                     login_url,
                                     redirect_field_name)

사용자 정의 GlobalPermissionRequiredMixin 구현

from django.core.exceptions import PermissionDenied, ImproperlyConfigured
from guardian.mixins import PermissionRequiredMixin
from collections.abc import Iterable

from permission.utils import get_40x_or_None


class GlobalPermissionRequiredMixin(PermissionRequiredMixin):
    global_permission_required = None

    def get_global_required_permissions(self, request=None):
        """
        Returns list of permissions in format *<app_label>.<codename>* that
        should be checked against *request.user* and *object*. By default, it
        returns list from ``global_permission_required`` attribute.

        :param request: Original request.
        """
        if isinstance(self.global_permission_required, str):
            perms = [self.global_permission_required]
        elif isinstance(self.global_permission_required, Iterable):
            perms = [p for p in self.global_permission_required]
        else:
            raise ImproperlyConfigured("'GlobalPermissionRequiredMixin' requires "
                                       "'global_permission_required' attribute to be set to "
                                       "'<app_label>.<permission codename>' but is set to '%s' instead"
                                       % self.global_permission_required)
        return perms

    def check_permissions(self, request):
        """
        Checks if *request.user* has all permissions returned by
        *get_required_permissions* method.

        :param request: Original request.
        """
        obj = self.get_permission_object()

        forbidden = get_40x_or_None(request,
                                    perms=self.get_required_permissions(request),
                                    global_perms=self.get_global_required_permissions(request),
                                    obj=obj,
                                    login_url=self.login_url,
                                    redirect_field_name=self.redirect_field_name,
                                    return_403=self.return_403,
                                    return_404=self.return_404,
                                    )
        if forbidden:
            self.on_permission_check_fail(request, forbidden, obj=obj)
        if forbidden and self.raise_exception:
            raise PermissionDenied()
        return forbidden

django 내장 crud 보기에서 global_required_permissions 및 required_permissions .

class ResourceDeleteView(GlobalPermissionRequiredMixin, DeleteView):
    ...
    global_permission_required = [app.delete_resource]
    permission_required = [app.view_resource]
    ...

결론

이 솔루션은 User 리소스 삭제에 대한 전역 권한이 있다는 것을 기반으로 합니다. 이 권한은 django 인증 모델에서 Group 의해 부여될 수 있습니다(이 문제의 맥락에서 역할). 그러나 그는 django 인증 모델에서 view_resource Permission 를 기반으로 하는 개체를 가지고 있기 때문에 리소스만 삭제할 수 있습니다. 이것이 django Guardian으로 역할을 구현하는 일반적인 방법이 될 수 있다고 생각합니다.

엄지손가락을 치켜세우면 위 코드의 충돌 없는 코드 버전으로 풀 리퀘스트를 열 것입니다.

정말 흥미로운 접근 @jokiefer. 나는 그것을 좋아한다. 나는 원래 그 라인을 따라 guardian 를 구현하려고 했다. 사용자는 전역 view 또는 edit 권한이 필요하지만 특정 개체에 액세스하려면 view 또는 edit 에 대한 개별 권한이 필요했습니다. 전역 권한은 개체 권한이 중요하지 않은 활성화 권한보다 더 많은 행위를 요구할 것입니다. 분명히 그것은 실제로 작동하지 않았으므로 나는 일을 재구성했습니다.

샘플이 이를 허용합니까? 즉, 전역 delete 권한이 필요하지만 실제로 delete 개체를 사용하려면 개체 기반 delete 권한도 필요합니다. 귀하의 예를 기반으로 글로벌 delete 가 필요하고 개체별 view ? 약간의 불일치입니까?

@dwasyl

샘플이 이를 허용합니까?
예, 이것은 귀하의 접근 방식에 적합합니다.

그러나 나는 위의 샘플에 초점을 맞추지 않았습니다. 우리 프로젝트에서는 가능한 한 간단한 acl 앱(AccessControlList)을 구현합니다. 이 앱에는 cl 이라는 하나의 핵심 모델이 있습니다. 이 모델은 atomic 보호자 권한의 추상화입니다. 사용자 집합, 권한 집합, 액세스 가능한 개체 집합을 저장합니다. 이 모델 뒤에 숨겨진 마법은 일부 신호에서 구현됩니다. 예를 들어 ownable_models_handling.py 는 보호자 권한으로 액세스할 수 있는 다른 모든 모델에 동적으로 신호를 추가하는 일반 신호입니다. 더 많은 모델을 확보하려면 AccessControlList 모델에 새 m2m 필드를 구현하면 됩니다. 이 필드는 자동으로 작동하려면 선행 accessible_MODELNAME 와 함께 호출되어야 합니다. acl_handling.py 에는 주어진 AccessControlList 기반으로 보호자 권한을 추가/제거하는 구현이 있습니다. 그것으로 우리는 가디언 코어를 수정할 필요가 없습니다.

이 cl 앱이 위의 샘플보다 더 도움이 될 수 있습니다. acl 앱에 대한 몇 가지 추가 작업으로 guadian(가디언을 위한 최상위 앱 솔루션)에 역할을 추가하는 일반적인 방법을 위해 코드에서 아웃소싱할 수 있습니다.