Werkzeug: Prise en charge de la SCRO

Werkzeug prend déjà en charge CORS en ce sens que vous pouvez définir les en-têtes sur les réponses que vous retournez dans votre application WSGI. Je ne sais pas quoi d'autre peut ou devrait être fait au sein de Werkzeug pour « soutenir CORS », pouvez-vous développer cela ?

Je ne suis pas l'OP, mais comme CORS est à peu près une injection d'en-tête standard, ce serait peut-être une bonne idée de l'avoir comme paramètre/paramètre. Quelque chose dans le sens de cet extrait , bien qu'ici, notamment, il n'y ait pas d'OPTIONS, donc le contrôle en amont sera problématique...

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

...vous connaissez le mantra du python : "piles incluses"... ;)

Mais CORS ne se limite pas à autoriser * , surtout lorsque vous utilisez des cookies et autres. Personnellement, j'utilise un middleware WSGI 20 LoC pour ajouter des en-têtes CORS et répondre à la demande de contrôle en amont. Ce n'est pas si dur.

@posativ -

Sous une forme très limitée :

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

Vous pouvez étendre cette classe pour inclure des en-têtes personnalisés, des informations d'identification et des caractères génériques.

@posativ - Merci pour cela, je vais l'essayer au début de la semaine prochaine quand je reprendrai le travail sur ce projet. :)

Besoin de remonter ça.

Question relative http://stackoverflow.com/questions/19382431/set-header-on-werkzeug-exception

Ligne associée : https://github.com/pallets/werkzeug/blob/master/werkzeug/debug/__init__.py#L297

le start_response('500 INTERNAL SERVER ERROR', rend difficile l'ajout d'un en-tête CORS comme Access-Control-Allow-Origin: * . Mais curieusement, nous avons déjà X-XSS-Protection: 0 là-bas.

J'ai activé Flask-CORS, j'ai débogué un appel API ajax distant délicat dans Chrome, lorsque Flask a une exception, je ne peux pas voir le contenu de débogage à cause de CORS. Pouvons-nous ajouter cet en-tête dans le modèle de débogage ?

Pourquoi voudriez-vous définir un en-tête CORS sur le débogueur ? Et pourquoi ne pouvez-vous pas faire cela avec un middleware d'emballage ?

Je veux également fermer ceci car je ne pense pas que nous ayons besoin d'ajouter tous les middleware à werkzeug.

@unittaker

Pourquoi voudriez-vous définir un en-tête CORS sur le débogueur ?

Parce qu'il s'agit d'un scénario délicat invoqué par une requête AJAX interdomaine, il ne peut le déboguer dans Chrome DevTool qu'après une série de déclenchements d'événements javascript, s'il n'y a pas d'en-tête CORS, Chrome DevTool n'affiche aucun contenu. Je ne peux rien voir. Je ne peux que regarder une page blanche avec une erreur de serveur 500.

Et pourquoi ne pouvez-vous pas faire cela avec un middleware d'emballage ?

car le middleware encapsulé fonctionne uniquement avec les pages NORMAL (application Flask renvoyée appropriée), mais ne fonctionne pas du tout lorsque le débogueur d'exception Werkzeug se produit.

Voici le "intergiciel d'emballage" auquel vous faites référence, https://github.com/corydolphin/flask-cors/issues/67, vous pouvez voir que nous ne pouvons pas faire grand-chose à ce sujet à moins que des éléments de niveau inférieur de Werkzeug n'aient été modifiés.

Je suppose que @untitaker n'a pas jeté un œil au code source que j'ai lié ? Voici une capture d'écran :

@lambdaq maintenant tu es méchant avec @untitaker

tout middleware qui entoure une application enveloppée de débogage peut modifier le comportement de start_response - même pour le débogueur - de sorte que le code que vous avez collé et lié semble complètement hors de propos,
puisqu'un middleware cors enveloppant pourrait juste le changer

peut-être que je manque votre problème exact, en raison d'une perspective/compréhension différente, veuillez décrire le cas d'utilisation exact qui semble cassé/impossible

La situation est un peu compliquée car le middleware du débogueur est appliqué lors de l'appel de app.run. Vous pouvez néanmoins contourner ce problème en appliquant manuellement à la fois votre CORS et le middleware du débogueur. IMO, c'est bien pour un tel edgecase, mais si vous avez des propositions concrètes pour changer le middleware du débogueur d'une manière qui ne compromet pas la sécurité, veuillez les suggérer. Je ne connais pas de changements faciles cependant.

De plus, je connais bien le code de Werkzeug. Je suppose que c'est pourquoi je le maintiens?

désolé, je m'excuse pour ma langue, Werkzeug est un projet génial.

Je suppose que je dois juste modifier ces lignes start_response() et ajouter l'en-tête bruteforce CORS pour mon environnement de développement, c'est plus pratique qu'un middleware velue.

Vous pouvez également envisager d'ajouter du code JS supplémentaire à la place qui redirige vers le débogueur si une réponse 500 revient.

Le code

De plus, le code js est un réactj compilé avec des tonnes de trucs, développé par une autre équipe, cela prend 300s+ à npm run dev . Pas facile à modifier ou à ajouter quelques lignes de débogage.

Je pense que #1699 résout cela. Bien que Werkzeug puisse faire plus que dans #1699, je pense qu'il devrait simplement fournir des méthodes d'accès (comme pour le contrôle du cache) et permettre aux outils construits dessus (par exemple Flask-CORS ou Quart-CORS) de faire la logique CORS.