Werkzeug: Soporte CORS

Werkzeug ya es compatible con CORS, ya que puede configurar los encabezados de las respuestas que devuelve en su aplicación WSGI. No estoy seguro de qué más se puede o se debe hacer dentro de Werkzeug para "apoyar a CORS", ¿puede darnos más detalles sobre eso?

No soy el OP, pero dado que CORS es prácticamente una inyección de encabezado estándar, quizás sea una buena idea tenerlo como configuración / parámetro. Algo parecido a este fragmento , aunque aquí, en particular, no hay OPCIONES, por lo que la verificación previa será problemática ...

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

... ya conoces el mantra de python: "pilas incluidas" ...;)

Pero CORS es más que permitir * , especialmente cuando usa cookies y esas cosas. Personalmente, uso un middleware WSGI de 20 LoC para agregar encabezados CORS y responder a la solicitud de verificación previa. No es tan dificil.

@posativ - ¿

De forma muy limitada:

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

Puede ampliar esta clase para incluir encabezados personalizados, credenciales y comodines.

@posativ - Gracias por esto, lo intentaré a principios de la semana que viene cuando reanude el trabajo en ese proyecto. :)

Necesito aumentar esto.

Pregunta relativa http://stackoverflow.com/questions/19382431/set-header-on-werkzeug-exception

Línea relacionada: https://github.com/pallets/werkzeug/blob/master/werkzeug/debug/__init__.py#L297

start_response('500 INTERNAL SERVER ERROR', hace que sea difícil agregar un encabezado CORS como Access-Control-Allow-Origin: * . Pero, curiosamente, ya tenemos X-XSS-Protection: 0 allí.

Tengo Flask-CORS habilitado, he estado depurando una llamada API remota ajax complicada en Chrome, cuando Flask tiene una excepción, no puedo ver el contenido de depuración debido a CORS. ¿Podemos agregar este encabezado en el modelo de depuración?

¿Por qué querría establecer un encabezado CORS en el depurador? ¿Y por qué no puedes hacer eso con un middleware envolvente?

También quiero cerrar esto ya que no creo que necesitemos agregar todos los middleware a werkzeug.

@unititaker

¿Por qué querría establecer un encabezado CORS en el depurador?

Debido a que es un escenario complicado invocado por una solicitud AJAX entre dominios, solo se puede depurar en Chrome DevTool después de una serie de activación de eventos de javascript, si no hay un encabezado CORS, Chrome DevTool no muestra ningún contenido. No puedo ver nada. Solo puedo mirar una página en blanco con un error de servidor 500.

¿Y por qué no puedes hacer eso con un middleware envolvente?

porque el middleware empaquetado funciona solo con páginas NORMAL (aplicación Flask devuelta correctamente), pero no funciona en absoluto cuando ocurre el depurador de excepciones Werkzeug.

Aquí está el "middleware de envoltura" al que se refiere, https://github.com/corydolphin/flask-cors/issues/67 , puede ver que no podemos hacer mucho al respecto a menos que se modifiquen las cosas de Werkzeug de nivel inferior.

Supongo que @untitaker no vinculé . Aquí hay una captura de pantalla:

@lambdaq ahora estás siendo malo con @untitaker

cualquier middleware que envuelva una aplicación de depuración puede cambiar el comportamiento start_response, incluso para el depurador, por lo que el código que pegó y vinculó parece completamente irrelevante,
ya que un envoltorio de middleware de Cors podría cambiarlo

tal vez me esté perdiendo su problema exacto, debido a una perspectiva / comprensión diferente, describa el caso de uso exacto que parece roto / imposible

La situación se complica un poco porque el middleware del depurador se aplica al llamar a app.run. Aún así, puede solucionar esto aplicando tanto su CORS como el middleware del depurador manualmente. En mi opinión, esto está bien para tal caso de borde, pero si tiene propuestas concretas para cambiar el middleware del depurador de una manera que no comprometa la seguridad, sugiérales. Sin embargo, no conozco cambios fáciles.

También conozco bien el código en Werkzeug. ¿Supongo que por eso lo mantengo?

lo siento, me disculpo por mi lenguaje, Werkzeug es un proyecto increíble.

Supongo que solo tengo que editar estas líneas start_response() y agregar la fuerza bruta del encabezado CORS para mi entorno de desarrollo, es más conveniente que un middleware peludo.

También podría considerar agregar código JS adicional en su lugar que redirija al depurador si regresa una respuesta 500.

El código

Además, el código js es reaccionario compilado peludo con toneladas de cosas, desarrollado por otro equipo, toma 300s + a npm run dev . No es fácil de modificar o agregar algunas líneas de depuración.

Creo que el número 1699 resuelve esto. Si bien Werkzeug podría hacer más de lo que está en el # 1699, creo que solo debería proporcionar métodos de acceso (como para el control de caché) y permitir que las herramientas integradas (por ejemplo, Flask-CORS o Quart-CORS) hagan lógica CORS.