Werkzeug: Поддержка CORS

Werkzeug уже поддерживает CORS в том смысле, что вы можете устанавливать заголовки для ответов, которые вы возвращаете в своем приложении WSGI. Я не уверен, что еще можно или нужно сделать в Werkzeug для «поддержки CORS», не могли бы вы об этом подробнее?

Я не ОП, но поскольку 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://github.com/pallets/werkzeug/blob/master/werkzeug/debug/__init__.py#L297

start_response('500 INTERNAL SERVER ERROR', затрудняет добавление заголовка CORS, например Access-Control-Allow-Origin: * . Но любопытно, что у нас там уже есть X-XSS-Protection: 0 .

У меня включен Flask-CORS, я отлаживаю сложный удаленный вызов API-интерфейса ajax в Chrome, когда во Flask возникает исключение, я не могу видеть содержимое отладки из-за CORS. Можем ли мы добавить этот заголовок в модель отладки?

Зачем вам нужно устанавливать заголовок CORS в отладчике? И почему вы не можете сделать это с помощью промежуточного программного обеспечения для упаковки?

Также я хочу закрыть это, так как я не думаю, что нам нужно добавлять все промежуточное ПО в werkzeug.

@unititaker

Зачем вам нужно устанавливать заголовок CORS в отладчике?

Поскольку это сложный сценарий, вызываемый междоменным запросом AJAX, он может только отлаживать его в Chrome DevTool после серии срабатываний событий javascript, если заголовок CORS отсутствует, Chrome DevTool вообще не отображает какой-либо контент. Я ничего не вижу. Я могу только смотреть на пустую страницу с ошибкой сервера 500.

И почему вы не можете сделать это с помощью промежуточного программного обеспечения для упаковки?

потому что обернутое промежуточное ПО работает только с НОРМАЛЬНЫМИ (правильно возвращаемым приложением Flask) страницами, но не работает вообще, когда происходит отладчик исключений Werkzeug.

Вот «промежуточное программное обеспечение для упаковки», о котором вы говорите, https://github.com/corydolphin/flask-cors/issues/67, вы можете видеть, что мы ничего не сможем с этим поделать, если не будет изменен материал Werkzeug более низкого уровня.

Я полагаю, @untitaker не взглянул на исходный код, на который я ссылался? Вот скриншот:

@lambdaq теперь ты злишься на

любое промежуточное ПО, которое оборачивается вокруг обернутого отладкой приложения, может изменить поведение start_response - даже для отладчика - поэтому вставленный и связанный код кажется совершенно неактуальным,
так как мидл-посуда Cors может просто изменить его

возможно, мне не хватает вашей точной проблемы, из-за другой точки зрения / понимания, пожалуйста, укажите точный вариант использования, который кажется сломанным / невозможным

Ситуация немного усложняется, потому что промежуточное ПО отладчика применяется при вызове app.run. Тем не менее, вы можете обойти это, применив как CORS, так и промежуточное ПО отладчика вручную. ИМО, это нормально для такого крайнего случая, но если у вас есть конкретные предложения по изменению промежуточного программного обеспечения отладчика таким образом, чтобы не ставить под угрозу безопасность, пожалуйста, предложите их. Хотя я не знаю легких изменений.

Также мне хорошо известен код Werkzeug. Думаю, поэтому я поддерживаю это?

извините, я прошу прощения за мой язык, Werkzeug - потрясающий проект.

Я думаю, мне просто нужно обезьяно отредактировать эти строки start_response() и добавить брутфорс заголовка CORS для моей среды разработки, это удобнее, чем волосатое промежуточное ПО.

Также вы можете подумать о добавлении дополнительного JS-кода, который перенаправляет на отладчик, если возвращается ответ 500.

Код @untitaker JS ничего не может сделать, если есть ошибка 500, вы можете только сказать, что его код состояния http равен 500, трассировка со страницы отладчика - это то, что мне нужно.

Кроме того, код js представляет собой скомпилированный код реагирования с множеством вещей, разработанный другой командой, требуется 300 с + до npm run dev . Нелегко настроить или добавить несколько строк отладки.

Я думаю, что # 1699 решает эту проблему. Хотя Werkzeug может делать больше, чем в # 1699, я думаю, он должен просто предоставлять методы доступа (например, для управления кешем) и позволять инструментам, построенным на нем (например, Flask-CORS или Quart-CORS), выполнять логику CORS.