Django-tastypie: 훨씬 더 안전한 기본값이 필요합니다.`DjangoAuthorization`은 모든 모델 객체에 대한`읽기`액세스를 허용하지 않아야합니다.

나는 이것이 이미 합병되어 감사하지만 여전히 문제가 있습니다. 새 요청을 열기 전에 다음과 같은 문제가 있습니다.

이 변경 사항은 불행히도 기존 코드를 손상시켜 이전 버전과 호환되지 않습니다 (이전에는 모든 GET 요청이 DjangoAuthorization을 통과 했음). 코드를 수정하기위한 유일한 두 가지 옵션은 모든 사용자에게 '변경'권한을 부여하거나 (나쁜) 읽기 작업의 사용자 지정 구현을 위해 DjangoAuthorization을 하위 클래스로 만드는 것입니다 (잠재적으로 많은 작업). 이것은 의도 된 것이 었습니까?

장고 관리자 컨텍스트에서이 이유에 대해 감사하지만 API 컨텍스트에서 '변경'에 해당하는 것으로 '읽기'를 설정하는 것이 예상되는 동작이 아니기 때문에 합리적인 기본 가정이라고 생각합니다. 결국 GET이 DjangoAuthorization과 함께 허용 된 메서드 인 경우 사용자에게 change 권한이 없다는 사실에 따라 액세스를 거부하는 이유는 무엇입니까?

나는 그가 다음과 같은 대체 구현을 제안합니다.

_for read_detail_

• 모델에 view 권한이있는 경우 확인 (= 필요한 사용자를위한 개선)
• view 권한이없는 경우 항상 허용 (= 이전 버전과 호환 됨)

_for read_list_

• 모델에 list 권한이있는 경우 확인 (= 필요한 사용자를위한 개선)
• list 권한이없는 경우 항상 허용 (= 이전 버전과 호환 됨)

이 방법으로 tastypie는 Django의 권한 기본값과 호환되는 기본값을 추가하는 동시에 DjangoAuthorization의 사용자 정의 구현을 작성하는 것보다 필요한 사람들에게보기 및 목록 권한을 추가하여 개선 할 수있는 쉬운 경로를 제공합니다.

최소한 기본 권한을 지정하는 방법이 있어야합니다.

DjangoAuthorization(read_permission='view', # applies to both list, detail if not spec'd
                    read_list_permission='view', # list only
                    read_detail_permission='view') # detail only
# while we're at it, why not add the other permissions too
DjangoAuthorization(change_permission='change',
                    delete_permission='delete',
                    add_permission='add', 
                    # ... add options as per above for each
                    # <action>_<level> permission where 
                    # action is `change,delete,add,read`,  level is `list,detail`)

@SeanHayes 가 결정하는 사람이 될 것입니다.

내 의견은 기본적으로 읽기를 허용하는 것이 보안 문제라고 생각합니다. 프로덕션에 매우 가까워지기 전까지는 전혀 예상하지 못했습니다. 이 맥락에서 이전 버전과의 호환성을 깨는 것이 필요하다고 생각합니다.

귀하의 제안에 따라 기존 코드에 대한 매개 변수 전달을 DjangoAuthorization 로 변경해야하는 것 같습니다.이 경우 클래스를 다른 것으로 호출하는 것이 더 명확하다고 생각합니다.

read_permission='view' 케이스를 고려하십시오. 여기에 정확히 필요한 것이있을 수 있습니다. 나는 그것이 왜 덜 최적인지 모르겠다.

class ModifiedDjangoAuthorization(DjangoAuthorization):
    READ_PERM_CODE = 'view'

다른 것을 변경하려면 메서드를 재정의하십시오. 변경은 실제로 매우 쉽게 할 수 있도록 설계되었습니다.

class ModifiedDjangoAuthorization(DjangoAuthorization):
    def delete_list(self, object_list, bundle):
        return self.perm_list_checks(bundle.request, 'del', object_list)

    def delete_detail(self, object_list, bundle):
        return self.perm_obj_checks(bundle.request, 'del', bundle.obj)

변경 사항은 수정을 염두에두고 쉽게 만들었습니다. init 매개 변수로 수행해야한다고 생각할 필요는 없습니다.

기본적으로 읽기를 허용하는 것이 보안 문제라고 생각합니다.

나는 원래 문제의 의도에 의문을 제기하는 것이 아닙니다. 병합 된 구현이 사람들의 기존 코드 및 가정을 무너 뜨리는 것과 되돌릴 수있는 효율적인 옵션이 없다는 점을 지적하십시오.

귀하의 제안에 기존 코드에 대한 DjangoAuthorization에 대한 매개 변수 전달을 변경 해야하는 것처럼 보입니다.

제가 제안한 솔루션을 다시 살펴보면 제가 옹호하는 것은 사람들에게 안전하고 이전 버전과 호환되는 기본 옵션을 제공하는 것입니다. 이 경우 사용자 코드를 변경할 필요가 없습니다.

이 맥락에서 이전 버전과의 호환성을 깨는 것이 필요하다고 생각합니다.

동의하지 않습니다. 현재 병합 된 변경은 이전 버전과의 호환성을 깨뜨릴뿐만 아니라 명백한 방법 (현재 구현에 의해 암시 됨)이 GET을 허용해야하는 모든 사용자에게 변경 권한을 할당하는 것이므로 훨씬 더 큰 잠재적 보안 문제를 야기합니다.

솔직히, 읽기 작업에 대한 change 권한이 보안을 향상시키는 동시에이 권한이 PUT도 허용하는 방법을 보지 못했습니다. 다른 작업에 대한 권한을 혼합하는 것은 좋은 선택이 아닌 것 같습니다.

안타깝게도 제안 된 ModifiedDjangoAuthorization 은 실제로 view 권한을 모델에 추가하지 않는 한 트릭을 수행하지 않으므로 다시 이전 버전과의 호환성이 깨집니다. 최소한 코드 변경이 필요하므로 이전 버전과의 호환성을 깨고 사용자가 코드 기반을 다시 작업해야합니다.

물론 재정의는 항상 특정 요구 사항을 달성하는 옵션이지만 tastypie의 일반적인 아이디어는 사용자 지정 코드를 추가 할 필요가없는 합리적이고 안전한 기본값을 제공하는 것이라고 생각합니다.

요컨대 더 나은 구현을 위해이 변경 사항을 되돌려 야한다고 생각합니다.

change 권한은 Django 자체에서 제공됩니다. Django의 기본값이며 Django Admin 앱이 설정되는 방식입니다. view 옵션은 그렇지 않습니다. 저는 개인적으로 read 로 이름을 지정했습니다.

model 를 확인하여 무슨 뜻인지 잘 모르겠습니다. _meta 확인을 의미하는 경우 불완전 할 수 있습니다. 당신이 db를 치는 것을 의미한다면, 나는 그것이 불필요하게 비싸다는 것을 알았습니다.

내 선호에 따라, 당신이 제안한 것은 기본 인증에 대해 "너무 많은 마법"쪽에있는 것 같습니다. 쉽게 재정의 할 수있는 안전한 기본값 만 있으면 충분 해 보입니다. 그러나 그것은 단지 내 의견입니다.

변경 사항은 https://github.com/django-tastypie/django-tastypie/blob/master/docs/release_notes/v0.13.2.rst 에 문서화되었습니다.

솔직히,이 권한이 PUT도 허용하는 동시에 읽기 작업에 대한 변경 권한이 보안을 향상시키는 방법을 알지 못합니다. 다른 작업에 대한 권한을 혼합하는 것은 좋은 선택이 아닌 것 같습니다.

우리는 사용자가 무언가를 변경할 수 있다면 그것을 읽을 수 있다는 것을 압니다. 그것이 Django 관리자가하는 방식입니다.

이 버전은 개발자가 자신이하는 일에 대해 생각하게하기 때문에 더 안전합니다. 자신의 "읽기"권한을 개발하는 대신 개발자가 "읽기"권한 만 가져야 할 때 의도적으로 모든 사람에게 "변경"권한을 부여하기로 선택하는 것이 문제입니다. 저는 다른 개발자들이 의도적으로 어리석은 일을하는 것을 막을 수 없습니다. 저는 Tastypie가 어리석은 일을하는 것을 막기 위해 여기에 있습니다. 이 변경의 요점은 DjangoAuthorization을 사용하는 모든 리소스에 대한 전역 읽기 권한을 방지하는 것이 었습니다. 새로운 동작은 개발자가 Django 관리자에서 경험하는 것과 일치합니다.

이전 동작을 원하는 경우 :

1. 0.13.2로 업그레이드하지 마십시오.
2. 또는 read_list and read_detail` 메서드를 재정의합니다.

문서가 개선 될 수 있다고 생각되면 자유롭게 PR을 제출하십시오.

귀하의 의견에 감사드립니다. 문서에 대한 링크를 주셔서 감사합니다. 충분히 공평하게, 그것을 놓친 것에 대해 나쁘게 생각합니다 (문제는 v0.13.4에 할당되었지만 문서는 v0.13.2에 있습니다).

내 pov에서 몇 가지 마지막 발언을하겠습니다.

우리는 사용자가 무언가를 변경할 수 있다면 그것을 읽을 수 있다는 것을 압니다. 그것이 Django 관리자가하는 방식입니다.

Django 관리자는 change 권한을 사용합니다. _changing_ 개체에 대한 관리자 인터페이스 _is_이기 때문입니다. 거기에서 의미가 있습니다. REST API에 대한 GET 요청은 정의에 따라 _reading / viewing_입니다. 대부분의 개발자는 DjangoAuthorization이 변경 권한이 없어서 읽기를 거부 할 것이라고 기대하지 않습니다.

이 버전은 개발자가 자신이하는 일에 대해 생각하게하기 때문에 더 안전합니다.

tastypie의 광고 기능 중 하나는 _ 합리적인 기본값 _을 제공하는 것입니다. API의 GET (정의 : 읽기) 및 PUT (변경) 메서드가 모든 의도와 목적에서 서로 다른 작업이므로 다른 권한도 필요하다고 가정하는 것이 합리적이지 않습니까?

귀중한 추가라고 생각한다면 제가 쓴 내용에 따라 PR을 기꺼이 기꺼이 드리겠습니다.

변경 권한은 Django 자체에서 제공됩니다. (...) 옵션보기가 아닙니다.

Django에서 view permission 를 추가하기 위해 보류중인 PR이 있으므로 뷰를 사용했습니다.

기본적으로 퍼블릭 / 글로벌 읽기 작업을 허용하지 않습니다. 그것은 최종입니다. 그리고 우리는 현재 그렇게 할 수있는 표준적인 방법이 없는데 개발자들이 어떻게 권한을 설정하는지 추측하지 않을 것입니다. 우리는 그것을 "읽기"또는 "보기"라고 부를지조차 확실하지 않으며, 여기에 오는 많은 사람들이 "나는 이런 식으로한다"또는 "새로운 Django 릴리스에서 그것을 다른 것으로 부르는 것을 원하지 않습니다." .

Django가 즉시 읽기 /보기 권한을 지원하는 경우 해당 권한으로 전환합니다. 지금은 개발자가 권한을 처리하는 사용자 지정 방식을 처리하기 위해 사용자 지정 코드를 작성해야합니다.

이 문제가 종결 된 것을 알고 있지만이 변경으로 인해 기존 프로젝트를 0.13.x로 마이그레이션하는 것이 기본적으로 차단되었다고 말하고 싶습니다.

@miraculixx 단순히 데이터를보기 위해 변경 권한을 요구하는 것이 약간 미친 짓이라는 사실과 관련하여 귀하가 완전히 옳다고 생각합니다. 나는 우리가 어떻게 든 장고를 비난 할 수 있다고 생각합니다. 그래도 뷰 권한의 개념이 없습니다. CRUD의 READ 부분).

생산을 중단하는 변경을 할 때 최소한 버전 관리에 반영 할 수 있습니까?
Tastypie의 x.y.z 버전 관리는 대부분의 사람들이 기대하는 것과 매우 유사합니다. 일반적으로 다음과 같습니다.

버전 번호 MAJOR.MINOR.PATCH가 주어지면 다음을 증가시킵니다.
..
이전 버전과 호환되는 버그 수정을 할 때 패치 버전.

새로운 프로덕션 배포 중에 이것을 추적하는 데 매우 불편한 시간을 보냈습니다.