Requests: verificar = False e requests.packages.urllib3.disable_warnings ()

Acho que você pode desabilitá-los em um nível global com o módulo warnings . Além disso, para trabalhar com registro (se bem me lembro), você precisa acessar urllib3 (e nós documentamos isso), então não sou contra documentar isso para usuários que não usarão a verificação de certificado para HTTPS conexões.

Continuo fortemente a favor de deixar esses avisos em vigor. Sim, eles são irritantes, mas também existem por um motivo. No mínimo, fico tentado a desligá-lo e substituí-lo por um dos nossos! = P

Neste ponto, é bastante óbvio que @Lukasa e eu temos -1 neste recurso. @kennethreitz @shazow alguma opinião?

Até certo ponto, concordo que os avisos são importantes, mas acho que há vários fatores que precisam ser considerados.

Da perspectiva do desenvolvedor, sei que eu sei sobre isso, posso simplesmente desligar se eu quiser. Eu sou mais novo em pacotes, então quando li a documentação, no aviso, essa solução realmente não funcionou. Gosto da ideia que @Lukasa apresentou sobre fazer algo específico para requests .

Da perspectiva do usuário, instalei pyvmomi com pip hoje, que usa requests em seus internos. É realmente um erro não transparente que é emitido de volta para o usuário em um caso em que requests é uma biblioteca de suporte silenciosa.

Sim, requests.packages.urllib3.disable_warnings() é um atalho para desligá-lo usando a filtragem do módulo de avisos.

Eu recomendo fortemente ter algum tipo de aviso para esse efeito. +0.5 em ter o urllib3 propagado, +1 se você quiser se esforçar e adicionar um pedido específico. -1 por não ter nenhum aviso.

Se desejar, podemos tornar a mensagem de aviso urllib3 configurável e você pode substituí-la para que possa pegar carona na mesma lógica de outra forma.

Mais uma vez, não considero esta mensagem hostil ao usuário, considero-a extremamente valiosa. Agora você sabe que pyvmomi desativou a verificação de certificado TLS, o que é uma informação bastante importante!

Dito isso, não me oponho a termos uma maneira mais solicitada de silenciá-lo.

Sim, realmente acho que este é um bug em pyvmomi . Se eles não querem ficar envergonhados assim, eles devem desabilitar os avisos em sua ferramenta. Não é nosso trabalho _não_ avisar aos usuários que as conexões que alguma ferramenta está fazendo podem expô-los a ataques MITM porque a ferramenta não está realizando verificação de certificado.

Obrigado pela discussão pessoal! Agradeço a todos que comentaram e me ajudaram a ver o valor na maneira como as coisas são feitas e por quê. Eu estava tendo dificuldade em ver os casos mais gerais! :)

Trabalhará em um patch hoje, se o tempo permitir, para ter uma maneira 'requisitada' de silenciar. O feedback será bem-vindo!

@invisiblethreat sinta-se à vontade para entrar no IRC se tiver perguntas

Gostaria de saber se você considerou o caso em que as solicitações são usadas em um webhook. Tenho que suprimir o aviso para que não polua a saída JSON do script (ou estou faltando alguma coisa?)

@macterra Não tenho certeza se entendi. Você está procurando estratégias alternativas para desativar o aviso ou ...?

Também não está extremamente claro para mim por que seu webhook está desativando a verificação de certificado. Eu gostaria de deixar isso ligado.

Além disso, se você estiver canalizando stdout de algum script para obter os resultados, avisos virão de stderr para que não poluam sua saída JSON.

Certo, se o aviso estiver em stderr, não há problema. Eu não poderia dizer olhando para a saída no console, erro meu.

Acho que devemos personalizar isso para apontar para a documentação das solicitações em vez da documentação do urllib3.

Não tenho certeza se entendi o que esse recurso de aviso se destina a atingir e como o aviso deve ser controlado.

Eu tenho um módulo que usa requests e tem que fazer solicitações com o argumento verify=False . Isso faz com que os usuários do meu módulo vejam o aviso desnecessário. Avisos desnecessários tornam os avisos importantes mais difíceis de ver,

Faria sentido que meu módulo desabilitasse o aviso, mas então _Eu estaria desabilitando o aviso também em qualquer outro módulo_ usando requests no aplicativo!

As coisas não vão melhorar se eu precisar instruir o usuário do meu módulo a desabilitar o aviso: O fato de que estou usando requests normalmente é apenas um detalhe de implementação invisível que o usuário não deve precisar saber. E o usuário ainda só teria a opção de silenciar tudo ou anotar.

Não acho que os alertas globais sejam úteis.

Eu poderia subclasse urllib3.HTTPSConnectionPool e substituir _validate_conn() e fazer requests usar isso em meu módulo para evitar esconder avisos de outros módulos, mas isso parece ser muito trabalhoso para uma coisa simples .

Não tenho certeza se entendi o que esse recurso de aviso se destina a alcançar

faz com que os usuários do meu módulo vejam o aviso desnecessário.

Ao definir verify=False você não estará mais protegendo suas conexões de rede. Isso, IMHO, _não_ é um aviso desnecessário, é um aviso extremamente relevante. Seus usuários, que antes não sabiam que você não estava verificando certificados, agora sabem que isso é verdade.

Se o aviso não for valioso para o seu módulo, provavelmente não será valioso para qualquer outro módulo do aplicativo (uma vez que você jogou fora a segurança em um ponto de rede, não há motivo para exagerar em todos os outros). Não vejo problema em desativá-lo globalmente.

Quando o usuário solicita explicitamente verify=False para uma solicitação específica, não vejo o valor de mostrar um aviso. Quando eu, como autor do módulo, defino verify=False , defino por solicitação do usuário (ou estou sendo malicioso, mas o aviso também não ajuda, porque posso silenciar os avisos). Na verdade, eu quero evitar ser malicioso e não quero silenciar globalmente os avisos, porque isso tira o aviso útil para essas solicitações que alguma outra parte do aplicativo está fazendo de forma insegura sem saber.

Além disso, ter o aviso ativado para as solicitações em que a verificação é explicitamente desativada pelo usuário também oculta as solicitações em que o usuário gostaria de receber o aviso, uma vez que o aviso é dado apenas uma vez. O aviso também não é muito útil para o usuário, pois não menciona o URL da solicitação específica.

Não concordo que jogar fora a segurança em um ponto de rede de alguma forma torne as verificações de segurança inúteis no aplicativo, nem mesmo os fornecedores de navegadores. Os navegadores me permitem ignorar as verificações de segurança de URLs individuais, mas continuo verificando o resto e gosto disso.

Quando tenho uma ferramenta que se comunica com um servidor interno com um certificado autoassinado em uma rede interna, mas também se comunica com hosts externos, quero verificar a comunicação externa. Essa seria a situação em que eu gostaria, como usuário, de ver avisos sobre solicitações acidentalmente desprotegidas.

Considere que estou ganhando service_foo e alguém usa em um aplicativo:

import service_foo
import requests

session = service_foo.Session('https://10.0.0.1', verify=False)
data = session.get_data()
requests.put('https://example.com/submit', data=data)

Tenho 2 opções para service_foo :

1. Eu mantenho o alerta de segurança global
   
   
   
   • O usuário sempre recebe um aviso quando o aplicativo fala com https://10.0.0.1
   
   
   • O usuário nunca recebe um aviso, mesmo se a solicitação de https://example.com/submit não for segura
   
   
2. Desative o aviso de segurança global:
   
   
   
   • O usuário nunca recebe um aviso, mesmo se a solicitação de https://example.com/submit não for segura
   
   

Não acho que nenhuma das opções seja boa, mas a opção 1 é pior, porque está dando falsos alarmes. Mas não me sinto confortável em ter as verificações de segurança desativadas para o usuário como um efeito colateral do uso do meu módulo.

Se eu fizesse isso com um script de shell, o usuário ficaria mais feliz e seguro:

curl --insecure -o data https://10.0.0.1/get_data
curl --upload-file data https://example.com/submit

Para mim só faz sentido avisar se a configuração da plataforma Python estiver quebrada. A página https://urllib3.readthedocs.org/en/latest/security.html vinculada na mensagem InsecureRequestWarning é realmente voltada para mostrar como corrigir problemas na plataforma. Se o usuário solicitar para ignorar a verificação, não deve haver um aviso como se não houvesse um aviso se o usuário solicitar uma URL http vez de https one.

Quando o usuário solicita explicitamente verify = False para uma solicitação específica, não vejo o valor de mostrar um aviso.

Quem é o 'usuário'? Ao longo de sua postagem, essa pergunta não parava de vir à minha mente, porque acredito que você está confundindo dois públicos.

Quando eu, como autor do módulo, defino verify = False, defino por solicitação do usuário (ou estou sendo malicioso).

Ou você está sendo negligente. Você já teve usuários reclamando que não podiam interoperar com seus certificados autoassinados e, portanto, desativou a verificação de certificado, apesar do fato de que desligar a verificação de certificado _não_ é a maneira de lidar com esse problema.

que tira o aviso útil para essas solicitações, alguma outra parte do aplicativo está tornando insegura sem saber

Esta frase me deixa perplexo. Isso sugere que é aceitável avisar quando um aplicativo _desconhecidamente_ faz solicitações inseguras, mas que um aplicativo _conscientemente_ fazendo-as de alguma forma está OK. Não vejo como fazer solicitações inseguras intencionalmente deva ser considerado 'mais seguro' do que fazê-lo sem saber.

Além disso, ter o aviso ativado para as solicitações em que a verificação é explicitamente desativada pelo usuário

Qual usuário? Como devemos distinguir entre o autor do módulo e o 'usuário', sejam eles quem forem?

O aviso também não é muito útil para o usuário, pois não menciona o URL da solicitação específica.

O aviso não deve mencionar o URL da solicitação, pois isso poderia gerar um spam de aviso. Avisamos _uma vez_, dizendo 'este aplicativo está em risco', e não 'esta comunicação específica está em risco'.

Os navegadores me permitem ignorar as verificações de segurança de URLs individuais, mas continuo verificando o resto e gosto disso.

Os fornecedores de navegador _warn_ quando você acessa um URL com um certificado inválido! Eles imprimem caixas de diálogo e destacam a barra de URL em vermelho! Isso é _exatamente_ o que estamos fazendo. Não estamos impedindo você de fazer nada, estamos apenas dizendo "ei, isso é ruim!" O que você está nos pedindo é o mesmo que pedir aos fornecedores de navegadores que permitam aos usuários desligar aquele aviso vermelho para URLs específicos, e eu garanto que eles se recusarão a fazer isso porque as implicações de segurança são monstruosas.

Quando tenho uma ferramenta que se comunica com um servidor interno com um certificado autoassinado em uma rede interna, mas também se comunica com hosts externos, quero verificar a comunicação externa.

Não, você deseja verificar _todas_ as comunicações. Verifique o certificado autoassinado! Valide se você obteve o certificado que esperava obter. verify=False deve ser considerado uma abordagem de marreta para a segurança, efetivamente dizendo "parafuse a segurança, apenas faça funcionar". Tudo bem, você tem o direito de dizer isso, mas temos a obrigação de chamá-lo de inseguro.

Não acho que nenhuma das opções seja boa, mas a opção 1 é pior, porque está dando falsos alarmes.

A opção 1 não está dando alarmes falsos, está dando alarmes reais. A comunicação para 10.0.0.1 é _insegura_ e não devemos fingir o contrário.

Se eu fizesse isso com um script de shell, o usuário ficaria mais feliz e seguro.

O usuário pode ficar mais feliz, mas não estaria mais seguro. Eles estariam exatamente tão seguros quanto antes. Você parece ter a impressão de que desligar esse aviso de alguma forma faz com que a verificação do certificado desapareça, e isso não acontece. Vou tocar nisso novamente no final desta resposta.

Para mim só faz sentido avisar se a configuração da plataforma Python estiver quebrada.

Não, devemos falhar muito se a configuração da plataforma Python estiver quebrada e você não solicitar solicitações não verificadas. Se a sua plataforma não pode fazer conexões TLS seguras, então absolutamente não devemos fazê-las, exceto na situação em que nosso usuário nos diga expressamente para não nos importarmos (definindo verify=False ), caso em que devemos avisar que o que você está prestes a fazer é perigoso.

Acho que você está tendo um mal-entendido, então gostaria de deixar algo muito claro: não há como fazer uma solicitação HTTPS não validada com solicitações sem a) definir verify=False (nosso comportamento de advertência) ou b) sabotar deliberadamente o módulo ssl . Não podemos pegar b) e não avisar sobre isso. Esta é a única situação que se enquadraria na noção que você levantou de "problemas com a plataforma". O conselho na página de ajuda do urllib3 não se aplica a nós porque tomamos todas as etapas necessárias relacionadas à plataforma, incluindo empacotar certificados confiáveis ​​e verificar manualmente os certificados.

Há uma visão perigosa na comunidade da web de que você só deve verificar os certificados assinados por certificados raiz confiáveis. Essa visão é totalmente equivocada. Se estiver encontrando certificados autoassinados, você deve muito bem validá-los. Isso é totalmente capaz de fazer! Adicione o certificado autoassinado a um arquivo .pem e passe-o como um argumento para verify !

Se você estiver tendo problemas para combinar isso com o arquivo .pem empacotado, por favor me avise e eu irei aprimorar o mkcert.org para permitir que você concatene seus próprios certificados com as raízes confiáveis. Mas, por favor, não finja que definir verify=False é seguro: simplesmente não é.

Além disso, ter o aviso ativado para as solicitações em que a verificação é explicitamente desativada pelo usuário também oculta as solicitações em que o usuário gostaria de receber o aviso, uma vez que o aviso é dado apenas uma vez.

Isso também é um pouco desconcertante. Ao definir verify=False você pode desativá-lo explicitamente apenas para aquela solicitação, mas não há como transmitir isso além do ponto em que construímos nossa solicitação. Também não há razão para transmitir isso além desse ponto, porque você desativou a verificação de certificado. O contexto em que você fez isso não tem importância para nós ou para qualquer pessoa que use seu aplicativo.

O que você está nos pedindo é o mesmo que pedir aos fornecedores de navegadores que permitam aos usuários desligar aquele aviso vermelho para URLs específicos, e eu garanto que eles se recusarão a fazer isso porque as implicações de segurança são monstruosas.

Meus navegadores me permitem aceitar permanentemente um certificado não verificado, que é "monstruosamente inseguro".

A comunicação para 10.0.0.1 é insegura e não devemos fingir o contrário.

A conexão é insegura de forma que você não pode verificar um certificado digital, mas verificar um certificado não diz realmente se o servidor com o qual você está falando é seguro. Mas quando estou falando com um servidor em uma rede fechada, posso realmente garantir a segurança do servidor.

Acho que você está tendo um mal-entendido, então gostaria de deixar algo muito claro: não há como fazer uma solicitação HTTPS não validada com solicitações sem a) configuração verify = False (nosso comportamento de advertência) ou b) deliberadamente sabotando o SSL

Estou tentando me perguntar como eu poderia ser um bom cidadão em meu módulo, honrando o desejo do usuário de ignorar verificações de certificado e avisos para a URL que eles fornecem para mim. E que valor o modelo de aviso agrega. Qual é o caso em que uma solicitação com verify=False deveria mostrar um aviso ao usuário?

Não vejo como o mecanismo de aviso pode detectar código negligente, uma vez que não consegue distinguir se uma solicitação é feita por causa de uma codificação malfeita ou porque um usuário solicitou isso. Também não acho que um módulo como requests deva ditar uma política de segurança. Eu entendi que os avisos geralmente são direcionados aos desenvolvedores para que eles possam corrigir o código incorreto, mas este aviso não é assim. Se o aviso for apenas para educação geral do usuário, deve haver uma maneira fácil para o usuário ocultá-lo.

Receber o aviso não é apenas cosmético, porque bagunça a saída de um programa.

Vejo apenas o valor negativo do aviso, por isso estou desativando-o no meu módulo, mesmo que odeie ocultar essa mudança de política global lá.

Há uma visão perigosa na comunidade da web de que você só deve verificar os certificados assinados por certificados raiz confiáveis. Essa visão é totalmente equivocada.

Não sabia que havia uma vista assim. Um certificado assinado por um certificado raiz não prova nada sobre a segurança do site. É barato obter um certificado anônimo se você quiser fazer coisas ruins.

Se estiver encontrando certificados autoassinados, você deve muito bem validá-los. Isso é totalmente capaz de fazer! Adicione o certificado autoassinado a um arquivo .pem e passe-o como um argumento para verificação!

O usuário precisaria de um canal seguro para obter o certificado, como uma rede interna confiável. Mas se o próprio servidor estiver na mesma rede interna, não há muito ganho. Mas isso é em todo caso algo que o usuário decide, não posso impor uma política no meu módulo.

Eu concordo com @kankri , na maior parte. Essa foi a intenção do projeto original.

Eu proponho algo - que desabilitamos por padrão, mas temos nossa própria função para reativá-lo ou documentar como ativá-lo. Não quero que os usuários saiam do caminho para usar o código como pretendido. verify=False é um recurso, embora não seja uma das melhores práticas. Isso não é da nossa conta.

Eu concordo que verify=False é um recurso, mas não concordo que seja um recurso no mesmo nível que params= ou cert= . É um recurso cujo padrão é um valor seguro e pode ser definido como inseguro. É uma opção gigantesca e tentadora para as pessoas jogarem a segurança pela janela por uma questão de conveniência, e acho que esse impulso deve ser resistido (mas não rejeitado). Eu sempre vou me inclinar para a escola de pensamento 'você deve explicitamente ser inseguro', e não me importo se isso significa apertar dois botões e não um.

Independentemente disso, esta é sua chamada, não minha. =)

Só queria dizer que concordo com @kankri e que a observação de @kennethreitz

verify = False é um recurso, embora não seja uma das melhores práticas. Isso não é da nossa conta.

resume bem.

Para quem também deseja desabilitar os avisos, veja como fazer. Você precisa usar os módulos de avisos , que fazem parte da biblioteca padrão:

import warnings
import requests
from requests.packages.urllib3 import exceptions

with warnings.catch_warnings():
    warnings.simplefilter("ignore", exceptions.InsecureRequestWarning)
    warnings.warn('a non-requests warning is not blocked')
    print requests.get('https://rsa-md5.ssl.hboeck.de/', verify=False)

Isso configura um filtro de aviso que irá ignorar qualquer aviso da categoria InsecureRequestWarning . A saída é semelhante a:

test.py:46: UserWarning: a non-requests warning
  warnings.warn('a non-requests warning is not blocked')
<Response [403]>

(O site de teste retorna uma página 403 Proibido, mas isso não é importante aqui.)

Observe que você precisa usar a classe do pacote urllib3 , e não a classe de um pacote urllib3 de nível superior, se acontecer de você ter um instalado.

Você pode (e provavelmente deve) fazer uma pequena função que usa o gerenciador de contexto na menor região de código possível:

def silent_unverified_get(*args, **kwargs):
    kwargs['verify'] = False
    with warnings.catch_warnings():
        warnings.simplefilter("ignore", exceptions.InsecureRequestWarning)
        return requests.get(*args, **kwargs)

Ou simplesmente faça isto:

requests.packages.urllib3.disable_warnings()

@Lukasa

Ou simplesmente faça isto:

requests.packages.urllib3.disable_warnings()

Exceto que não encontro nenhuma menção a essa função no manual de solicitações.

Embora esteja longe de todos que sabem sobre isso, eu diria que o módulo warnings _é_ a ferramenta padrão que um programador Python deve procurar quando quiser desativar os avisos. Faz parte da biblioteca padrão e está bem documentado.

Eu sugiro colocar uma referência a warnings na documentação requests - ou na função de conveniência disable_warnings se você quiser, contanto que haja uma enable_warnings função ( parece que não existe tal função ).

Mais uma vez: não quero desativar os avisos em geral. Eu só quero que este aviso específico desapareça quando eu _explicitly_ definir verify = False em meu código. Pode haver outros avisos úteis, ao contrário deste aviso específico e inútil. O que é tão difícil de entender sobre isso ?!

@zaitcev Correndo o risco de me repetir:

requests.packages.urllib3.disable_warnings()

E se mesmo isso for muito amplo para você:

from requests.packages.urllib3.exceptions import InsecureRequestWarning

requests.packages.urllib3.disable_warnings(InsecureRequestWarning)

Finalmente, uma nota, @zaitcev : você descobrirá que aceitar o tom exasperado que acabou de fazer não lhe

@zaitcev Não parece que isso vai mudar no próprio módulo de solicitações, mas espero que você possa usar o código que coloquei em meu outro comentário . Isso deve permitir que você desabilite seletivamente os avisos emitidos pelo urllib3.

Você também pode suprimi-lo com:

with warnings.catch_warnings():
  warnings.filterwarnings("ignore", message=".*InsecurePlatformWarning.*")
  ...

No meu caso, não estou usando solicitações diretamente, portanto, suprimir dessa forma me deixa um pouco menos preocupado em ser interrompido mais tarde.

@zaitcev Juntando todas as sugestões anteriores, você pode fazer algo assim:

verify = False
if not verify:
    from requests.packages.urllib3.exceptions import InsecureRequestWarning
    requests.packages.urllib3.disable_warnings(InsecureRequestWarning)
r = requests.get('https://www.example.com', verify=verify)

@utkonos Isso deixaria os avisos desabilitados para todas as solicitações subsequentes.

Juntando outros exemplos, estendi o Session padrão (já que requests.get e outros atalhos criam um Session temporário, de qualquer maneira):

from requests.packages.urllib3 import exceptions

class Session(requests.sessions.Session):

    def request(self, *args, **kwargs):
        if not kwargs.get('verify', self.verify):
            with warnings.catch_warnings():
                warnings.simplefilter('ignore', exceptions.InsecurePlatformWarning)
                warnings.simplefilter('ignore', exceptions.InsecureRequestWarning)
                return super(Session, self).request(*args, **kwargs)
        else:
            return super(Session, self).request(*args, **kwargs)

Desativar todos os avisos de requests é provavelmente uma má ideia, um pouco melhor seria:

import requests
from requests.packages.urllib3.exceptions import InsecureRequestWarning
requests.packages.urllib3.disable_warnings(InsecureRequestWarning)

Para resumir como eu lidei com isso:

import warnings
with warnings.catch_warnings():
    warnings.simplefilter("error") 
    try:
        req = requests.get("https://an-insecure-server.com")
    except (RuntimeWarning, requests.exceptions.SSLError)::
        log.error("Making an insecure request")
        warnings.simplefilter("ignore")
        req = requests.get("https://an-insecure-server.com")

Isso me permite verificar se uma solicitação é insegura, ocultar o aviso de urllib e gerar um aviso de minha própria formatação para o usuário. Exige que o pedido seja feito duas vezes. Editado para tornar a cláusula de exceção menos ampla.

except Exception: é MUITO amplo. você realmente não quer isso.

O que foi dito acima é uma forma de abordar as preocupações de ambos os lados desta discussão.

não lança alguma subclasse de Exception que você pode pegar em vez disso?

Ou use logging.captureWarnings()

A alternativa é saber que urllib3 está envolvido e codificar seu namespace, veja o comentário de tuukkamustonen. Esta foi minha principal objeção: eles poderiam ter feito funcionar direito, eu até forneci um patch em uma solicitação de pull. Mas eles negam que o problema exista e dizem a todos os usuários para criarem soluções alternativas terríveis como "exceto Exception" ou "from requests.packages.urllib3 import exceptions". Nesse ponto, alguém tem que admitir que estava errado o tempo todo e, portanto, estamos presos.

Esta foi minha principal objeção: eles poderiam ter feito funcionar direito, eu até forneci um patch em uma solicitação de pull. Mas eles negam que o problema exista e dizem a todos os usuários para criarem soluções alternativas terríveis como "exceto Exception" ou "from requests.packages.urllib3 import exceptions". Nesse ponto, alguém tem que admitir que estava errado o tempo todo e, portanto, estamos presos.

@zaitcev Mais uma vez, gostaria de lembrar que esta é uma comunidade de voluntários fazendo o melhor que podem. Deixamos esse assunto livre para discussão, não tentamos bloqueá-lo ou evitar discussões futuras. Estamos _ouvindo a você_. O que não estamos fazendo é concordar imediatamente com sua avaliação da situação. Considere a possibilidade de que nos importamos com mais casos de uso do que simplesmente os seus, e que precisamos equilibrar as necessidades de todos eles.

Quanto à sua solicitação de pull, ela foi rejeitada por uma _ razão muito específica_ que você está constantemente ignorando! Deixe-me citar a minha citação de Ian :

A declaração de encerramento foi: "Visto que isso está principalmente em urllib3 e dependeria de aceitação lá, estou encerrando isso até que haja progresso lá. " (Ênfase minha).

A partir de hoje, ainda não vejo nenhuma solicitação ou problema de pull associado a esse problema no urllib3. Ninguém deste projeto se interpôs no seu caminho ou impediu que este trabalho ocorresse, simplesmente não optamos por fazê-lo porque _não concordamos com você no momento_.

No entanto, correndo o risco de descer por esta toca do coelho novamente, deixe-me reiterar:

Esta foi minha principal objeção: eles poderiam ter feito funcionar direito.

Eu não acredito que seu patch faça este trabalho "certo" . Como já disse várias vezes neste tópico, considero o comportamento atual desejável. Fazer solicitações TLS inseguras é uma má ideia e os usuários devem ser advertidos contra isso.

Minha posição é que um usuário _deserva saber_ quando está fazendo uma solicitação TLS que não está adequadamente protegida, especialmente em qualquer sistema que esteja lidando com suas senhas.

Há um acordo neste segmento de que devemos considerar ter um gancho no nível de solicitações para desativar esses avisos. Por outro lado, atualmente ninguém além de você acredita que alguma distinção anteriormente inexistente entre verify=False e verify=None deve ser adicionada para silenciar implicitamente esses avisos. Você achará muito mais fácil fazer o primeiro do que o último.

+1 para não diferenciar entre verify = False e verify = None. Eu apoiaria:

• adicionar um novo parâmetro (digamos, noInsecureWarnings), ou
• ter solicitações interceptar o aviso urllib3 e emitir um próprio, então (a) posso suprimir algo menos assustador do que 'request.packages.urllib3.exceptions.InsecureRequestWarning' (que já é específico de solicitações de qualquer maneira, mas será interrompido se as solicitações migrarem para uma biblioteca subjacente diferente) e (b) o aviso pode apontar para um URL específico de solicitações (o URL atual não é relevante porque o aviso foi sombreado!)

E obrigado a todos os voluntários por apoiarem os pedidos, sejam corrigidos ou não: é uma ótima biblioteca :)

Esta é uma biblioteca incrível, obrigado por todo o seu trabalho árduo.

Eu me deparei com esse problema depois de atualizar meus pacotes python recentemente e notar uma série de novas impressões do InsecurePlatformWarning. Portanto, estou contribuindo com meu caso de uso, que considero atraente.

Estou usando solicitações para gerenciar servidores jenkins em 4 ambientes diferentes. Três dos ambientes (dev, staging, production) têm certificados válidos. O quarto ambiente é uma caixa virtual vagrant, que os desenvolvedores podem usar para testar mudanças em suas máquinas locais. Este não possui um certificado válido, mas por uma questão de política, todas as configurações do servidor rejeitam solicitações não criptografadas.

As configurações de conexão jenkins (nome do servidor, token, etc) para um ambiente incluem um sinalizador específico para desligar a verificação SSL, que só é definido como True para o ambiente vagrant.

Na minha configuração, desabilitar o aviso globalmente seria uma má ideia porque o projeto é bastante grande e muitas solicitações podem ser feitas, com ou sem a biblioteca de solicitações. Desativar o aviso no escopo seria bom, exceto que parte do projeto inclui um aplicativo de frasco e outros casos possivelmente multi-threaded.

Na minha opinião, parece que o uso de verify = False deve ser suportado e funcionar conforme o esperado, sem avisos. Cabe ao desenvolvedor do aplicativo decidir quando e se isso deve ser permitido. Por exemplo, se eu estivesse escrevendo um navegador para uso geral, nunca definiria isso como True sem exibir uma grande caixa de diálogo de confirmação com muito texto em vermelho. Mas se eu for o proprietário do servidor e do cliente e tiver meus próprios motivos para não emitir um certificado, devo ser capaz de ter um log limpo e não ocultar outros problemas potenciais.

Cabe ao desenvolvedor do aplicativo decidir quando e se isso deve ser permitido.

Esta afirmação é onde eu discordo de você. Acredito que cabe ao desenvolvedor decidir quando deve usá-lo. Mas acredito que cabe ao _usuário_ decidir se essa escolha é aceitável. É _crítico_ que os usuários entendam quando estão sendo colocados em risco pelas escolhas do desenvolvedor e que sejam capazes de avaliar esse risco.

Mas se eu for o proprietário do servidor e do cliente e tiver meus próprios motivos para não emitir um certificado, devo ser capaz de ter um log limpo e não ocultar outros problemas potenciais.

E você pode fazer isso usando um gerenciador de contexto de registro para capturar o aviso. Também estamos considerando fazer com que as solicitações tornem este aviso mais específico para as solicitações, para que seja mais fácil de capturar, mas isso ainda não aconteceu.

Eu tenho uma situação semelhante a @ jamie-sparked.

Eu entendo o ponto de Lukasa em impor a segurança, mas acho que você deve deixar SEU usuário decidir o que é melhor para ele.
Requests é uma biblioteca, não um aplicativo de usuário final. IMO, você deve considerar os desenvolvedores como seus usuários.
Os desenvolvedores de aplicativos devem ser responsabilizados por erros de segurança, se decidirem desligar a verificação do certificado (ou seja, verificar = Falso)

Como desenvolvedor, valorizo ​​a flexibilidade em vez de uma biblioteca que tenta ditar o que devo fazer.

Aliás, como outros disseram, acho os pedidos _excelentes_ e agradeço todo o seu esforço. Obrigado.

@thalesac Nós _do_ deixamos os desenvolvedores decidir. Conforme discutido _muitas_ vezes neste tópico, é bem possível desativar esse aviso. No entanto, não temos um switch que desativa todos os avisos: você precisa fazer cada um manualmente. Esta é uma tentativa de fazer com que nossos usuários removam _conscientemente_ cada proteção de segurança.

Pense nisso como uma defesa em profundidade. Para usar uma analogia com a arma de fogo, estamos entregando a você uma arma com a trava de segurança e sem balas nela, e um carregador. Se verify=False desativássemos todos os avisos, isso seria o equivalente a ter uma arma que, quando um carregador foi inserido, desativou automaticamente a segurança e disparou um cartucho. Conveniente? Certo. Perigoso? Pode apostar.

Receio, discordo do seu modelo de analogia.
Eu diria verificar = Falso É seu mecanismo de segurança. Se você o desabilitou explicitamente (ou manualmente), não quer que a arma o avise o tempo todo quando estiver atirando nos bandidos. Obviamente, o comportamento padrão deve impor o pensamento de segurança.
De qualquer forma, entendo que essa é apenas a minha opinião e você deve fazer o que achar melhor para o seu projeto. Talvez seja por isso que é uma boa biblioteca. :)
Obrigado

Eu definitivamente concordo com a Lukasa, a segurança é a primeira e se como um desenvolvedor estou usando o verify = False em uma parte do meu código, então devo suprimir o aviso, se não quiser ser avisado.

De qualquer forma, excelente biblioteca, grande fã do seu trabalho em equipe, continue assim, +10000 pela paciência em nos responder.

A meu ver, se um aplicativo está usando uma url definida por um usuário, o usuário deve ter a opção de desabilitar a verificação, mas em todas as situações em que consigo pensar, eles devem receber o aviso. Se, como desenvolvedor, você sabe por qualquer motivo que está se conectando a um url do qual não se espera um certificado válido (serviços internos pelos quais você não pagará por um certificado, teste, etc.), você deverá ter a opção de desativar os avisos junto com a desativação da verificação.

Ao mesmo tempo, acho que não será comum ter uma situação em que você deseje desativar os avisos globalmente de uma vez, pois isso torna muito fácil abrir problemas de segurança que são silenciosamente ignorados.

requests.packages.urllib3.disable_warnings() sim, é trabalho

Olá

requests.packages.urllib3.disable_warnings() não está mais funcionando? costumava silenciar os avisos para mim. Aqui é onde estou chamando a função de desativar avisos, e aqui está um exemplo de backtrace onde a função de aviso é chamada:

 [+] Redirecionamento aceito para https://drupal.org/
 > /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py (791) _validate_conn ()
 -> warnings.warn ((
 (Pdb) bt
 / root / droopescan / droopescan (5)()
 -> droopescan.main ()
 /root/droopescan/dscan/droopescan.py (55) main ()
 -> ds.run ()
 /usr/local/lib/python2.7/dist-packages/cement/core/foundation.py (764) run ()
 -> self.controller._dispatch ()
 /usr/local/lib/python2.7/dist-packages/cement/core/controller.py (466) _dispatch ()
 -> return func ()
 /usr/local/lib/python2.7/dist-packages/cement/core/controller.py (472) _dispatch ()
 -> return func ()
 /root/droopescan/dscan/plugins/internal/scan.py (114) default ()
 -> follow_redirects)
 /root/droopescan/dscan/plugins/internal/scan.py (230) _process_cms_identify ()
 -> if inst.cms_identify (url, opts ['timeout'], self._generate_headers (host_header)) == Verdadeiro:
 /root/droopescan/dscan/plugins/internal/base_plugin_internal.py (910) cms_identify ()
 -> cabeçalhos)
 /root/droopescan/dscan/plugins/internal/base_plugin_internal.py (827) enumerate_file_hash ()
 -> r = self.session.get (url + file_url, tempo limite = tempo limite, cabeçalhos = cabeçalhos)
 /usr/lib/python2.7/dist-packages/requests/sessions.py (480) get ()
 -> return self.request ('GET', url, ** kwargs)
 /usr/lib/python2.7/dist-packages/requests/sessions.py (468) request ()
 -> resp = self.send (prep, ** send_kwargs)
 /usr/lib/python2.7/dist-packages/requests/sessions.py (576) send ()
 -> r = adapter.send (solicitação, ** kwargs)
 /usr/lib/python2.7/dist-packages/requests/adapters.py (376) send ()
 -> tempo limite = tempo limite
 /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py (559) urlopen ()
 -> corpo = corpo, cabeçalhos = cabeçalhos)
 /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py (345) _make_request ()
 -> self._validate_conn (conn)
 > /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py (791) _validate_conn ()
 -> warnings.warn ((

O seguinte é a saída de pip freeze , estou usando o teste debian:

 argparse == 1.2.1
 beautifulsoup4 == 4.4.1
 cimento == 2.6.2
 chardet == 2.3.0
 colorama == 0.3.3
 cobertura == 4.0.3
 criptografia == 1.2.1
 distlib == 0.2.1
 -e [email protected]: droope/droopescan.git@6524a9235e89a6fdb3ef304ee8dc4cb73eca0386#egg=droopescan-development
 enum34 == 1.1.2
 funcsigs == 0.4
 futuros == 3.0.4
 html5lib == 0,999
 httpplib2 == 0.9.1
 idna == 2.0
 ipaddress == 1.0.16
 lxml == 3.5.0
 mercurial == 3.5.2
 mock == 1.3.0
 ndg-httpsclient == 0.4.0
 nariz == 1.3.7
 pbr == 1.8.1
 pyOpenSSL == 0.15.1
 pyasn1 == 0.1.9
 picurl == 7.21.5
 pystache == 0,5,4
 python-apt == 1.1.0b1
 python-debian == 0.1.27
 python-debianbts == 2.6.0
 reportbug == 6.6.6
 pedidos == 2.9.1
 respostas == 0.3.0
 tentando novamente == 1.3.3
 seis == 1.10.0
 urllib3 == 1.13.1
 roda == 0.26.0
 wsgiref == 0.1.2

Obrigado,
Pedro

disable_warnings não impede que a função de aviso seja chamada, apenas suprime a saída. Você pode encontrar problemas se algum outro trecho de código permitir todos os avisos.

Olá @Lukasa ,

Eu coloquei o ponto de interrupção após o if. No final, parei de usar o teste debian, pois me deparei com muitos problemas, e este pode muito bem ser um deles. Eu simplesmente ignoraria meu comentário, não tenho certeza do que aconteceu, mas provavelmente não é algo que afetará muitas pessoas.

Obrigado!
Pedr

Sim, então se você estava usando um pacote debian, é possível que a lógica de não venda quebrou algo aqui.

Querer fazer uma solicitação não segura especificando verify=False e não ver um aviso para essa solicitação, sem interferir nos avisos de qualquer outra solicitação feita em outro lugar, parece perfeitamente razoável.

from requests.packages.urllib3.exceptions import InsecureRequestWarning

...
with warnings.catch_warnings():
    warnings.filterwarnings("ignore", category=InsecureRequestWarning)
    resp = requests.get(url, verify=False)  # InsecureRequestWarning suppressed for this request

resp = requests.get(url, verify=False)  # InsecureRequestWarning not suppressed for this request
...