requests 🚀 - 확인=거짓 및 requests.packages.urllib3.disable_warnings()

warnings 모듈을 사용하여 전역 수준에서 이를 비활성화할 수 있다고 생각합니다. 또한, 로깅 작업을 하려면(제 기억이 맞다면) urllib3 에 접근해야 합니다(그리고 우리는 이를 문서화합니다). 사이.

sigmavirus24 에 2014년 09월 09일

저는 이러한 경고를 그대로 유지하는 것에 강력히 찬성합니다. 예, 그들은 성가신 일이지만 이유가 있습니다. 무엇이든 전원을 끄고 우리 제품으로 교체하고 싶습니다! =피

Lukasa 에 2014년 09월 09일

이 시점에서 @Lukasa 와 나는 이 기능에 대해 -1이라는 것이 상당히 분명합니다. @kennethreitz @shazow 의견이 있으 십니까?

sigmavirus24 에 2014년 09월 10일

어느 정도 경고가 중요하다는 점에는 동의하지만 고려해야 할 여러 요소가 있다고 생각합니다.

개발자의 관점에서 내가 이것에 대해 알고 있다는 것을 알고 있고, 내가 의향이 있으면 이 기능을 끌 수 있습니다. 저는 패키지에 익숙하지 않으므로 문서를 읽을 때 경고에서 해당 솔루션이 실제로 작동하지 않았습니다. 나는 @Lukasa 가 requests 특정한 것을 만드는 것에 대해 제시한 아이디어를 좋아합니다.

사용자 관점에서 오늘 pyvmomi 와 함께 pip 를 설치했는데 내부에서 requests 를 사용합니다. requests 가 자동 지원 라이브러리인 경우 사용자에게 다시 내보내지는 불투명한 오류입니다.

invisiblethreat 에 2014년 09월 10일

예, requests.packages.urllib3.disable_warnings() 는 경고 모듈의 필터링을 사용하여 해제하는 지름길입니다.

이 효과에 대해 일종의 경고를 표시하는 것이 좋습니다. urllib3를 전파하는 데 +0.5, 노력을 기울이고 특정 요청을 추가하려는 경우 +1. -1 경고 없음.

원하는 경우 urllib3 경고 메시지를 구성 가능하게 만들 수 있으며 이를 재정의할 수 있으므로 그렇지 않으면 동일한 논리를 피기백할 수 있습니다.

shazow 에 2014년 09월 10일

다시 한 번 말씀드리지만 저는 이 메시지가 사용자에게 적대적이라고 생각하지 않으며 매우 가치 있다고 생각합니다. 이제 pyvmomi가 TLS 인증서 확인을 해제했음을 알았습니다. 이는 상당히 중요한 정보입니다!

즉, 나는 우리가 더 많은 요청을 하는 것에 반대하지 않습니다.

Lukasa 에 2014년 09월 10일

예, 정말로 이것이 pyvmomi 의 버그라고 생각합니다. 이렇게 당황하지 않으려면 도구에서 경고를 비활성화해야 합니다. 도구가 인증서 확인을 수행하지 않기 때문에 일부 도구가 만드는 연결이 사용자를 MITM 공격에 노출시킬 수 있음을 사용자에게 경고하는 _not_ 것은 우리의 일이 아닙니다.

sigmavirus24 에 2014년 09월 10일

토론해주셔서 감사합니다! 나는 모든 사람들이 의견을 제시하고 일을 수행하는 방식과 그 이유에서 가치를 볼 수 있도록 도와주셔서 감사합니다. 좀 더 일반적인 경우를 보기가 어려웠어요! :)

시간이 허락하는 한 오늘 패치에서 작업하여 침묵을 위한 '요청-y' 방식을 가질 것입니다. 피드백을 환영합니다!

invisiblethreat 에 2014년 09월 10일

@invisiblethreat 질문이 있는 경우 언제든지 IRC에 뛰어들 수 있습니다.

sigmavirus24 에 2014년 09월 11일

웹훅에서 요청이 사용되는 경우를 고려했는지 궁금합니다. 스크립트의 JSON 출력을 오염시키지 않도록 경고를 표시하지 않아야 합니다(또는 누락된 항목이 있습니까?).

macterra 에 2014년 09월 24일

@macterra 내가 이해하고 있는지 잘 모르겠습니다. 경고 또는 ...를 비활성화하기 위한 대체 전략을 찾고 있습니까?

sigmavirus24 에 2014년 09월 24일

웹훅이 인증서 확인을 비활성화하는 이유도 매우 불분명합니다. 나는 그것을 놔두고 싶었다.

Lukasa 에 2014년 09월 24일

또한 결과를 얻기 위해 일부 스크립트에서 stdout을 파이핑하는 경우 stderr에서 경고가 나오므로 JSON 출력을 오염시키지 않아야 합니다.

shazow 에 2014년 09월 24일

맞습니다. 경고가 stderr에 있으면 문제가 없습니다. 콘솔의 출력을 보고는 알 수 없었습니다. 제 실수였습니다.

macterra 에 2014년 10월 03일

urllib3의 문서 대신 요청 문서를 가리키도록 이것을 사용자 정의해야 한다고 생각합니다.

kennethreitz42 에 2014년 10월 05일

이 경고 기능이 무엇을 의미하고 경고가 어떻게 제어되는지 이해하지 못합니다.

requests 를 사용하는 모듈이 있고 verify=False 인수로 요청해야 합니다. 이로 인해 내 모듈의 사용자에게 불필요한 경고가 표시됩니다. 불필요한 경고는 중요한 경고를 보기 어렵게 만들고,

내 모듈이 경고를 비활성화하는 것이 합리적이지만 응용 프로그램에서 requests 를 사용하여 _다른 모듈에서도 경고를 비활성화할 것입니다!

경고를 비활성화하도록 모듈 사용자에게 지시해야 하는 경우 상황이 더 좋지 않습니다. requests 를 사용하고 있다는 사실은 일반적으로 사용자가 알 필요가 없는 보이지 않는 구현 세부 사항입니다. 그리고 사용자는 여전히 모든 것을 침묵시키거나 메모하는 옵션만 가질 수 있습니다.

나는 글로벌 경고가 도움이 될 것이라고 생각하지 않습니다.

urllib3.HTTPSConnectionPool 하위 클래스를 만들고 _validate_conn() 재정의하고 requests 가 다른 모듈에서 경고를 숨기지 않도록 내 모듈에서 이를 사용하도록 할 수 있지만 간단한 일에는 너무 많은 작업인 것 같습니다. .

kankri 에 2014년 10월 06일

이 경고 기능이 무엇을 의미하는지 이해하지 못합니다.
내 모듈의 사용자에게 불필요한 경고가 표시됩니다.

verify=False 하면 더 이상 네트워크 연결을 보호하지 않습니다. IMHO는 불필요한 경고가 아니라 _아닌_ 매우 관련성이 높은 경고입니다. 이전에는 인증서를 확인하지 않는다는 사실을 몰랐던 사용자는 이제 이것이 사실임을 알고 있습니다.

경고가 모듈에 대해 가치가 없다면 애플리케이션의 다른 모듈에는 가치가 없을 가능성이 높습니다(한 네트워크 지점에서 보안을 포기하면 다른 모든 곳에서 이에 대해 걱정할 필요가 없습니다). 전 세계적으로 비활성화하는 데 문제가 있다고 생각하지 않습니다.

Lukasa 에 2014년 10월 06일

사용자가 특정 요청에 대해 명시적으로 verify=False 를 요청하면 경고 표시 값이 표시되지 않습니다. 내가 모듈 작성자로서 verify=False 를 설정할 때 사용자의 요청에 따라 설정했습니다(또는 제가 악의적이지만 경고를 무시할 수 있기 때문에 경고도 도움이 되지 않습니다). 사실, 나는 악의적인 행동을 피하고 경고를 전역적으로 무음화하고 싶지 않습니다. 왜냐하면 그렇게 하면 응용 프로그램의 다른 부분이 무의식적으로 안전하지 않게 만드는 요청에 대한 유용한 경고가 제거되기 때문입니다.

또한 사용자가 확인을 명시적으로 해제한 요청에 대해 경고를 켜면 경고가 한 번만 제공되기 때문에 사용자가 경고를 원하는 요청도 숨깁니다. 경고는 또한 특정 요청의 URL을 언급하지 않기 때문에 사용자에게 실제로 도움이 되지 않습니다.

나는 한 네트워크 지점에서 보안을 버리는 것이 어떻게든 응용 프로그램에서 보안 검사를 쓸모 없게 만든다는 데 동의하지 않으며 어느 브라우저 공급업체도 마찬가지입니다. 브라우저를 사용하면 개별 URL에 대한 보안 검사를 우회할 수 있지만 나머지는 계속 검사하는 것이 마음에 듭니다.

내부 네트워크에서 자체 서명된 인증서로 내부 서버와 통신하지만 외부 호스트와도 통신하는 도구가 있는 경우 외부 통신을 확인하고 싶습니다. 이것은 내가 사용자로서 실수로 보안되지 않은 요청에 대한 경고를 보고 싶은 상황이 될 것입니다.

내가 service_foo 만들고 있고 누군가 앱에서 그것을 사용한다고 생각해보세요.

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)

service_foo 대한 2가지 옵션이 있습니다.

나는 글로벌 보안 경고를 계속
- 애플리케이션이 https://10.0.0.1 대화할 때 사용자는 항상 경고를 받습니다.
- https://example.com/submit 요청이 안전하지 않더라도 사용자는 경고를 받지 않습니다.
글로벌 보안 경고 끄기:
- https://example.com/submit 요청이 안전하지 않더라도 사용자는 경고를 받지 않습니다.

두 옵션 모두 좋지 않다고 생각하지만 옵션 1은 잘못된 경보를 제공하기 때문에 더 나쁩니다. 하지만 내 모듈 사용의 부작용으로 사용자에 대한 보안 검사를 끄는 것이 불편합니다.

쉘 스크립트로 이 작업을 수행하면 사용자가 더 행복하고 안전할 것입니다.

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

나에게는 Python 플랫폼의 구성이 손상된 경우에만 경고를 표시하는 것이 합리적입니다. InsecureRequestWarning 메시지에 링크된 https://urllib3.readthedocs.org/en/latest/security.html 페이지는 실제로 플랫폼의 문제를 해결하는 방법을 보여주기 위한 것입니다. 사용자 요청이 검증을 생략 할 경우 사용자가 요청하는 경우 경고가없는 같은 경고가 안 http URL 대신의 https 를.

kankri 에 2014년 10월 06일

사용자가 특정 요청에 대해 verify=False를 명시적으로 요청하면 경고 표시 값이 표시되지 않습니다.

'이용자'는 누구입니까? 귀하의 게시물을 통해 이 질문이 계속 제 마음에 떠올랐습니다. 귀하가 두 청중을 혼동하고 있다고 생각하기 때문입니다.

모듈 작성자가 verify=False로 설정하면 사용자의 요청에 따라(또는 내가 악의적으로) 설정합니다.

아니면 부주의하고 있습니다. 사용자가 자체 서명된 인증서와 상호 운용할 수 없다고 불평하게 하여 인증서 확인을 끄는 것이 해당 문제를 처리하는 방법이 _아니다_ 사실에도 불구하고 인증서 확인을 끕니다.

응용 프로그램의 다른 부분이 무의식적으로 안전하지 않게 만드는 요청에 대한 유용한 경고를 제거합니다.

이 문장은 나를 당황하게 한다. 그것은 응용 프로그램이 _무의식적으로_ 보안되지 않은 요청을 할 때 경고하는 것이 허용되지만 응용 프로그램이 _알고 있는_ 이러한 요청을 하는 것은 어떻게든 괜찮다는 것을 암시합니다. 나는 의도적으로 안전하지 않은 요청을 하는 것이 무의식적으로 그렇게 하는 것보다 어떤 식으로든 '더 안전한' 것으로 간주되어야 하는지 알지 못합니다.

또한 사용자가 명시적으로 확인을 해제한 요청에 대해 경고를 켭니다.

어떤 사용자? 모듈 작성자와 '사용자'를 어떻게 구별할 수 있습니까?

경고는 또한 특정 요청의 URL을 언급하지 않기 때문에 사용자에게 실제로 도움이 되지 않습니다.

경고는 경고 스팸을 생성할 위험이 있으므로 요청의 URL을 언급해서는 안 됩니다. 우리는 '이 특정 통신이 위험에 처해 있습니다'가 아니라 '이 응용 프로그램이 위험에 처해 있습니다'라고 _한번_ 경고합니다.

브라우저를 사용하면 개별 URL에 대한 보안 검사를 우회할 수 있지만 나머지는 계속 검사하는 것이 마음에 듭니다.

잘못된 인증서가 있는 URL에 액세스하면 브라우저 공급업체 _경고_! 대화 상자를 인쇄하고 URL 표시줄을 빨간색으로 강조 표시합니다! 그것이 _정확히_ 우리가 하는 일입니다. 우리는 당신이 아무것도 하는 것을 막지 않고 단지 "이봐, 이건 나쁘다!"라고 말하는 것뿐입니다. 당신이 우리에게 요구하는 것은 브라우저 공급업체에 사용자가 특정 URL에 대한 빨간색 경고를 끌 수 있도록 요청하는 것과 동일하며 보안에 미치는 영향이 어마어마하기 때문에 사용자가 이를 거부할 것임을 보장합니다.

내부 네트워크에서 자체 서명된 인증서로 내부 서버와 통신하지만 외부 호스트와도 통신하는 도구가 있는 경우 외부 통신을 확인하고 싶습니다.

아니요, 통신을 _모두_ 확인하려고 합니다. 자체 서명 인증서를 확인하십시오! 예상한 인증서를 받았는지 확인합니다. verify=False 는 보안에 대한 강력한 접근 방식으로 간주되어야 하며, 효과적으로 "보안 나사를 조여 작동시키십시오"라고 말합니다. 그것은 절대적으로 괜찮습니다. 당신은 그렇게 말할 권리가 있지만 우리는 그것을 안전하지 않다고 부를 의무가 있습니다.

두 옵션 모두 좋지 않다고 생각하지만 옵션 1은 잘못된 경보를 제공하기 때문에 더 나쁩니다.

옵션 1은 잘못된 경보를 제공하는 것이 아니라 실제 경보를 제공합니다. 10.0.0.1에 대한 통신은 _insecure_이며, 다른 척 해서는 안 됩니다.

쉘 스크립트로 이 작업을 수행하면 사용자가 더 행복하고 안전할 것입니다.

사용자는 더 행복할 수 있지만 더 안전하지는 않습니다. 그들은 이전만큼 안전할 것입니다. 이 경고를 끄면 마술처럼 인증서 확인이 사라지는 것처럼 보이지만 그렇지 않습니다. 이 답변의 끝에서 이에 대해 다시 언급하겠습니다.

나에게는 Python 플랫폼의 구성이 손상된 경우에만 경고를 표시하는 것이 합리적입니다.

아니요, Python 플랫폼의 구성이 손상되고 확인되지 않은 요청을 요청하지 않은 경우 열심히 실패해야 합니다. 플랫폼이 안전한 TLS 연결을 만들 수 없는 경우 사용자가 명시적으로 신경쓰지 말라고 명시적으로 말하는 상황( verify=False 설정)을 제외하고 절대 연결해서는 안 됩니다. 하려고 하는 것은 위험합니다.

나는 당신이 오해 속에서 일하고 있다고 생각합니다. 그래서 저는 아주 분명히 말하고 싶습니다: a) verify=False (우리의 경고 동작) 또는 b) 의도적으로 ssl 모듈을 방해하는 행위. 우리는 b)를 잡을 수 없으며 그것에 대해 경고하지 않습니다. 이것은 "플랫폼 문제"에 대해 제기한 개념에 해당하는 유일한 상황입니다. urllib3의 도움말 페이지에 있는 조언은 신뢰할 수 있는 인증서 번들링 및 인증서 수동 확인을 포함하여 필요한 모든 플랫폼 관련 단계를 수행하기 때문에 적용되지 않습니다.

웹 커뮤니티에는 신뢰할 수 있는 루트 인증서로 서명된 인증서만 확인해야 한다는 위험한 견해가 있습니다. 이 견해는 완전히 잘못된 것입니다. 자체 서명된 인증서가 있는 경우 이를 확인해야 합니다. 그것은 완전히 할 수 있습니다! 자체 서명된 인증서를 .pem 파일에 추가하고 verify 인수로 전달하십시오!

번들된 .pem 파일과 이를 결합하는 데 문제가 있는 경우 알려주시면 자신의 인증서를 신뢰할 수 있는 루트와 연결할 수 있도록 mkcert.org를 개선하겠습니다. 그러나 verify=False 이 안전한 척하지 마십시오. 실제로는 그렇지 않습니다.

Lukasa 에 2014년 10월 06일

또한 사용자가 확인을 명시적으로 해제한 요청에 대해 경고를 켜면 경고가 한 번만 제공되기 때문에 사용자가 경고를 원하는 요청도 숨깁니다.

이것도 좀 의외네요. verify=False 하면 해당 요청에 대해서만 명시적으로 해제할 수 있지만 요청을 구성하는 지점 이상으로 이를 전달할 방법이 없습니다. 또한 인증서 확인을 비활성화했기 때문에 그 이상을 전달할 이유가 없습니다. 귀하가 그렇게 한 상황은 당사 또는 귀하의 앱을 사용하는 모든 사람에게 중요하지 않습니다.

sigmavirus24 에 2014년 10월 06일

당신이 우리에게 요구하는 것은 브라우저 공급업체에 사용자가 특정 URL에 대한 빨간색 경고를 끌 수 있도록 요청하는 것과 동일하며 보안에 미치는 영향이 어마어마하기 때문에 사용자가 이를 거부할 것임을 보장합니다.

내 브라우저를 사용하면 "매우 안전하지 않은" 확인되지 않은 인증서를 영구적으로 수락할 수 있습니다.

10.0.0.1에 대한 통신은 안전하지 않으며 우리는 그렇지 않은 척해서는 안됩니다.

디지털 인증서를 확인할 수 없다는 점에서 연결이 안전하지 않지만 인증서를 확인한다고 해서 현재 대화 중인 서버가 안전한지 여부는 알 수 없습니다. 그러나 폐쇄된 네트워크의 서버와 대화할 때 서버의 보안을 실제로 확인할 수 있습니다.

나는 당신이 오해 속에서 일하고 있다고 생각합니다. 그래서 저는 매우 분명히 하고 싶습니다: a) verify=False(우리의 경고 동작)를 설정하거나 b) 의도적으로 SSL 방해

나는 그들이 나에게주는 URL에 대한 인증서 확인 및 경고를 무시하려는 사용자의 희망을 존중함으로써 내 모듈에서 어떻게 훌륭한 시민이 될 수 있는지 궁금합니다. 그리고 경고 모델이 추가하는 가치. verify=False 가 포함된 요청이 사용자에게 경고를 표시해야 하는 경우는 무엇입니까?

경고 메커니즘이 부주의한 코드를 포착하는 방법을 알 수 없습니다. 코드가 조잡해서 요청이 이루어진 것인지 사용자가 요청했기 때문인지 구분할 수 없기 때문입니다. requests 같은 모듈도 보안 정책을 지시해서는 안 된다고 생각합니다. 경고는 일반적으로 개발자를 대상으로 하여 잘못된 코드를 수정할 수 있다는 것을 이해했지만 이 경고는 그렇지 않습니다. 경고가 사용자의 일반 교육을 위한 것이라면 사용자가 쉽게 숨길 수 있는 방법이 있어야 합니다.

경고를 받는 것은 프로그램의 출력을 엉망으로 만들기 때문에 외관상 뿐만이 아닙니다.

경고의 음수 값만 표시되므로 전역 정책 변경 사항을 숨기고 싶지 않더라도 내 모듈에서 이 경고를 끕니다.

웹 커뮤니티에는 신뢰할 수 있는 루트 인증서로 서명된 인증서만 확인해야 한다는 위험한 견해가 있습니다. 이 견해는 완전히 잘못된 것입니다.

이런 뷰가 있는지 몰랐네요. 루트 인증서로 서명된 인증서는 실제로 사이트 보안에 대해 아무 것도 증명하지 않습니다. 나쁜 일을 하고 싶다면 익명의 인증서를 받는 것이 저렴합니다.

자체 서명된 인증서가 있는 경우 이를 확인해야 합니다. 그것은 완전히 할 수 있습니다! 자체 서명된 인증서를 .pem 파일에 추가하고 확인을 위한 인수로 전달하십시오!

사용자는 내부 신뢰할 수 있는 네트워크와 같이 인증서를 얻기 위해 보안 채널이 필요합니다. 그러나 서버 자체가 동일한 내부 네트워크에 있으면 얻는 것이 별로 없습니다. 그러나 이것은 어떤 경우에도 사용자가 결정하는 것이므로 내 모듈에 정책을 적용할 수 없습니다.

kankri 에 2014년 10월 07일

나는 대부분 @kankri 에 동의합니다. 그것이 원래 디자인 의도였습니다.

기본적으로 비활성화되어 있지만 다시 활성화하거나 켜는 방법을 문서화하는 자체 기능이 있는 것을 제안합니다. 나는 외부 사용자가 의도한 대로 코드를 사용하는 데 방해가 되는 것을 원하지 않습니다. verify=False 는 모범 사례는 아니지만 기능입니다. 그건 우리가 상관할 일이 아닙니다.

kennethreitz42 에 2014년 10월 07일

verify=False 가 기능이라는 점에는 동의하지만 params= 또는 cert= 와 같은 수준의 기능이라는 점에는 동의하지 않습니다. 보안 값으로 기본 설정되며 안전하지 않은 값으로 설정될 수 있는 기능입니다. 사람들이 편의를 위해 보안을 창밖으로 내던져 버리는 것은 거대하고 유혹적인 선택이며, 나는 그 충동을 억제해야 한다고 생각합니다(그러나 허용되지는 않음). 나는 항상 '당신은 분명히 불안해해야 한다'는 학파에 기댈 것이고, 그것이 하나가 아닌 두 개의 스위치를 켜는 것을 의미하는지 상관하지 않습니다.

어쨌든 이것은 내 전화가 아니라 당신의 전화입니다. =)

Lukasa 에 2014년 10월 07일

@kankri 와 @kennethreitz 의 말에 동의한다고 말하고 싶었습니다.

verify=False는 모범 사례는 아니지만 기능입니다. 그건 우리가 상관할 일이 아닙니다.

잘 요약합니다.

piotr-dobrogost 에 2014년 10월 09일

👍1

경고를 비활성화하려는 사람들을 위해 다음을 수행합니다. 표준 라이브러리의 일부인 warnings 모듈 을 사용해야 합니다.

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)

이것은 InsecureRequestWarning 범주의 경고를 무시하는 경고 필터를 구성합니다. 출력은 다음과 같습니다.

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

(테스트 사이트는 403 Forbidden 페이지를 반환하지만 여기서는 중요하지 않습니다.)

번들로 제공되는 urllib3 패키지의 클래스를 사용해야 하며, 설치되어 있는 경우 최상위 urllib3 패키지의 클래스가 아니라 사용해야 합니다.

코드의 가능한 가장 작은 영역에서 컨텍스트 관리자를 사용하는 작은 함수를 만들 수 있습니다.

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

mgeisler 에 2015년 01월 29일

또는 간단히 다음과 같이 하십시오.

requests.packages.urllib3.disable_warnings()

Lukasa 에 2015년 01월 29일

👍3

@루카사

또는 간단히 다음과 같이 하십시오.
requests.packages.urllib3.disable_warnings()

요청 매뉴얼에 이 기능에 대한 언급이 없다는 점을 제외하고는.

그것에 대해 아는 모든 사람과는 거리가 멀지만, 저는 warnings 모듈이 파이썬 프로그래머가 경고를 비활성화하고 싶을 때 살펴봐야 하는 표준 도구라고 주장합니다. 표준 라이브러리의 일부이며 잘 문서화되어 있습니다.

warnings 에 대한 참조를 requests 문서에 넣는 것이 좋습니다. 또는 원하는 경우 해당 enable_warnings 가 있는 한 편리한 disable_warnings 기능을 사용하는 것이 좋습니다. 기능(이런 기능 은 없는 것 같습니다 ).

mgeisler 에 2015년 01월 29일

다시 한 번: 일반적으로 경고를 비활성화하고 싶지 않습니다. 내 코드에서 _명시적으로_ verify=False를 설정할 때 이 특정 경고가 사라지기를 원합니다. 이 특별한 쓸모없는 경고와 달리 다른 유용한 경고가 있을 수 있습니다. 이것에 대해 이해하기 어려운 것은 무엇입니까?!

zaitcev 에 2015년 02월 04일

@zaitcev 나 자신을 반복 할 위험이 있습니다.

requests.packages.urllib3.disable_warnings()

Lukasa 에 2015년 02월 04일

그리고 그것이 당신에게 너무 광범위하다면:

from requests.packages.urllib3.exceptions import InsecureRequestWarning

requests.packages.urllib3.disable_warnings(InsecureRequestWarning)

Lukasa 에 2015년 02월 04일

👍2

마지막으로, @zaitcev 메모: 방금 한 분노한 어조를 취하는 것이 전혀 호의를 얻지 못한다는 것을 알게 될 것입니다. 우리는 모두 자원 봉사자이며 당신에게 무언가를 만드는 데 줄 수 있는 시간이 제한되어 있음을 기억하십시오. 당신이 대우받고자 하는 방식으로 우리를 대우해 주세요.

Lukasa 에 2015년 02월 04일

@zaitcev 이것은 requests 모듈 자체에서 변경될 것 내 다른 주석에 넣은 코드를 사용할 수 있기를 바랍니다. 그러면 urllib3에서 내보낸 경고를 선택적으로 비활성화할 수 있습니다.

mgeisler 에 2015년 02월 09일

다음을 사용하여 억제할 수도 있습니다.

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

제 경우에는 리퀘스트를 직접 사용하지 않기 때문에 이렇게 억제하면 나중에 깨질 걱정을 조금 덜 수 있습니다.

alicederyn 에 2015년 03월 23일

@zaitcev 이전 제안을 모두 종합하면 다음과 같이 할 수 있습니다.

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 에 2015년 04월 03일

@utkonos 그러면 모든 후속 요청에 대해 경고가 비활성화됩니다.

다른 예를 모아서 기본 Session 확장했습니다( requests.get 및 다른 단축키는 임시 Session 생성하므로 어쨌든).

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)

tuukkamustonen 에 2015년 06월 09일

requests 모든 경고를 비활성화하는 것은 나쁜 생각일 수 있습니다.

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

SEJeff 에 2015년 08월 12일

이 문제를 처리한 방법을 요약하면 다음과 같습니다.

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

이렇게 하면 요청이 안전하지 않은지 확인하고, urllib 경고를 숨기고, 사용자에 대해 내 자신의 형식에 대한 경고를 표시할 수 있습니다. 요청이 두 번 수행되어야 합니다. except 절이 덜 광범위하도록 수정되었습니다.

sky-shiny 에 2015년 08월 12일

except Exception: 는 매우 광범위합니다. 당신은 정말로 그것을 원하지 않습니다.

ThiefMaster 에 2015년 08월 12일

위의 내용은 이 논의의 양측에 대한 우려를 해결하는 방법입니다.

sky-shiny 에 2015년 08월 12일

대신 잡을 수있는 예외의 일부 하위 클래스가 발생하지 않습니까?

ThiefMaster 에 2015년 08월 12일

또는 logging.captureWarnings()

t-8ch 에 2015년 08월 12일

대안은 urllib3이 관련되어 있다는 것을 알고 네임스페이스를 하드코딩하는 것입니다(tuukkamustonen의 주석 참조). 이것이 나의 주된 반대였습니다. 그들이 제대로 작동하도록 만들 수 있었고, 심지어 풀 리퀘스트에서 패치를 제공했습니다. 그러나 그들은 문제가 존재한다는 것을 부인하고 모든 사용자에게 "예외 제외" 또는 "요청에서.패키지.urllib3 가져오기 예외"와 같은 끔찍한 해결 방법을 제시하도록 지시합니다. 이 시점에서 누군가는 자신이 항상 틀렸음을 인정해야 하므로 우리는 꼼짝 못하고 있습니다.

zaitcev 에 2015년 08월 12일

이것이 나의 주된 반대였습니다. 그들이 제대로 작동하도록 만들 수 있었고, 심지어 풀 리퀘스트에서 패치를 제공했습니다. 그러나 그들은 문제가 존재한다는 것을 부인하고 모든 사용자에게 "예외 제외" 또는 "요청에서.패키지.urllib3 가져오기 예외"와 같은 끔찍한 해결 방법을 제시하도록 지시합니다. 이 시점에서 누군가는 자신이 항상 틀렸음을 인정해야 하므로 우리는 꼼짝 못하고 있습니다.

@zaitcev 다시 한 번, 이 커뮤니티는 최선을 다하는 자원 봉사 커뮤니티임을 상기시켜 드립니다. 우리는 이 문제를 토론을 위해 무료로 남겨두었고 그것을 잠그거나 더 이상의 토론을 방지하려고 시도하지 않았습니다. 우리는 _귀 기울이고 있습니다_. 우리가 하지 않는 것은 상황에 대한 귀하의 평가에 즉시 동의하는 것입니다. 우리가 귀하의 것보다 더 많은 사용 사례에 관심을 갖고 있으며 모든 요구 사항의 균형을 맞춰야 할 가능성을 고려하십시오.

당신의 풀 리퀘스트는 당신이 지속적으로 무시하고 있는 _매우 구체적인 이유_로 인해 거부되었습니다! 나를 보자 자신이 인용 인용 이안 :

마무리 진술은 "이것이 대부분 urllib3에 있고 거기에서 승인에 의존한다는 점을 감안할 때 진행이 이루어질 때까지 이것을 닫을 것입니다. "(강조 내)였습니다.

오늘 현재까지 urllib3에서 이 문제에 대한 관련 pull 요청이나 문제를 볼 수 없습니다. 이 프로젝트의 누구도 방해하거나 이 작업이 발생하는 것을 막지 않았습니다. _현재 귀하와 동의하지 않기 때문에 우리가 직접 하기로 선택하지 않았습니다.

그러나 이 토끼굴에 다시 빠질 위험을 무릅쓰고 다시 말하겠습니다.

이것이 나의 주된 반대였습니다. 그들이 제대로 작동하도록 만들 수 있었을 것입니다.

귀하의 패치가 이 작업을 "올바른" 것으로 만들지 않는다고 생각합니다 . 이 스레드에서 여러 번 말했듯이 현재 동작이 바람직하다고 생각합니다. 안전하지 않은 TLS 요청을 수행하는 것은 나쁜 생각이며 사용자에게 그렇게 하지 않도록 주의해야 합니다.

제 입장은 사용자가 특히 자신의 비밀번호를 처리하는 시스템에서 적절하게 보호되지 않는 TLS 요청을 할 때 _알 권리가 있습니다_ 라는 것입니다.

이 스레드 에는 이러한 경고를 비활성화하기 위해 요청 수준 후크를 갖는 것을 고려해야 한다는 verify=False 와 verify=None 사이에 이전에 존재하지 않았던 구별을 추가해야 이러한 경고를 묵시적으로 차단할 수 있다고 생각합니다. 전자가 후자보다 훨씬 쉽다는 것을 알게 될 것입니다.

Lukasa 에 2015년 08월 13일

verify=False와 verify=None을 구별하지 않으려면 +1입니다. 나는 다음 중 하나를 지원합니다.

새 매개변수 추가(예: noInsecureWarnings), 또는
요청이 있으면 urllib3 경고를 가로채고 자체 경고를 발행하므로 (a) 'requests.packages.urllib3.exceptions.InsecureRequestWarning'보다 덜 무서운 것을 억제할 수 있습니다(어쨌든 이미 요청에 따라 다르지만 요청이 마이그레이션되면 중단됩니다. (b) 경고는 요청별 URL을 가리킬 수 있습니다(경고가 음영 처리되었으므로 현재 URL은 관련이 없습니다!)

그리고 이 문제가 해결되었는지 여부에 관계없이 요청을 지원하는 모든 자원 봉사자에게 감사드립니다. 훌륭한 라이브러리입니다. :)

alicederyn 에 2015년 08월 24일

여러분의 노고에 감사하는 멋진 라이브러리입니다.

최근에 파이썬 패키지를 업그레이드하고 새로운 InsecurePlatformWarning 출력물을 발견한 후 이 문제를 발견했습니다. 그래서 저는 제 유스 케이스에 기여하고 있는데, 이는 설득력이 있다고 생각합니다.

4가지 다른 환경에서 젠킨스 서버를 관리하기 위해 요청을 사용하고 있습니다. 세 가지 환경(개발, 스테이징, 프로덕션)에는 모두 유효한 인증서가 있습니다. 네 번째 환경은 개발자가 로컬 시스템에서 변경 사항을 테스트하는 데 사용할 수 있는 방랑 가상 상자입니다. 유효한 인증서가 없지만 정책에 따라 모든 서버 구성은 암호화되지 않은 요청을 거부합니다.

환경에 대한 jenkins 연결 설정(서버 이름, 토큰 등)에는 vagrant 환경에 대해서만 True로 설정되는 SSL 확인을 끄기 위한 특정 플래그가 포함됩니다.

내 설정에서 경고를 전역적으로 비활성화하는 것은 프로젝트가 다소 크고 요청 라이브러리가 있든 없든 많은 요청이 이루어질 수 있기 때문에 나쁜 생각입니다. 프로젝트의 일부에 플라스크 응용 프로그램 및 기타 가능한 다중 스레드 사례가 포함된다는 점을 제외하고 범위 내에서 경고를 비활성화하는 것은 괜찮습니다.

제 생각에는 verify=False 사용이 지원되고 경고 없이 예상대로 작동해야 하는 것 같습니다. 이것이 허용되어야 하는 시기와 여부를 결정하는 것은 애플리케이션 개발자에게 달려 있습니다. 예를 들어, 일반적인 사용을 위해 브라우저를 작성하는 경우 빨간색 텍스트가 많은 큰 확인 대화 상자를 표시하지 않고는 이것을 True로 설정하지 않을 것입니다. 하지만 내가 서버와 클라이언트를 소유하고 있고 인증서를 발급하지 않는 이유가 있다면 다른 잠재적인 문제를 숨기지 않고 깨끗한 로그를 가질 수 있어야 합니다.

jamie-sparked 에 2015년 09월 23일

이것이 허용되어야 하는 시기와 여부를 결정하는 것은 애플리케이션 개발자에게 달려 있습니다.

이 논쟁은 내가 당신과 다른 점입니다. 언제 사용해야할지 결정하는 것은 개발자의 몫이라고 생각합니다. 그러나 그 선택이 수용 가능한지 결정하는 것은 _user_에게 달려 있다고 생각합니다. 사용자가 개발자의 선택으로 인해 위험에 처할 때를 이해하고 해당 위험을 평가할 수 있다는 것은 _중요합니다_.

하지만 내가 서버와 클라이언트를 소유하고 있고 인증서를 발급하지 않는 이유가 있다면 다른 잠재적인 문제를 숨기지 않고 깨끗한 로그를 가질 수 있어야 합니다.

로깅 컨텍스트 관리자를 사용하여 경고를 캡처하면 그렇게 할 수 있습니다. 또한 요청에서 이 경고를 요청에 더 구체적으로 지정하여 캡처하기 더 쉽도록 하는 것도 고려하고 있지만 아직 발생하지 않았습니다.

Lukasa 에 2015년 09월 30일

@jamie-sparked와 비슷한 상황이 있습니다.

보안 강화에 대한 Lukasa의 요점을 이해하지만 사용자가 자신에게 가장 적합한 것을 결정하도록 해야 한다고 생각합니다.
요청은 최종 사용자 애플리케이션이 아닌 라이브러리입니다. IMO에서는 개발자를 사용자로 간주해야 합니다.
애플리케이션 개발자는 인증서 확인을 끄기로 결정한 경우 보안 실수에 대해 책임을 져야 합니다(예: verify=False).

개발자로서 나는 내가 해야 할 일을 지시하는 라이브러리보다 유연성을 중요하게 생각합니다.

다른 사람들이 말했듯이 BTW는 요청을 _훌륭하게 찾았으며 귀하의 모든 노력에 감사드립니다. 감사 해요.

thalesac 에 2015년 10월 06일

@thalesac 개발자가 결정하도록 _do_ 합니다. 이 스레드에서 _여러_번 논의했듯이 이 경고를 끄는 것이 가능합니다. 그러나 모든 경고를 끄는 스위치는 없습니다. 각 경고를 수동으로 수행해야 합니다. 이것은 사용자가 _의식적으로_ 각 안전 장치를 제거하도록 하려는 시도입니다.

심층 방어라고 생각하시면 됩니다. 총알을 비유하자면 안전장치가 있고 총알이 들어 있지 않은 총과 탄창을 제공합니다. verify=False 모든 경고를 비활성화하도록 했다면 탄창이 삽입될 때 자동으로 안전 장치를 비활성화하고 총알을 발사하는 총을 갖는 것과 같습니다. 편리한? 확신하는. 위험한? 물론이지.

Lukasa 에 2015년 10월 06일

유감스럽게도 나는 당신의 유추 모델에 동의하지 않습니다.
나는 verify=False가 당신의 안전/보안 메커니즘이라고 말하고 싶습니다. 명시적으로(또는 수동으로) 비활성화한 경우 나쁜 놈들을 쏠 때 총이 항상 경고하는 것을 원하지 않습니다. 분명히 기본 동작은 보안 사고를 강제해야 합니다.
어쨌든, 나는 이것이 단지 나의 견해라는 것을 이해하고 당신은 당신이 프로젝트에 가장 적합하다고 생각하는 것을 해야 합니다. 아마도 그것이 좋은 도서관인 이유일 것입니다. :)
감사 해요

thalesac 에 2015년 10월 06일

나는 Lukasa, 보안의 첫 번째 부분에 동의합니다. 개발자로서 코드의 한 부분에서 verify=False를 사용하는 경우 경고를 받고 싶지 않다면 경고를 표시하지 않아야 합니다.

어쨌든 팀 작업에 대한 훌륭한 라이브러리 열렬한 팬입니다. 계속해서 인내심을 갖고 우리에게 응답할 수 있도록 +10000입니다.

Divagnz 에 2015년 10월 13일

내가 볼 때 응용 프로그램이 사용자가 설정한 URL을 사용하는 경우 사용자에게 확인을 비활성화하는 옵션이 제공되어야 하지만 모든 상황에서 경고를 받아야 한다고 생각할 수 있습니다. 개발자로서 유효한 인증서가 없을 것으로 예상되는 URL(인증서, 테스트 등의 비용을 지불하지 않는 내부 서비스)에 연결하는 이유를 알고 있다면 비활성화할 수 있는 옵션이 있어야 합니다. 확인 비활성화와 함께 경고.

동시에 조용히 무시되는 보안 문제를 너무 쉽게 열 수 있으므로 한 번에 전역적으로 경고를 비활성화하려는 상황이 발생하는 것이 일반적이라고 생각하지 않습니다.

thexder1 에 2015년 10월 27일

requests.packages.urllib3.disable_warnings() 예 작동합니다

101t 에 2015년 11월 19일

안녕하세요

requests.packages.urllib3.disable_warnings() 가) 더 이상 작동하지 않습니까? 그것은 나를 위해 경고를 침묵시키는 데 사용되었습니다. 여기 에서 경고 비활성화 기능을 호출하고 있으며 경고 기능이 호출되는 역추적의 예는 다음과 같습니다.

 [+] 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()
 -> 반환 함수()
 /usr/local/lib/python2.7/dist-packages/cement/core/controller.py(472)_dispatch()
 -> 반환 함수()
 /root/droopescan/dscan/plugins/internal/scan.py(114)default()
 -> 팔로우_리디렉션)
 /root/droopescan/dscan/plugins/internal/scan.py(230)_process_cms_identify()
 -> inst.cms_identify(url, opts['timeout'], self._generate_headers(host_header)) == True인 경우:
 /root/droopescan/dscan/plugins/internal/base_plugin_internal.py(910)cms_identify()
 -> 헤더)
 /root/droopescan/dscan/plugins/internal/base_plugin_internal.py(827)enumerate_file_hash()
 -> r = self.session.get(url + file_url, timeout=timeout, headers=headers)
 /usr/lib/python2.7/dist-packages/requests/sessions.py(480)get()
 -> 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(요청, **kwargs)
 /usr/lib/python2.7/dist-packages/requests/adapters.py(376)send()
 -> 시간 초과 = 시간 초과
 /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py(559)urlopen()
 -> 본문=본문, 헤더=헤더)
 /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((

다음은 pip freeze 의 출력입니다. 저는 데비안 테스트를 사용하고 있습니다.

 argparse==1.2.1
 아름다운 수프4==4.4.1
 시멘트==2.6.2
 샤르데==2.3.0
 컬러라마==0.3.3
 적용 범위==4.0.3
 암호화==1.2.1
 distlib==0.2.1
 -e [email protected]:droope/droopescan.git@6524a9235e89a6fdb3ef304ee8dc4cb73eca0386#egg=droopescan-development
 enum34==1.1.2
 기능식==0.4
 선물==3.0.4
 html5lib==0.999
 httplib2==0.9.1
 아이디==2.0
 IP 주소==1.0.16
 lxml==3.5.0
 수은==3.5.2
 모의==1.3.0
 ndg-httpsclient==0.4.0
 코==1.3.7
 pbr==1.8.1
 pyOpenSSL==0.15.1
 pyasn1==0.1.9
 파이컬==7.21.5
 파이스타치==0.5.4
 파이썬-apt==1.1.0b1
 파이썬 데비안==0.1.27
 파이썬-debianbts==2.6.0
 버그 보고==6.6.6
 요청==2.9.1
 응답==0.3.0
 재시도==1.3.3
 6==1.10.0
 urllib3==1.13.1
 휠==0.26.0
 wsgiref==0.1.2

감사 해요,
페드로

droope 에 2016년 02월 04일

disable_warnings 경고 기능이 호출되는 것을 방지하지 않고 출력을 억제합니다. 다른 코드 비트가 모든 경고를 활성화하면 문제가 발생할 수 있습니다.

Lukasa 에 2016년 02월 05일

안녕하세요 @Lukasa ,

if 뒤에 중단점을 넣었습니다. 결국 너무 많은 문제에 직면하여 데비안 테스트 사용을 중단했습니다. 이것은 아마도 그 중 하나일 것입니다. 나는 내 의견을 무시할 것입니다. 무슨 일이 일어 났는지 확실하지 않지만 많은 사람들에게 영향을 줄 일은 아닐 것입니다.

감사 해요!
페드르

droope 에 2016년 02월 06일

예, 따라서 데비안의 패키지를 사용하는 경우 판매하지 않는 논리로 인해 여기에서 문제가 발생했을 수 있습니다.

Lukasa 에 2016년 02월 06일

verify=False 을 지정하여 안전하지 않은 요청을 하고 해당 요청에 대한 경고를 표시하지 않고 다른 곳에서 이루어진 다른 요청에 대한 경고를 방해하지 않으려는 것은 완벽하게 합리적으로 보입니다.

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

j0hnsmith 에 2017년 01월 21일

Requests: 확인=거짓 및 requests.packages.urllib3.disable_warnings()

가장 유용한 댓글

모든 57 댓글

관련 문제