Werkzeug: CORS-Unterstützung

Werkzeug unterstützt CORS bereits insofern, als Sie die Header für die Antworten festlegen können, die Sie in Ihrer WSGI-Anwendung zurückgeben. Ich bin mir nicht sicher, was innerhalb von Werkzeug sonst noch getan werden kann oder sollte, um CORS zu unterstützen. Können Sie das näher erläutern?

Ich bin nicht das OP, aber da CORS so ziemlich eine Boilerplate-Header-Injektion ist, könnte es vielleicht eine gute Idee sein, es als Einstellung / Parameter zu haben. Etwas in der Art dieses Snippets , obwohl es hier keine OPTIONEN gibt, daher wird der Preflight problematisch ...

    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')

...du kennst das Python-Mantra: "Batterien enthalten"... ;)

Aber CORS erlaubt mehr als * , insbesondere wenn Sie Cookies und ähnliches verwenden. Persönlich verwende ich eine 20 LoC WSGI Middleware, um CORS-Header hinzuzufügen und Preflight-Anfragen zu beantworten. Es ist nicht so schwer.

@posativ - Möchten Sie vielleicht ein Wesentliches teilen? :)

In sehr eingeschränkter Form:

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/")

Sie können diese Klasse um benutzerdefinierte Header, Anmeldeinformationen und Platzhalter erweitern.

@posativ - Vielen Dank dafür, ich werde es Anfang nächster Woche versuchen, wenn ich die Arbeit an diesem Projekt wieder aufnehmen werde. :)

Muss das aufpolieren.

Relative Frage http://stackoverflow.com/questions/19382431/set-header-on-werkzeug-Exception

Verwandte Zeile: https://github.com/pallets/werkzeug/blob/master/werkzeug/debug/__init__.py#L297

start_response('500 INTERNAL SERVER ERROR', macht es schwierig, CORS-Header wie Access-Control-Allow-Origin: * hinzuzufügen. Aber seltsamerweise haben wir bereits X-XSS-Protection: 0 dort.

Ich habe Flask-CORS aktiviert, habe einen kniffligen Remote-Ajax-API-Aufruf in Chrome debuggt. Wenn Flask eine Ausnahme hat, kann ich den Debug-Inhalt wegen CORS nicht sehen. Können wir diesen Header im Debug-Modell hinzufügen?

Warum sollten Sie im Debugger einen CORS-Header festlegen? Und warum können Sie das nicht mit einer Wrapping-Middleware tun?

Außerdem möchte ich dies schließen, da ich nicht denke, dass wir jede Middleware zu werkzeug hinzufügen müssen.

@unititaker

Warum sollten Sie im Debugger einen CORS-Header festlegen?

Da es sich um ein kniffliges Szenario handelt, das durch eine domänenübergreifende AJAX-Anforderung aufgerufen wird, kann es in Chrome DevTool nur nach einer Reihe von Javascript-Ereignisauslösungen debuggt werden, wenn kein CORS-Header vorhanden ist, zeigt das Chrome DevTool überhaupt keinen Inhalt an. Ich kann nichts sehen. Ich kann nur auf eine leere Seite mit 500 Serverfehler starren.

Und warum können Sie das nicht mit einer Wrapping-Middleware tun?

weil umschlossene Middleware nur mit

Hier ist die "Wrapping-Middleware", auf die Sie sich beziehen, https://github.com/corydolphin/flask-cors/issues/67. Sie können sehen, dass wir nicht viel dagegen tun können, es sei denn, Werkzeug auf niedrigerer Ebene wurde optimiert.

Ich nehme an ,

@lambdaq jetzt bist du gemein zu @untitaker

Jede Middleware, die eine Debug-umschlossene Anwendung umschließt, kann das Verhalten von start_response ändern - sogar für den Debugger -, sodass der von Ihnen eingefügte und verlinkte Code völlig irrelevant erscheint.
da eine umhüllende Cors-Middleware es einfach ändern könnte

Vielleicht vermisse ich Ihr genaues Problem, aufgrund unterschiedlicher Perspektiven/Verständnisse skizzieren Sie bitte den genauen Anwendungsfall, der kaputt/unmöglich erscheint

Die Situation wird etwas knifflig, da beim Aufruf von app.run die Debugger-Middleware angewendet wird. Sie können dies jedoch umgehen, indem Sie sowohl Ihr CORS als auch die Debugger-Middleware manuell anwenden. IMO ist dies für einen solchen Edgecase in Ordnung, aber wenn Sie konkrete Vorschläge haben, die Debugger-Middleware so zu ändern, dass die Sicherheit nicht beeinträchtigt wird, schlagen Sie sie bitte vor. Ich kenne jedoch keine einfachen Änderungen.

Auch der Code in Werkzeug ist mir gut bekannt. Ich schätze, deshalb behalte ich es bei?

Entschuldigung, ich entschuldige mich für meine Sprache, Werkzeug ist ein tolles Projekt.

Ich schätze, ich muss nur diese start_response() Zeilen bearbeiten und CORS-Header-Bruteforce für meine Entwicklungsumgebung hinzufügen, das ist bequemer als eine haarige Middleware.

Sie könnten auch in Betracht ziehen, stattdessen zusätzlichen JS-Code hinzuzufügen, der zum Debugger umleitet, wenn eine 500-Antwort zurückkommt.

@untitaker JS-Code kann nichts tun, wenn es einen 500-Fehler gibt, können Sie nur sagen, dass sein http-Statuscode 500 ist, der Traceback von der Debugger-Seite ist das, wonach ich suche.

auch der js-code ist haarig kompilierte reaktionsjs mit tonnenweise sachen, entwickelt von einem anderen team, es dauert 300s+ bis npm run dev . Nicht einfach zu optimieren oder ein paar Debug-Zeilen hinzuzufügen.

Ich denke, #1699 löst dies. Während Werkzeug mehr tun könnte als in #1699, sollte es meiner Meinung nach nur Accessor-Methoden (wie für die Cache-Steuerung) bereitstellen und darauf aufbauende Tools (z. B. Flask-CORS oder Quart-CORS) die CORS-Logik ausführen lassen.