Requests: verificar = Falso y request.packages.urllib3.disable_warnings ()

Creo que puede deshabilitarlos a nivel global con el módulo warnings . Además, para trabajar con el registro (si mal no recuerdo), debe acceder a urllib3 (y lo documentamos), por lo que no estoy en contra de documentar esto para los usuarios que no van a utilizar la verificación de certificado para HTTPS. conexiones.

Sigo firmemente a favor de dejar estas advertencias en su lugar. Sí, son molestos, pero también están ahí por una razón. En todo caso, estoy tentado de apagarlo y reemplazarlo por uno propio. = P

En este punto, es bastante obvio que @Lukasa y yo somos -1 en esta función. @kennethreitz @shazow ¿ alguna opinión?

Hasta cierto punto, estoy de acuerdo en que las advertencias son importantes, pero creo que hay múltiples factores que podrían necesitar ser considerados.

Desde la perspectiva de un desarrollador, sé que sé sobre esto, puedo apagarlo si me apetece. Soy más nuevo en los paquetes, por lo que cuando leí los documentos, en la advertencia, esa solución en realidad no funcionó. Me gusta la idea que presentó @Lukasa acerca de hacer algo específico para requests .

Desde la perspectiva del usuario, instalé pyvmomi con pip hoy, que usa requests en sus componentes internos. Es realmente un error no transparente que se envía al usuario en un caso en el que requests es una biblioteca de soporte silenciosa.

Sí, requests.packages.urllib3.disable_warnings() es un atajo para desactivarlo usando el filtrado del módulo de advertencias.

Recomiendo encarecidamente tener algún tipo de advertencia al respecto. +0.5 al hacer que el urllib3 se propague, +1 si quieres esforzarte y agregar una solicitud específica. -1 al no tener advertencia.

Si lo desea, podemos hacer que el mensaje de advertencia de urllib3 sea configurable y usted puede anularlo para que, de lo contrario, pueda utilizar la misma lógica.

Una vez más, no considero que este mensaje sea hostil para el usuario, lo considero extremadamente valioso. Ahora sabe que pyvmomi ha desactivado la verificación del certificado TLS, ¡que es una información bastante importante!

Dicho esto, no me opongo a que tengamos una forma más solicitada de silenciarlo.

Sí, realmente creo que esto es un error en pyvmomi . Si no quieren sentirse avergonzados de esta manera, deberían desactivar las advertencias en su herramienta. No es nuestro trabajo _no_ advertir a los usuarios que las conexiones que está haciendo alguna herramienta podrían exponerlos a ataques MITM porque la herramienta no está realizando la verificación del certificado.

¡Gracias por la discusión amigos! Aprecio a todos los que comentan y me ayudan a ver el valor de la forma en que se hacen las cosas y por qué. ¡Me estaba costando ver los casos más generales! :)

Trabajará en un parche hoy, según lo permita el tiempo, para tener una forma de silencio. ¡Los comentarios serán bienvenidos!

@invisiblethreat no dude en ingresar al IRC si tiene preguntas

Me pregunto si consideró el caso en el que las solicitudes se utilizan en un webhook. Tengo que suprimir la advertencia para que no contamine la salida JSON del script (¿o me falta algo?)

@macterra No estoy seguro de entender. ¿Está buscando estrategias alternativas para desactivar la advertencia o ...?

Tampoco me queda muy claro por qué su webhook está deshabilitando la verificación del certificado. Me gustaría dejar eso encendido.

Además, si está canalizando stdout desde algún script para obtener los resultados, saldrán advertencias de stderr para que no contaminen su salida JSON.

Bien, si la advertencia está en stderr, no hay problema. No pude decir al mirar la salida en la consola, mi error.

Creo que deberíamos personalizar esto para que apunte a la documentación de las solicitudes en lugar de a la documentación de urllib3.

No estoy seguro de entender qué se pretende lograr con esta función de advertencia y cómo se debe controlar la advertencia.

Tengo un módulo que usa requests y tiene que hacer solicitudes con el argumento verify=False . Esto hace que los usuarios de mi módulo vean una advertencia innecesaria. Las advertencias innecesarias hacen que las advertencias importantes sean más difíciles de ver,

Tendría sentido que mi módulo deshabilitara la advertencia, pero entonces _¡Estaría deshabilitando la advertencia también en cualquier otro módulo_ usando requests en la aplicación!

Las cosas no mejoran si necesito instruir al usuario de mi módulo para que desactive la advertencia: el hecho de que estoy usando requests normalmente es solo un detalle de implementación invisible que el usuario no debería necesitar saber. Y el usuario aún tendría la opción de silenciar todo o anotar.

No creo que las advertencias globales vayan a ser útiles.

Podría subclasificar urllib3.HTTPSConnectionPool y anular _validate_conn() y hacer que requests use eso en mi módulo para evitar ocultar advertencias de otros módulos, pero eso parece ser demasiado trabajo para una cosa simple .

No estoy seguro de entender qué se pretende lograr con esta función de advertencia

hace que los usuarios de mi módulo vean la advertencia innecesaria.

Cuando configura verify=False ya no está asegurando sus conexiones de red. Eso, en mi humilde opinión, _no_ es una advertencia innecesaria, es una advertencia enormemente relevante. Sus usuarios, que anteriormente no tenían idea de que usted no estaba verificando certificados, ahora saben que esto es cierto.

Si la advertencia no es valiosa para su módulo, es probable que no lo sea para ningún otro módulo de la aplicación (una vez que haya desechado la seguridad en un punto de la red, no tiene sentido alardear de ello en el resto). Realmente no veo ningún problema en deshabilitarlo globalmente.

Cuando el usuario solicita explícitamente verify=False para una solicitud en particular, no veo el valor de mostrar una advertencia. Cuando yo, como autor del módulo, configuro verify=False , lo configuro por solicitud del usuario (o estoy siendo malicioso, pero la advertencia tampoco ayuda porque puedo silenciar las advertencias). De hecho, quiero evitar ser malicioso y no quiero silenciar globalmente las advertencias, porque eso quita la advertencia útil para aquellas solicitudes que alguna otra parte de la aplicación está haciendo sin saberlo de manera insegura.

Además, tener la advertencia activada para aquellas solicitudes en las que el usuario desactiva explícitamente la verificación también oculta las solicitudes en las que el usuario querría la advertencia, ya que la advertencia se da solo una vez. La advertencia tampoco es realmente útil para el usuario, ya que no menciona la URL de la solicitud en particular.

No estoy de acuerdo en que descartar la seguridad en un punto de la red de alguna manera haga que los controles de seguridad sean inútiles en la aplicación, ni tampoco los proveedores de navegadores. Los navegadores me permiten eludir los controles de seguridad para URL individuales, pero sigo revisando el resto y eso me gusta.

Cuando tengo una herramienta que habla con un servidor interno con un certificado autofirmado en una red interna, pero también se comunica con hosts externos, quiero verificar la comunicación externa. Esta sería la situación en la que me gustaría, como usuario, ver advertencias sobre solicitudes no seguras accidentalmente.

Considere que estoy ganando service_foo y alguien lo usa en una aplicación:

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)

Tengo 2 opciones por service_foo :

1. Mantengo activada la advertencia de seguridad global
   
   
   
   • El usuario siempre recibe una advertencia cuando la aplicación habla con https://10.0.0.1
   
   
   • El usuario nunca recibe una advertencia, incluso si la solicitud a https://example.com/submit no es segura
   
   
2. Desactive la advertencia de seguridad global:
   
   
   
   • El usuario nunca recibe una advertencia, incluso si la solicitud a https://example.com/submit no es segura
   
   

No creo que ninguna de las opciones sea buena, pero la opción 1 es peor, porque da falsas alarmas. Pero no me siento cómodo con que los controles de seguridad estén desactivados para el usuario como un efecto secundario del uso de mi módulo.

Si hiciera esto con un script de shell, el usuario estaría más feliz y seguro:

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

Para mí, solo tiene sentido dar una advertencia si la configuración de la plataforma Python está rota. La página https://urllib3.readthedocs.org/en/latest/security.html vinculada en el mensaje InsecureRequestWarning está realmente diseñada para mostrar cómo solucionar problemas en la plataforma. Si el usuario solicita omitir la verificación, no debería haber una advertencia como si no hubiera una advertencia si el usuario solicita una URL http lugar de una https una.

Cuando el usuario solicita explícitamente verify = False para una solicitud en particular, no veo el valor de mostrar una advertencia.

¿Quién es el 'usuario'? A lo largo de su publicación, esta pregunta siguió viniendo a mi mente, porque creo que está combinando dos audiencias.

Cuando yo, como autor de un módulo, establezco verify = False, lo configuro por solicitud del usuario (o estoy siendo malicioso).

O estás siendo negligente. Algunos usuarios se han quejado de que no pueden interoperar con sus certificados autofirmados, por lo que desactivó la verificación de certificados, a pesar de que desactivar la verificación de certificados no es la forma de solucionar ese problema.

que elimina la advertencia útil para aquellas solicitudes que alguna otra parte de la aplicación está haciendo sin saberlo de manera insegura

Esta frase me desconcierta. Sugiere que es aceptable advertir cuando una aplicación _inconocimiento_ realiza solicitudes inseguras, pero que una aplicación _con conocimiento_ que las hace está de alguna manera OK. No veo cómo hacer solicitudes inseguras a sabiendas debería considerarse de alguna manera "más seguro" que hacerlo sin saberlo.

Además, tener la advertencia activada para aquellas solicitudes en las que el usuario desactiva explícitamente la verificación

¿Qué usuario? ¿Cómo distinguir entre el autor del módulo y el 'usuario', sea quien sea?

La advertencia tampoco es realmente útil para el usuario, ya que no menciona la URL de la solicitud en particular.

La advertencia no debe mencionar la URL de la solicitud, ya que correría el riesgo de generar spam de advertencia. Advertimos _una vez_, diciendo 'esta aplicación está en riesgo', no 'esta comunicación en particular está en riesgo'.

Los navegadores me permiten eludir los controles de seguridad para URL individuales, pero sigo revisando el resto y eso me gusta.

Los proveedores de navegadores _advierten_ cuando accede a una URL con un certificado no válido. Imprimen cuadros de diálogo y resaltan la barra de URL en rojo. Eso es _exactamente_ lo que estamos haciendo. No le estamos impidiendo hacer nada, solo le decimos "¡oye, esto es malo!" Lo que nos pide que hagamos es lo mismo que pedirles a los proveedores de navegadores que permitan a los usuarios desactivar esa advertencia roja para determinadas URL, y les garantizo que se negarán a hacerlo porque las implicaciones de seguridad son monstruosas.

Cuando tengo una herramienta que habla con un servidor interno con un certificado autofirmado en una red interna, pero también se comunica con hosts externos, quiero verificar la comunicación externa.

No, quieres verificar _toda_ la comunicación. ¡Verifique el certificado autofirmado! Valide que obtuvo el certificado que esperaba obtener. verify=False debe considerarse un enfoque de seguridad de mazo, diciendo efectivamente "seguridad al diablo, simplemente haz que funcione". Eso está absolutamente bien, tienes derecho a decir eso, pero tenemos la obligación de llamarlo inseguro.

No creo que ninguna de las opciones sea buena, pero la opción 1 es peor, porque da falsas alarmas.

La opción 1 no está dando falsas alarmas, está dando alarmas reales. La comunicación a 10.0.0.1 es _insegura_, y no deberíamos fingir lo contrario.

Si hiciera esto con un script de shell, el usuario estaría más feliz y seguro.

El usuario puede estar más feliz, pero no estaría más seguro. Estarían exactamente tan seguros como antes. Parece tener la impresión de que desactivar esta advertencia de alguna manera hace que desaparezca mágicamente la verificación del certificado, y no es así. Tocaré esto nuevamente al final de esta respuesta.

Para mí, solo tiene sentido dar una advertencia si la configuración de la plataforma Python está rota.

No, deberíamos fallar si la configuración de la plataforma Python está rota y no solicitó solicitudes no verificadas. Si su plataforma no puede realizar conexiones TLS seguras, entonces no deberíamos hacerlo, excepto en la situación en la que nuestro usuario nos diga expresamente que no nos importe (configurando verify=False ), en cuyo caso debemos advertir que lo que usted Estoy a punto de hacerlo es peligroso.

Creo que estás trabajando bajo un malentendido, así que me gustaría dejar algo muy claro: no hay forma de hacer una solicitud HTTPS no validada con solicitudes sin a) configurar verify=False (nuestro comportamiento de advertencia) o b) sabotear deliberadamente el módulo ssl . No podemos atrapar b) y no advertir sobre ello. Ésta es la única situación que caería dentro de la noción que planteó de "problemas con la plataforma". El consejo de la página de ayuda de urllib3 no se aplica a nosotros porque tomamos todos los pasos necesarios relacionados con la plataforma, incluido el empaquetado de certificados confiables y la verificación manual de certificados.

Existe una opinión peligrosa en la comunidad web de que solo debe verificar los certificados firmados por certificados raíz de confianza. Esta opinión está completamente equivocada. Si se encuentra con certificados autofirmados, debería validarlos. ¡Eso es totalmente factible! ¡Agregue el certificado autofirmado a un archivo .pem y páselo como argumento a verify !

Si tiene problemas para combinar eso con el archivo .pem incluido, hágamelo saber y mejoraré mkcert.org para que pueda concatenar sus propios certificados con las raíces de confianza. Pero, por favor, no pretenda que la configuración verify=False es segura: simplemente no lo es.

Además, tener la advertencia activada para aquellas solicitudes en las que el usuario desactiva explícitamente la verificación también oculta las solicitudes en las que el usuario querría la advertencia, ya que la advertencia se da solo una vez.

Esto también es un poco desconcertante. Al establecer verify=False , tal vez lo desactive explícitamente solo para esa solicitud, pero no hay forma de transmitir eso más allá del punto en el que construimos nuestra solicitud. Tampoco hay razón para transmitirlo más allá de ese punto porque ha desactivado la verificación del certificado. El contexto en el que lo hizo no tiene importancia para nosotros ni para nadie que utilice su aplicación.

Lo que nos pide que hagamos es lo mismo que pedirles a los proveedores de navegadores que permitan a los usuarios desactivar esa advertencia roja para determinadas URL, y les garantizo que se negarán a hacerlo porque las implicaciones de seguridad son monstruosas.

Mis navegadores me permiten aceptar de forma permanente un certificado no verificado, que es "monstruosamente inseguro".

La comunicación con 10.0.0.1 es insegura y no deberíamos fingir lo contrario.

La conexión es insegura en la forma en que no puede verificar un certificado digital, pero verificar un certificado realmente no le dice si el servidor con el que está hablando es seguro. Pero cuando hablo con un servidor en una red cerrada, realmente puedo asegurarme de la seguridad del servidor.

Creo que está trabajando bajo un malentendido, por lo que me gustaría dejar algo muy claro: no hay forma de realizar una solicitud HTTPS no validada con solicitudes sin a) establecer verificar = Falso (nuestro comportamiento de advertencia) ob) deliberadamente saboteando el ssl

Estoy tratando de preguntarme cómo podría ser un buen ciudadano en mi módulo honrando el deseo del usuario de ignorar las verificaciones de certificados y las advertencias de la URL que me dan. Y qué valor agrega el modelo de advertencia. ¿Cuál es el caso en el que una solicitud con verify=False debería mostrar una advertencia al usuario?

No veo cómo el mecanismo de advertencia puede detectar un código negligente, ya que no puede distinguir si una solicitud se realiza debido a una codificación descuidada o porque un usuario lo solicitó. Tampoco creo que un módulo como requests deba dictar una política de seguridad. Tengo entendido que las advertencias generalmente están dirigidas a los desarrolladores para que puedan corregir el código incorrecto, pero esta advertencia no es así. Si la advertencia es solo para la educación general del usuario, debe haber una manera fácil para que el usuario la oculte.

Recibir la advertencia tampoco es solo cosmético, ya que altera el resultado de un programa.

Solo veo el valor negativo de la advertencia, así que lo apago en mi módulo, incluso si odio esconder un cambio de política tan global allí.

Existe una opinión peligrosa en la comunidad web de que solo debe verificar los certificados firmados por certificados raíz de confianza. Esta opinión está completamente equivocada.

No sabía que había una vista así. Un certificado firmado por un certificado raíz no prueba nada sobre la seguridad del sitio. Es barato obtener un certificado anónimo si quieres hacer cosas malas.

Si se encuentra con certificados autofirmados, debería validarlos. ¡Eso es totalmente factible! Agregue el certificado autofirmado a un archivo .pem y páselo como argumento para verificar.

El usuario necesitaría un canal seguro para obtener el certificado, como una red de confianza interna. Pero si el servidor está en la misma red interna, no se gana mucho. Pero, en cualquier caso, esto es algo que decide el usuario, no puedo imponer una política en mi módulo.

Estoy de acuerdo con @kankri , en su mayor parte. Esa fue la intención del diseño original.

Propongo algo: que deshabilitamos de forma predeterminada, pero tenemos nuestra propia función para volver a habilitarlo o documentar cómo encenderlo. No quiero que los usuarios tengan que salir del camino para usar el código según lo previsto. verify=False es una característica, aunque no una de las mejores prácticas. Eso no es asunto nuestro.

Estoy de acuerdo en que verify=False es una función, pero no estoy de acuerdo en que sea una función del mismo nivel que params= o cert= . Es una función que se establece de forma predeterminada en un valor seguro y puede configurarse en uno inseguro. Es una opción gigantesca y tentadora para la gente tirar la seguridad por la ventana en aras de la conveniencia, y creo que ese impulso debe resistirse (pero no desestimarse). Siempre me inclinaré hacia la escuela de pensamiento de 'debes ser explícitamente inseguro', y no me importa si eso significa presionar dos interruptores y no uno.

Independientemente, esta es tu llamada, no la mía. =)

Solo quería decir que estoy de acuerdo con @kankri y que el comentario de @kennethreitz

verify = False es una característica, aunque no es una de las mejores prácticas. Eso no es asunto nuestro.

lo resume bien.

Para aquellos que también quieran desactivar las advertencias, así es como se hace. Debe utilizar los módulos de advertencias , que forman parte de la biblioteca estándar:

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)

Esto configura un filtro de advertencia que ignorará cualquier advertencia de la categoría InsecureRequestWarning . La salida se ve así:

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

(El sitio de prueba devuelve una página 403 Prohibida, pero eso no es importante aquí).

Tenga en cuenta que es necesario utilizar la clase del paquete urllib3 paquete, y no a la clase de un alto nivel de urllib3 paquete, si le sucede que tiene uno instalado.

Puede (y probablemente debería) hacer una pequeña función que use el administrador de contexto en la región de código más pequeña posible:

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

O simplemente haz esto:

requests.packages.urllib3.disable_warnings()

@Lukasa

O simplemente haz esto:

requests.packages.urllib3.disable_warnings()

Excepto que no encuentro ninguna mención de esta función en el manual de solicitudes.

Si bien está lejos de todos los que lo conocen, yo diría que el módulo warnings _es_ la herramienta estándar que un programador de Python debería buscar cuando quiera deshabilitar las advertencias. Es parte de la biblioteca estándar y está bien documentado.

Sugiero poner una referencia a warnings en la documentación de requests - o a la conveniencia de la función disable_warnings si lo desea, siempre que haya un enable_warnings función ( parece que no existe tal función ).

Una vez más: no quiero desactivar las advertencias en general. Solo quiero que esta advertencia en particular desaparezca cuando _explícitamente_ establezca verify = False en mi código. Puede haber otras advertencias útiles, a diferencia de esta advertencia particular e inútil. ¡¿Qué es tan difícil de entender sobre esto ?!

@zaitcev A riesgo de repetirme:

requests.packages.urllib3.disable_warnings()

Y si incluso eso es demasiado amplio para ti:

from requests.packages.urllib3.exceptions import InsecureRequestWarning

requests.packages.urllib3.disable_warnings(InsecureRequestWarning)

Finalmente, una nota, @zaitcev : encontrarás que tomar el tono exasperado que acabas de hacer no te gana ningún favor. Recuerde que todos somos voluntarios y que tenemos una cantidad limitada de nuestro tiempo para dedicarle a construir cosas. Intente tratarnos de la manera que le gustaría que lo trataran a usted.

@zaitcev No parece que esto vaya a cambiar en el módulo de solicitudes, pero espero que puedas usar el código que puse en mi otro comentario . Eso debería permitirle deshabilitar selectivamente las advertencias emitidas por urllib3.

También puede suprimirlo con:

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

En mi caso, no estoy usando las solicitudes directamente, por lo que suprimirlas de esta manera me permite preocuparme un poco menos de que se rompa más adelante.

@zaitcev Juntando todas las sugerencias anteriores, puede hacer algo como esto:

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 Eso dejaría las advertencias deshabilitadas para todas las solicitudes posteriores.

Juntando otros ejemplos, extendí el Session predeterminado (como requests.get y otros atajos crean un Session temporal, de todos modos):

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)

Deshabilitar todas las advertencias de requests probablemente sea una mala idea, un poco mejor podría ser:

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

Para resumir cómo manejé esto:

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

Esto me permite verificar si una solicitud es insegura, ocultar la advertencia de urllib y generar una advertencia de mi propio formato para el usuario. Requiere que la solicitud se realice dos veces. Editado para hacer que la cláusula except sea menos amplia.

except Exception: es MUY amplio. realmente no quieres eso.

Lo anterior va de alguna manera a abordar las preocupaciones de ambos lados de esta discusión.

¿No arroja alguna subclase de excepción que pueda atrapar en su lugar?

O use logging.captureWarnings()

La alternativa es saber que urllib3 está involucrado y codificar su espacio de nombres, ver el comentario de tuukkamustonen. Esta fue mi principal objeción: podrían haberlo hecho funcionar bien, incluso proporcioné un parche en una solicitud de extracción. Pero niegan que el problema exista y les dicen a todos los usuarios que propongan soluciones terribles como "excepto Excepción" o "de las solicitudes de excepciones de importación de paquetes.urllib3". En este punto, alguien tiene que admitir que se equivocó todo el tiempo y, por lo tanto, estamos estancados.

Esta fue mi principal objeción: podrían haberlo hecho funcionar bien, incluso proporcioné un parche en una solicitud de extracción. Pero niegan que el problema exista y les dicen a todos los usuarios que propongan soluciones terribles como "excepto Excepción" o "de las solicitudes de excepciones de importación de paquetes.urllib3". En este punto, alguien tiene que admitir que se equivocó todo el tiempo y, por lo tanto, estamos estancados.

@zaitcev Una vez más, permítanme recordarles que esta es una comunidad de voluntarios que hace lo mejor que pueden. Hemos dejado este tema libre para su discusión, no hemos intentado bloquearlo ni evitar que se siga debatiendo. Te estamos escuchando. Lo que no estamos haciendo es estar de acuerdo de inmediato con su evaluación de la situación. Tenga en cuenta la posibilidad de que nos interesen más casos de uso que simplemente el suyo, y que necesitamos equilibrar las necesidades de todos ellos.

En cuanto a su solicitud de extracción, fue rechazada por una _ razón muy específica_ que ignora constantemente. Permítanme citarme citando a Ian :

La declaración final fue: "Dado que esto está principalmente en urllib3 y dependería de la aceptación allí, cerraré esto hasta que se haya realizado un progreso allí "

A día de hoy, todavía no veo ninguna solicitud de extracción asociada o problema para este problema en urllib3. Nadie de este proyecto se ha interpuesto en su camino o ha impedido que este trabajo ocurra, simplemente no hemos elegido hacerlo nosotros mismos porque _ actualmente no estamos de acuerdo con usted_.

Sin embargo, a riesgo de volver a caer por esta madriguera, permítanme reiterar:

Esta fue mi principal objeción: podrían haberlo hecho bien.

No creo que su parche haga que esto funcione "bien" . Como he dicho muchas veces en este hilo, considero deseable el comportamiento actual. Hacer solicitudes TLS inseguras es una mala idea y se debe advertir a los usuarios que no lo hagan.

Mi posición es que un usuario _merece saber_ cuando está haciendo una solicitud TLS que no está adecuadamente protegida, especialmente en cualquier sistema que esté manejando sus contraseñas.

Existe un acuerdo en este hilo de que deberíamos considerar tener un verify=False y verify=None para silenciar implícitamente estas advertencias. Le resultará mucho más fácil hacer lo primero que lo segundo.

+1 para no diferenciar entre verificar = Falso y verificar = Ninguno. Yo apoyaría ya sea:

• agregar un nuevo parámetro (digamos, noInsecureWarnings), o
• tener solicitudes intercepta la advertencia urllib3 y emite una propia, por lo que (a) puedo suprimir algo menos aterrador que 'request.packages.urllib3.exceptions.InsecureRequestWarning' (que ya es específico de las solicitudes de todos modos, pero se interrumpirá si las solicitudes se migran a una biblioteca subyacente diferente), y (b) la advertencia puede apuntar a una URL específica de solicitudes (la URL actual no es relevante ya que la advertencia se ha sombreado).

Y gracias a todos los voluntarios por apoyar las solicitudes, ya sea que esto se solucione o no: es una gran biblioteca :)

Esta es una biblioteca increíble, gracias por todo su arduo trabajo.

Me encontré con este problema después de actualizar mis paquetes de Python recientemente y notar una gran cantidad de nuevas impresiones de InsecurePlatformWarning. Así que estoy contribuyendo con mi caso de uso, que creo que es convincente.

Estoy usando solicitudes para administrar servidores jenkins en 4 entornos diferentes. Tres de los entornos (desarrollo, preparación, producción) tienen certificados válidos. El cuarto entorno es una caja virtual vagabunda, que los desarrolladores pueden usar para probar cambios en sus máquinas locales. Este no tiene un certificado válido, pero como cuestión de política, todas las configuraciones del servidor rechazan las solicitudes no cifradas.

La configuración de conexión de jenkins (nombre del servidor, token, etc.) para un entorno incluye un indicador específico para desactivar la verificación SSL, que solo se establece en True para el entorno vagabundo.

En mi configuración, deshabilitar la advertencia globalmente sería una mala idea porque el proyecto es bastante grande y se pueden realizar muchas solicitudes, con o sin la biblioteca de solicitudes. Deshabilitar la advertencia en el alcance estaría bien, excepto que parte del proyecto incluye una aplicación de matraz y otros casos posiblemente de subprocesos múltiples.

En mi opinión, parece que el uso de verify = False debería ser compatible y funcionar como se esperaba, sin advertencias. Depende del desarrollador de la aplicación decidir cuándo y si debe permitirse. Por ejemplo, si estuviera escribiendo un navegador para uso general, nunca lo establecería en Verdadero sin mostrar un gran cuadro de diálogo de confirmación con mucho texto en rojo. Pero si soy el propietario del servidor y del cliente y tengo mis propias razones para no emitir un certificado, debería poder tener un registro limpio y no ocultar otros problemas potenciales.

Depende del desarrollador de la aplicación decidir cuándo y si debe permitirse.

Esta afirmación es donde difiero contigo. Creo que depende del desarrollador decidir cuándo deben usarlo. Pero creo que depende del _usuario_ decidir si esa elección es aceptable. Es _crítico_ que los usuarios comprendan cuándo están siendo puestos en riesgo por las decisiones de los desarrolladores, y que puedan evaluar ese riesgo.

Pero si soy el propietario del servidor y del cliente y tengo mis propias razones para no emitir un certificado, debería poder tener un registro limpio y no ocultar otros problemas potenciales.

Y puede hacerlo utilizando un administrador de contexto de registro para capturar la advertencia. También estamos considerando que las solicitudes hagan que esta advertencia sea más específica para las solicitudes para que sea más fácil de capturar, pero eso aún no ha sucedido.

Tengo una situación similar a @ jamie-sparked.

Entiendo el punto de Lukasa en hacer cumplir la seguridad, pero creo que debes dejar que TU usuario decida qué es lo mejor para ellos.
Requests es una biblioteca, no una aplicación de usuario final. En mi opinión, debería considerar a los desarrolladores como sus usuarios.
Los desarrolladores de aplicaciones deben ser responsables de los errores de seguridad si deciden desactivar la verificación del certificado (es decir, verificar = Falso)

Como desarrollador, valoro la flexibilidad sobre una biblioteca que intenta dictar lo que debo hacer.

Por cierto, como han dicho otros, encuentro solicitudes _excelentes_ y agradezco todo su esfuerzo. Gracias.

@thalesac _Dejamos que los desarrolladores decidan. Como se discutió _muchas_ veces en este hilo, es muy posible desactivar esta advertencia. Sin embargo, no tenemos un interruptor que apague todas las advertencias: debe hacer cada una manualmente. Este es un intento de hacer que nuestros usuarios _conscientemente_ retiren todos los resguardos de seguridad.

Piense en ello como una defensa en profundidad. Para usar una analogía con un revólver, le entregamos un arma con el seguro puesto y sin balas, y un cargador. Si tuviéramos verify=False deshabilitar todas las advertencias, eso sería el equivalente a tener un arma que, cuando se inserta un cargador, deshabilita automáticamente el seguro y guarda una ronda. ¿Conveniente? Seguro. ¿Peligroso? Usted apuesta.

Me temo que no estoy de acuerdo con su modelo de analogía.
Yo diría que verifique = Falso ES su mecanismo de seguridad. Si lo desactivó explícitamente (o manualmente), no querrá que el arma le advierta todo el tiempo cuando dispara a los malos. Obviamente, el comportamiento predeterminado debe reforzar el pensamiento de seguridad.
De todos modos, entiendo que esto es solo mi punto de vista y que debes hacer lo que creas que es mejor para tu proyecto. Quizás por eso es una buena biblioteca. :)
Gracias

Definitivamente estoy de acuerdo con Lukasa, la seguridad es lo primero y si como desarrollador estoy usando verify = False en una parte de mi código, entonces debería suprimir la advertencia, si no quiero ser advertido.

De todos modos, excelente biblioteca, gran fanático del trabajo en equipo, sigan así, +10000 por la paciencia para respondernos.

A mi modo de ver, si una aplicación está usando una URL establecida por un usuario, el usuario debería tener una opción para deshabilitar la verificación, pero en cada situación que se me ocurra, debería recibir la advertencia. Si como desarrollador y sabe por qué razón se está conectando a una URL que no se espera que tenga un certificado válido (servicios internos por los que no pagará por un certificado, prueba, etc.), entonces debería tener la opción de deshabilitar las advertencias junto con la desactivación de la verificación.

Al mismo tiempo, no creo que sea común tener una situación en la que desee deshabilitar las advertencias a nivel mundial de una sola vez, ya que eso hace que sea demasiado fácil abrir problemas de seguridad que se ignoran en silencio.

requests.packages.urllib3.disable_warnings() sí, es trabajo

Hola

¿ requests.packages.urllib3.disable_warnings() no funciona? solía silenciar las advertencias para mí. Aquí es donde llamo a la función de desactivación de advertencias, y aquí hay un ejemplo de rastreo inverso donde se llama a la función de advertencia:

 [+] Redireccionamiento aceptado a 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) principal ()
 -> 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) predeterminado ()
 -> 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)) == Verdadero:
 /root/droopescan/dscan/plugins/internal/base_plugin_internal.py (910) cms_identify ()
 -> encabezados)
 /root/droopescan/dscan/plugins/internal/base_plugin_internal.py (827) enumerate_file_hash ()
 -> r = self.session.get (url + file_url, tiempo de espera = tiempo de espera, encabezados = encabezados)
 /usr/lib/python2.7/dist-packages/requests/sessions.py (480) get ()
 -> return self.request ('OBTENER', url, ** kwargs)
 /usr/lib/python2.7/dist-packages/requests/sessions.py (468) solicitud ()
 -> resp = self.send (preparación, ** enviar_kwargs)
 /usr/lib/python2.7/dist-packages/requests/sessions.py (576) send ()
 -> r = adapter.send (solicitud, ** kwargs)
 /usr/lib/python2.7/dist-packages/requests/adapters.py (376) send ()
 -> tiempo de espera = tiempo de espera
 /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py (559) urlopen ()
 -> cuerpo = cuerpo, encabezados = encabezados)
 /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py (345) _make_request ()
 -> self._validate_conn (conexión)
 > /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py (791) _validate_conn ()
 -> warnings.warn ((

La siguiente es la salida de pip freeze , estoy usando debian testing:

 argparse == 1.2.1
 beautifulsoup4 == 4.4.1
 cemento == 2.6.2
 chardet == 2.3.0
 colorama == 0.3.3
 cobertura == 4.0.3
 criptografía == 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
 httplib2 == 0.9.1
 idna == 2.0
 ipaddress == 1.0.16
 lxml == 3.5.0
 mercurial == 3.5.2
 simulacro == 1.3.0
 ndg-httpsclient == 0.4.0
 nariz == 1.3.7
 pbr == 1.8.1
 pyOpenSSL == 0.15.1
 pyasn1 == 0.1.9
 pycurl == 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
 solicitudes == 2.9.1
 respuestas == 0.3.0
 reintentando == 1.3.3
 seis == 1.10.0
 urllib3 == 1.13.1
 rueda == 0.26.0
 wsgiref == 0.1.2

Gracias,
Pedro

disable_warnings no evita que se llame a la función de advertencia, simplemente suprime la salida. Puede encontrar problemas si algún otro código habilita todas las advertencias.

Hola @Lukasa ,

Puse el punto de ruptura después del si. Al final dejé de usar las pruebas de Debian porque encontré demasiados problemas, y este puede ser uno de ellos. Simplemente ignoraría mi comentario, no estoy seguro de lo que sucedió, pero es probable que no sea algo que afecte a mucha gente.

¡Gracias!
Pedr

Sí, así que si estuvieras usando un paquete de Debian, es posible que su lógica de reventa rompiera algo aquí.

Querer realizar una solicitud insegura especificando verify=False y no ver una advertencia para esa solicitud, sin interferir con las advertencias de cualquier otra solicitud realizada en otro lugar, parece perfectamente razonable.

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
...