Django-rest-framework: DRF는 기본적으로 모든 OPTIONS 요청을 승인해야 합니다.

DRF 버전: 3.7.3
파이썬 3.6.3

위에서 언급한 임시 해결 방법이 효과가 없었습니다. PUT, POST, GET, OPTIONS 등인지 여부에 관계없이 모든 요청이 인증되었습니다.

다음과 같이 변경했습니다.

# myapp/permissions.py
from rest_framework.permissions import IsAuthenticated

class AllowOptionsAuthentication(IsAuthenticated):
    def has_permission(self, request, view):
        if request.method == 'OPTIONS':
            return True
        return request.user and request.user.is_authenticated

그리고 settings.py에서:

REST_FRAMEWORK = {
    'DEFAULT_AUTHENTICATION_CLASSES': ( 'rest_framework.authentication.TokenAuthentication',),
    'DEFAULT_PERMISSION_CLASSES': (
        'myapp.permissions.AllowOptionsAuthentication',
    )
}

나도 같은 문제가 발생했습니다. 제안된 솔루션에 동의하며 임시 해결 방법에 감사드립니다!

CORS 실행 전 요청 이외의 경우에 OPTIONS 요청을 사용하는 REST 프레임워크를 사용하는 많은 개발자가 있기 때문에 "기본적으로 모든 OPTIONS 요청을 승인해야 함"이 정확히 우리가 원하는 동작이라고 100% 확신하는 것은 아닙니다.

그러나 우리는 아마도 축복받은 CORS 옵션을 원할 것입니다. https://github.com/ottoyiu/django-cors-headers/를 직접 포함해야 하는지 아니면 더 많이 참조해야 하는지 모르겠습니다.

해당 패키지를 사용하면 이 문제가 해결됩니까?

이 패키지는 실제로 솔루션이 아니며 CORS 헤더를 추가할 뿐 인증되지 않은 모든 요청에 ​​대해 DRF 권한이 특별히 부여되지 않은 경우 OPTIONS가 HTTP401을 반환한다는 사실을 수정하지 않습니다.

IMO는 다른 방식으로 도입되어야 합니다. 즉, 기본적으로 주요 변경 공지와 함께 허용됩니다.
이것은 W3C 사양에 따라 예상되는 동작이며 잘못된 구현을 패치하기 위해 문서에서 타사를 언급하는 것은 실제로 깨끗한 솔루션이 아닙니다...

따라서 CORS가 아닌 관련 항목에 OPTIONS를 사용하는 사람들이 있지만(저도 그 중 하나입니다), CORS 메커니즘이 점점 더 많은 브라우저에 의해 시행되고 있기 때문에 잠재적으로 훨씬 더 많은 것을 암시적으로 예상하고 있습니다. 실제로 이러한 메커니즘은 웹을 통해 OPTIONS 요청의 99% 이상을 잠재적으로 생성합니다.

흥미로운 갈등. OPTIONS 메서드에서 기본적으로 암시적 허용을 사용하는 문제를 완전히 이해합니다. 나는 자연스럽게 더 안전한 솔루션에 더 편향되어 있으며 DRF에 대한 개발자의 목적에 달려 있다고 생각합니다. 따라서 기본 거부가 나에게 더 적절해 보입니다.

OPTIONS를 허용하기 위한 W3C 사양이 CORS의 컨텍스트에서만 적용되는 것도 가능합니다. 분명히 DRF는 컨텍스트를 알 수 있는 방법이 없으며 개발자에게 제공되는 설정이어야 합니다.

CORS가 의도된 경우 모든 OPTIONS 요청을 허용합니다. CORS는 기본적으로 의도하지 않습니다.

실제로 현재 동작을 계속 사용할 수 있는 상태에서 주요 버전에 대한 주요 변경 사항을 고려할 수 있다고 생각합니다. 우리의 기존 OPTIONS 동작은 사람들이 CORS가 아닌 JSONP를 사용했기 때문에 적용되었으므로 아마도 우리가 노출하는 상당히 임시적인 기본 정보 세트를 제거하고 기본적으로 CORS용 OPTIONS에만 집중하는 새로 고침 때문일 것입니다. .

+1

@tomchristie 메이저 버전 업데이트/수정이 언제 일어날지 알고 있습니까? 나는 또한이 문제를 치고 있습니다.

한편 @medakk 의 해결 방법은 완벽합니다!

3.9에 대한 적절한 고려를 받을 수 있도록 이정표를 작성합니다.

다른 해결 방법은 뷰에서 이를 명시적으로 처리하는 것입니다. 여러 permission_classes가 있는 경우 각각이 처리가 필요하기 때문에 더 DRY입니다.

def check_permissions(self, request):
        if request.method == 'OPTIONS':
            return
        super(MyApiView, self).check_permissions(request)

https://github.com/OttoYiu/django-cors-headers 패키지는 미들웨어에서 preflighted OPTIONS 요청을 처리하고 응답을 직접 반환합니다. REST 프레임워크에 도달하기 전에 요청/응답이 가로채기 때문에 여기에서 REST 프레임워크가 무엇을 하는지는 중요하지 않습니다.

여기에 문제 가 있다는 것이 분명하지 않습니다.

실행 전 응답은 REST 프레임워크를 건드리지 않습니다: https://github.com/ottoyiu/django-cors-headers/blob/master/corsheaders/middleware.py#L83

감사 해요. 우리는 django-cors-headers를 사용하지 않지만 아마도 그렇게 해야 할 것입니다.
나는 여전히 DRF가 W3C 호환 CORS 요청을 처리하기 위해 외부 패키지가 필요하지 않아야 한다는 이전 의견에 동의합니다.

예, 문제를 우회하는 방법/타사 패키지가 많이 있습니다.
하지만 이 티켓은 DRF가 W3C CORS 사양과 호환되지 않기 때문에 생성되었으며 수정되어야 합니다.

오늘날 엔드포인트에 대해 수행되는 대부분의 OPTIONS 요청은 프리플라이트 목적을 위한 것이며 DRF의 독단적인 선택으로 인해 새로운 DRF 사용자가 이러한 문제를 수동으로 처리해야 하는 것은 아마도 기만적일 것입니다.

오늘날 엔드포인트에 대해 수행되는 대부분의 OPTIONS 요청은 프리플라이트 목적을 위한 것이며 DRF의 독단적인 선택으로 인해 새로운 DRF 사용자가 이러한 문제를 수동으로 처리해야 하는 것은 아마도 기만적일 것입니다.

CORS가 OPTIONS 메서드를 하이재킹했다고 해서 기본적으로 보안을 수용하도록 변경되어야 한다는 의미는 아닙니다. 특히 CORS 지원이 제대로 구현되면 필요한 방식으로 작동합니다. 죄송하지만, 이것을 변경하고 싶은 개발자는 DRF 관리자가 아니라 자신의 의견을 확인해야 한다고 생각합니다.

CORS가 필요한 경우 바퀴를 다시 발명하는 대신 적절한 구현을 지원하는 모듈을 사용하도록 제안하는 문서 개선 사항일 수 있습니다.

레벨을 낮추자.

미들웨어 는 CORS 헤더를 처리하는 합리적인 장소입니다. 우리는 그것을 REST 프레임워크에 구축 할 수 있지만 기존 패키지는 이미 그것을 정말 훌륭하게 다루었습니다.

REST 프레임워크가 OPTIONS 요청에 대해 반환하는 본문은 여기에서 관련이 없습니다. preflighted CORS 요청은 어쨌든 미들웨어에서 가로채야 하고 표준 CORS 요청은 모든 HTTP 메서드일 수 있기 때문입니다.

REST 프레임워크가 기본적으로 해당 응답 본문을 제공 하지 않는 것으로 이동하는 것이 매우 기쁩니다. 그러나 이는 CORS 지원 문제와 약간 다르며 REST 프레임워크가 거기에서 독단적인 행동을 하는 것이 아니라 오히려 CORS가 널리 구현되기 이전의 동작입니다.

미들웨어 솔루션만으로는 부족하거나 최소한 DRF의 협조가 필요한 것 같습니다. 참조된 코드를 보면 전역 기본값이 CORS 헤더를 제공하는 데 사용되고 있음을 알 수 있습니다. 그러나 각 보기가 지원하는 헤더를 전역적으로 어떻게 알 수 있습니까?

따라서 미들웨어가 보기 집합/보기에서 이러한 구성 옵션에 연결하는 표준 방법을 보고 싶습니다. 예를 들어 allowed_cors_headers 방법입니다.

나는 이것이 뷰에 의해 처리될 필요가 없다는 데 동의하지만 그것이 제공할 수 있는 것에 대한 뷰의 지식을 절대적으로 존중해야 합니다.

라우터의 모든 보기에 적용할 라우터 수준 재정의를 갖는 것도 가치가 있습니다.

추가 고려 사항:

• 원산지에 따라 다름
• 콘텐츠 유형에 따라 다름

이것은 내가 가장 좋아하는 선택은 아니지만 타사를 사용하는 방향으로 가고 있습니다.

문서가 CORS 사용자에 대한 적절한 정보로 업데이트되면 이 티켓을 닫을 수 있다고 생각합니다(예: "조심, DRF는 OPTIONS 요청에 대한 W3C CORS 사양을 충족하지 않습니다. CORS에 OPTIONS를 사용하는 경우 추가하는 것을 잊지 마십시오. 적절한 미들웨어가 없으면 승인 부족으로 인해 실행 전 요청이 실패할 수 있습니다." 등)

기존 문서 https://www.django-rest-framework.org/topics/ajax-csrf-cors/#cors 는 완벽하게 합리적이며 미들웨어에서 CORS를 처리하는 것이 어떤 경우에도 올바른 접근 방식입니다.

그러나 각 보기가 지원하는 헤더를 전역적으로 어떻게 알 수 있습니까?

그럴 필요는 없습니다. 사이트의 CORS 정책이 무엇인지 알아야 합니다.

CORS 문서를 더 눈에 띄게 만들거나 적절한 다른 위치에 포함시키는 pull 요청을 수락하게 되어 기쁩니다. 그 외에는 여기에 실행 가능한 문제가 없습니다.

사양에 대한 나의 오해, 웁스.

이 경우 지원은 django 사이트 기여에 더 잘 포함될 것입니다.
패키지가 아닌 drf.

르마르. 19화 2019년 10시 22분, Tom Christie [email protected] a
에크리트 :

기존 문서
https://www.django-rest-framework.org/topics/ajax-csrf-cors/#cors 는
완벽하게 합리적이며 미들웨어에서 CORS를 처리하는 것이 정확합니다.
어떤 경우에도 접근합니다.

그러나 각 보기가 지원하는 헤더를 전역적으로 어떻게 알 수 있습니까?

그럴 필요는 없습니다. 사이트의 CORS 정책이 무엇인지 알아야 합니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/encode/django-rest-framework/issues/5616#issuecomment-465146969 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AFhtlM6bG-Bs2CvoO972pIfwvxLHbzAxks5vPAjAgaJpZM4Qlvkn
.