Werkzeug: CORS 지원

Werkzeug는 WSGI 애플리케이션에서 반환하는 응답에 헤더를 설정할 수 있다는 점에서 이미 CORS를 지원합니다. Werkzeug 내에서 "CORS 지원"을 위해 무엇을 할 수 있거나 해야 하는지 잘 모르겠습니다. 자세히 설명해 주시겠습니까?

저는 OP가 아니지만 CORS는 거의 상용구 헤더 주입이므로 설정/매개변수로 사용하는 것이 좋습니다. 이 스 니펫 의 라인을 따라 뭔가가 있지만 여기에는 특히 OPTIONS가 없으므로 preflight가 문제가 될 것입니다 ...

    if 'cors' in config and config['cors'] is True:
        response.headers.add('Access-Control-Allow-Origin', '*')
        response.headers.add('Access-Control-Allow-Methods',
                             'GET,PUT,POST,DELETE,PATCH')
        response.headers.add('Access-Control-Allow-Headers',
                             'Content-Type, Authorization')

...파이썬 만트라 "배터리 포함"을 알고 있습니다... ;)

그러나 CORS는 특히 쿠키와 물건을 사용할 때 * 허용하는 것 이상입니다. 개인적으로 저는 20 LoC WSGI 미들웨어를 사용하여 CORS 헤더를 추가하고 비행 전 요청에 응답합니다. 그렇게 어렵지 않습니다.

@posativ - 요점을 공유하고

매우 제한된 형태로:

from werkzeug.datastructures import Headers

class CORSMiddleware(object):
    """Add Cross-origin resource sharing headers to every request."""

    def __init__(self, app, origin):
        self.app = app
        self.origin = origin

    def __call__(self, environ, start_response):

        def add_cors_headers(status, headers, exc_info=None):
            headers = Headers(headers)
            headers.add("Access-Control-Allow-Origin", self.origin)
            headers.add("Access-Control-Allow-Headers", "Origin, ...")
            headers.add("Access-Control-Allow-Credentials", "true")
            headers.add("Access-Control-Allow-Methods", "GET, POST, PUT, etc")
            headers.add("Access-Control-Expose-Headers", "...")
            return start_response(status, headers.to_list(), exc_info)

        if environ.get("REQUEST_METHOD") == "OPTIONS":
            add_cors_headers("200 Ok", [("Content-Type", "text/plain")])
            return [b'200 Ok']

        return self.app(environ, add_cors_headers)

# usage
app = CORSMiddleware(make_app(...), "http://example.org/")

사용자 정의 헤더, 자격 증명, 와일드 카드를 포함하도록 이 클래스를 확장할 수 있습니다.

@posativ - 감사합니다. 다음 주 초에 해당 프로젝트에 대한 작업을 재개할 때 시도해 보겠습니다. :)

이것을 부풀려야 합니다.

상대적 질문 http://stackoverflow.com/questions/19382431/set-header-on-werkzeug-exception

관련 라인: https://github.com/pallets/werkzeug/blob/master/werkzeug/debug/__init__.py#L297

start_response('500 INTERNAL SERVER ERROR', 는 Access-Control-Allow-Origin: * 와 같은 CORS 헤더를 추가하기 어렵게 만듭니다. 하지만 흥미롭게도 이미 X-XSS-Protection: 0 가 있습니다.

Flask-CORS를 활성화하고 Chrome에서 까다로운 원격 Ajax API 호출을 디버깅하고 있습니다. Flask에 예외가 있을 때 CORS로 인해 디버그 내용을 볼 수 없습니다. 디버그 모델에 이 헤더를 추가할 수 있습니까?

디버거에서 CORS 헤더를 설정하려는 이유는 무엇입니까? 그리고 왜 래핑 미들웨어로 그렇게 할 수 없습니까?

또한 werkzeug에 모든 미들웨어를 추가할 필요가 없다고 생각하기 때문에 이것을 닫고 싶습니다.

@unititaker

디버거에서 CORS 헤더를 설정하려는 이유는 무엇입니까?

교차 도메인 AJAX 요청에 의해 호출되는 까다로운 시나리오이기 때문에 일련의 자바스크립트 이벤트 트리거 후에만 Chrome DevTool에서 디버그할 수 있습니다. CORS 헤더가 없으면 Chrome DevTool은 콘텐츠를 전혀 표시하지 않습니다. 나는 아무것도 볼 수 없습니다. 500 서버 오류가 있는 빈 페이지만 응시할 수 있습니다.

그리고 왜 래핑 미들웨어로 그렇게 할 수 없습니까?

래핑된 미들웨어는 NORMAL (적절하게 반환된 Flask 응용 프로그램) 페이지에서만 작동하지만 Werkzeug 예외 디버거가 발생하면 전혀 작동하지 않기 때문입니다.

https://github.com/corydolphin/flask-cors/issues/67에서 언급하는 "래핑 미들웨어"가 있습니다. 낮은 수준의 Werkzeug 항목이 조정되지 않는 한 이에 대해 많은 것을 할 수 없습니다.

@untitaker 가 내가 링크한 소스 코드를 살펴보지 않았다고 가정합니까? 다음은 스크린샷입니다.

@lambdaq 지금 당신은 심술궂게 굴고 있습니다

디버그 래핑된 애플리케이션을 래핑하는 모든 미들웨어는 start_response 동작을 변경할 수 있습니다(디버거의 경우에도). 따라서 붙여넣고 링크한 코드는 완전히 관련이 없는 것처럼 보입니다.
cors 미들웨어를 감싸는 것은 그것을 변경할 수 있기 때문에

다른 관점/이해로 인해 정확한 문제가 누락되었을 수 있습니다. 깨진/불가능한 것처럼 보이는 정확한 사용 사례를 간략하게 설명하십시오.

app.run을 호출할 때 디버거 미들웨어가 적용되기 때문에 상황이 약간 까다로워집니다. 그래도 CORS와 디버거 미들웨어를 모두 수동으로 적용하여 이 문제를 해결할 수 있습니다. IMO는 이러한 엣지 케이스에 적합하지만 보안을 손상시키지 않는 방식으로 디버거 미들웨어를 변경하기 위한 구체적인 제안이 있으면 제안하십시오. 하지만 쉬운 변화는 모릅니다.

또한 Werkzeug의 코드를 잘 알고 있습니다. 내가 그것을 유지하는 이유 같아요?

죄송합니다. 제 언어에 대해 사과드립니다. Werkzeug는 멋진 프로젝트입니다.

이 start_response() 행을 원숭이 편집하고 내 개발 환경에 CORS 헤더 무차별 대입을 추가해야 한다고 생각합니다. 털이 미들웨어보다 더 편리합니다.

또한 500 응답이 반환되는 경우 디버거로 리디렉션하는 대신 추가 JS 코드를 추가하는 것을 고려할 수 있습니다.

@untitaker JS 코드는 아무 것도 할 수 없습니다. 500 오류가 있으면 http 상태 코드가 500이고 디버거 페이지의 역추적만

또한 js 코드는 다른 팀에서 개발한 수많은 항목으로 컴파일된 reactjs이며 npm run dev 까지 300초 이상 걸립니다. 약간의 디버그 라인을 수정하거나 추가하기가 쉽지 않습니다.

나는 #1699가 이것을 해결한다고 생각한다. Werkzeug는 #1699에 있는 것보다 더 많은 작업을 수행할 수 있지만 (캐시 제어와 같은) 접근자 메서드를 제공하고 여기에 빌드된 도구(예: Flask-CORS 또는 Quart-CORS)가 CORS 논리를 수행하도록 허용해야 한다고 생각합니다.