Werkzeug: Suporte CORS

Criado em 3 nov. 2011  ·  16Comentários  ·  Fonte: pallets/werkzeug

Seria bom dar suporte ao CORS [1] [2]

até mesmo arquivos estáticos precisam suportá-lo

[1] http://www.w3.org/TR/cors/
[2] http://enable-cors.org/

Comentários muito úteis

Também quero fechar isso, pois não acho que precisamos adicionar todos os middlewares ao werkzeug.

Todos 16 comentários

O Werkzeug já oferece suporte ao CORS, pois você pode definir os cabeçalhos nas respostas que retornar em seu aplicativo WSGI. Não tenho certeza do que mais pode ou deve ser feito no Werkzeug para "dar suporte ao CORS", você pode explicar melhor?

Eu não sou o OP, mas como o CORS é basicamente uma injeção de cabeçalho padrão, talvez seja uma boa ideia tê-lo como uma configuração / parâmetro. Algo na linha deste trecho , embora aqui - notavelmente não haja OPÇÕES, então o preflight será problemático ...

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

... você conhece o mantra python: "baterias incluídas" ...;)

Mas o CORS é mais do que permitir * , especialmente quando você usa cookies e outras coisas. Pessoalmente, eu uso um middleware 20 LoC WSGI para adicionar cabeçalhos CORS e responder à solicitação de comprovação. Não é tão difícil.

@posativ -

De uma forma muito 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/")

Você pode estender esta classe para incluir cabeçalhos personalizados, credenciais e curingas.

@posativ - Obrigado por isso, tentarei no início da semana que vem, quando retome o trabalho nesse projeto. :)

Precisa melhorar isso.

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

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

o start_response('500 INTERNAL SERVER ERROR', torna difícil adicionar um cabeçalho CORS como Access-Control-Allow-Origin: * . Mas, curiosamente, já temos X-XSS-Protection: 0 lá.

Eu tenho Flask-CORS habilitado, depurando uma complicada chamada remota de API ajax no Chrome, quando o Flask tem uma exceção, não consigo ver o conteúdo de depuração por causa do CORS. Podemos adicionar este cabeçalho no modelo de depuração?

Por que você deseja definir um cabeçalho CORS no depurador? E por que você não pode fazer isso com um middleware de embalagem?

Também quero fechar isso, pois não acho que precisamos adicionar todos os middlewares ao werkzeug.

@unititaker

Por que você deseja definir um cabeçalho CORS no depurador?

Por ser um cenário complicado invocado por solicitação AJAX de domínio cruzado, só é possível depurá-lo no Chrome DevTool após uma série de disparos de eventos javascript, se não houver cabeçalho CORS, o Chrome DevTool não exibe nenhum conteúdo. Não consigo ver nada. Só consigo olhar para uma página em branco com 500 erro de servidor.

E por que você não pode fazer isso com um middleware de embalagem?

porque o middleware empacotado funciona apenas com páginas NORMAL (aplicativo Flask adequado), mas não funciona quando o depurador de exceção Werkzeug acontece.

Aqui está o "middleware de embrulho" ao qual você está se referindo, https://github.com/corydolphin/flask-cors/issues/67 , você pode ver que não podemos fazer muito a respeito, a menos que o material Werkzeug de nível inferior seja ajustado.

Presumo que vinculei ? Aqui está uma captura de tela:

qq20160420-3

@lambdaq agora você está sendo mau com @untitaker

qualquer middleware que envolva um aplicativo empacotado de depuração pode alterar o comportamento de start_response - mesmo para o depurador - então o código que você colou e vinculou parece completamente irrelevante,
uma vez que um middleware da Cors envolvendo poderia apenas mudá-lo

talvez eu esteja perdendo seu problema exato, devido à perspectiva / compreensão diferente, descreva o caso de uso exato que parece quebrado / impossível

A situação torna-se um pouco complicada porque o middleware do depurador é aplicado ao chamar app.run. Ainda assim, você pode contornar isso aplicando o CORS e o middleware do depurador manualmente. IMO, isso é bom para tal caso de edição, mas se você tiver propostas concretas para alterar o middleware do depurador de uma forma que não comprometa a segurança, por favor, sugira-as. Não conheço nenhuma mudança fácil.

Além disso, estou bem ciente do código em Werkzeug. Acho que é por isso que estou mantendo isso?

desculpe, peço desculpas pela minha linguagem, Werkzeug é um projeto incrível.

Acho que só preciso editar essas start_response() linhas e adicionar a força bruta do cabeçalho CORS ao meu ambiente de desenvolvimento, é mais conveniente do que um middleware cabeludo.

Além disso, você pode considerar adicionar código JS extra em vez de redirecionar para o depurador se uma resposta 500 voltar.

O código

além disso, o código js é uma reação complicada compilada com toneladas de material, desenvolvida por outra equipe, leva 300s + a npm run dev . Não é fácil ajustar ou adicionar algumas linhas de depuração.

Acho que # 1699 resolve isso. Embora o Werkzeug possa fazer mais do que no # 1699, acho que ele deve apenas fornecer métodos de acesso (como para controle de cache) e permitir que ferramentas construídas nele (por exemplo, Flask-CORS ou Quart-CORS) façam a lógica CORS.

Esta página foi útil?
0 / 5 - 0 avaliações