Certaines requêtes HTTP proxy échouent sous Windows (schannel : prochain échec de InitializeSecurityContext)Bonjour, nous avons constaté que certaines requêtes HTTP (en particulier vers AWS S3) échouent avec un proxy HTTP sous Windows avec l'erreur :
schannel : le prochain InitializeSecurityContext a échoué : erreur inconnue (0x80092012)
Il semble que cela puisse être lié à ces problèmes de curl :
Avez-vous des suggestions sur la façon de résoudre ou de contourner ce problème ? Cela empêche les requêtes HTTP de fonctionner correctement lors de l'utilisation de JMP dans des environnements proxy d'entreprise courants. Il est donc important que nous résolvions ce problème.
Automatisation et scriptsAccès aux donnéesles fenêtresRe : Certaines requêtes HTTP proxy échouent sous Windows (schannel : échec de InitializeSecurityContext suivant)Quelle version de JMP ? Si 17, cela ressemble à un problème de support technique. (Onglet, haut de la page.)
Suggestions de solution de contournement :
Si vous pouvez télécharger une copie de curl contenant les correctifs dont vous avez besoin, Le site Web veut un mot de passe montre comment appeler curl avec RunProgram.
Si vous devez utiliser curl sur une machine Linux à partir de JMP sur une machine Windows, ces éléments peuvent être utiles : ils ont tous la même idée d'utiliser plink (putty) pour créer un shell distant. Je n'irais pas là-bas si vous pouviez mettre curl sur la machine Windows.
JSL peut-il communiquer avec Linux ?
JSL pour contrôler la caméra Raspberry
Beowulf, Newton et M. Hanson
Arithmétique à précision multiple avec Python
Re : Certaines requêtes HTTP proxy échouent sous Windows (schannel : échec de InitializeSecurityContext suivant)Les erreurs schannel sont Windows sont généralement dues à l'utilisation de certificats https et auto-signés ou de certificats dont la révocation ne peut pas être vérifiée.
La requête HTTP, qui utilise libcurl, est liée dynamiquement à WinSSPI qui est le « coffre-fort » de certificat pour le système d'exploitation. Tout certificat installé localement ne peut pas être vérifié.
curl que Craige mentionne désactive automatiquement la vérification, ce qui, même s'il fonctionne, annulera l'utilisation de https. Autrement dit, la connexion sera toujours chiffrée, mais le certificat utilisé pour la chiffrer n'est pas vérifié. Bref, il faut savoir que vous lui faites confiance.
HTTP Request vous permet de désactiver la sécurité à l'aide de Secure(0)
En plus,
JMP 16 introduit :
Certificates( "c:\certs\my_certificate.crt" );
ce qui vous permettra d'utiliser votre propre fichier de certificat
et
Verify SSL( "false" )
ce qui désactivera la vérification du certificat.
