Werkzeug: CORS 支持

Werkzeug 已经支持 CORS，因为您可以在 WSGI 应用程序中返回的响应上设置标头。 我不确定在 Werkzeug 中还可以或应该做什么来“支持 CORS”，您能详细说明一下吗？

我不是 OP，但由于 CORS 几乎是样板头文件注入，因此将其作为设置/参数可能是个好主意。 沿着这个片段的路线，虽然这里 - 值得注意的是没有选项，所以预检会有问题......

    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 不仅仅是允许* ，尤其是当您使用 cookie 和其他东西时。 就个人而言，我使用 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 :

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请求调用的棘手场景，在一系列javascript事件触发后只能在Chrome DevTool中调试，如果没有CORS header，Chrome DevTool根本不显示任何内容。 我什么都看不到。 我只能盯着一个带有 500 服务器错误的空白页面。

为什么你不能用包装中间件来做到这一点？

因为包装的中间件仅适用于NORMAL （正确返回的 Flask 应用程序）页面，但在 Werkzeug 异常调试器发生时根本不起作用。

这是您所指的“包装中间件”， https://github.com/corydolphin/flask-cors/issues/67您可以看到我们对此无能为力，除非对较低级别的 Werkzeug 进行了调整。

我认为@untitaker没有查看我链接的源代码？ 这是一个屏幕截图：

@lambdaq现在你对@untitaker 很刻薄

任何环绕调试包装应用程序的中间件都可以更改 start_response 行为 - 即使对于调试器 - 因此您粘贴和链接的代码似乎完全无关，
因为环绕的 cors 中间件可以改变它

也许我错过了您的确切问题，由于不同的观点/理解，请概述似乎已损坏/不可能的确切用例

情况有点棘手，因为在调用 app.run 时应用了调试器中间件。 您仍然可以通过手动应用 CORS 和调试器中间件来解决此问题。 IMO 这对于这样的边缘情况很好，但是如果您有以不损害安全性的方式更改调试器中间件的具体建议，请提出建议。 我不知道任何简单的变化。

我也很清楚 Werkzeug 中的代码。 我想这就是我维护它的原因？

对不起，我为我的语言道歉，Werkzeug 是一个很棒的项目。

我想我只需要猴子编辑这些start_response()行并为我的开发环境添加 CORS 标头暴力破解，它比毛茸茸的中间件更方便。

此外，您可能会考虑添加额外的 JS 代码，而不是在 500 响应返回时重定向到调试器。

@untitaker JS 代码什么也做不了，如果有 500 错误，你只能告诉它的 http 状态代码是 500，调试器页面的回溯就是我所追求的。

js 代码也是由另一个团队开发的大量编译的 reactjs 代码，需要 300 秒+ 到npm run dev 。 不容易调整或添加少量调试行。

我认为#1699 解决了这个问题。 虽然 Werkzeug 可以做的比 #1699 中的多，但我认为它应该只提供访问器方法（例如用于缓存控制）并允许构建在其上的工具（例如 Flask-CORS 或 Quart-CORS）执行 CORS 逻辑。