@ChALkeR Merci pour le pointeur. Cela nous sera utile lorsque nous y arriverons. N'hésitez pas à envoyer un PR si vous vous sentez inspiré :-)

@tvrprasad : @ChALkeR fait partie de l'équipe Node.js et cet article est principalement destiné à nous avertir que cette fonctionnalité est obsolète. Je ne pense pas qu'il utilise réellement tedious . ??

@ChALkeR : Je connais cette dépréciation depuis un certain temps, mais la documentation autour de cette dépréciation est vraiment rare. Les exemples que j'ai vus jusqu'à présent (comme le PR pour node-mysql ) se concentrent sur les mises à niveau "simples" de TLS, où la connexion est simplement basculée de non-TLS à TLS.

Dans TDS, la mise à niveau de TLS est beaucoup plus complexe, tous les paquets d'établissement de liaison doivent être encapsulés dans des messages TDS, puis une fois la connexion établie, tous les autres paquets TLS n'ont plus besoin d'être encapsulés. L'implémentation via tls.createSecurePair était assez simple, mais la dernière fois que j'ai essayé cela via TLSSocket , je n'ai pas pu le faire fonctionner. ??

Je réessayerai quand j'y arriverai, mais je ne pense pas que grand chose ait changé.

Un autre problème que j'ai rencontré est que l'encapsulation d'un socket du package readable-stream dans un TLSSocket provoquerait une erreur de segmentation (!) du processus Node.js. Malheureusement, je n'ai pas d'étapes de reproduction à portée de main pour le moment. ??

@arthurschreiber Merci pour l'info :-)

mais la dernière fois que j'ai essayé cela via TLSSocket, je n'ai pas pu le faire fonctionner.

Si ce travail est sur github, merci de m'envoyer un pointeur. Je suis curieux de le vérifier.

@tvrprasad @arthurschreiber Voici des informations sur la façon de remplacer tls.createSecurePair https://nodejs.org/dist/latest-v6.x/docs/api/tls.html#tls_class_securepair

J'ai rencontré le même problème sur Node v8.0.1. Mon application signale l'erreur suivante, après avoir essayé d'établir une connexion cryptée :

(node:6344) [DEP0064] DeprecationWarning: tls.createSecurePair() is deprecated. Please use tls.Socket instead.

J'utilise patriksimek/node-mssql et le pilote tedious (le pilote par défaut de node-mssql ) pour accéder à notre base de données Microsoft SQL Server.

Même problème que @olange utilisant node-mssql avec un pilote fastidieux.

Listening on port 4000
(node:4402) [DEP0064] DeprecationWarning: tls.createSecurePair() is deprecated. Please use tls.Socket instead.

S'il vous plaît, ne vous méprenez pas et j'apprécie vraiment vos efforts pour maintenir ce module en place, mais y a-t-il une prédiction quand il sera corrigé?

En utilisant le package 'mssql' et en utilisant les options :
{
crypter : vrai
}

(nœud:13508) [DEP0064] Avertissement de dépréciation : tls.createSecurePair() est déprécié. Veuillez utiliser tls.Socket à la place.

Lorsque l'équipe Node désapprouve quelque chose comme ça, quel est le délai de suppression dans Node ? Juste curieux.

Sera probablement supprimée dans le nœud 9 ou 10. La fonctionnalité est obsolète depuis au moins 4 ans. :-/ C'est l'un des seuls packages NPM populaires qui l'utilise encore.

Est-ce que quelqu'un parmi les collaborateurs a un calendrier sur le moment où le changement sera publié ?

Obtenir cela aujourd'hui puisque je viens de mettre à jour nos systèmes vers le nœud 8.9.0 lts. J'ai deux gros projets en ce moment, mais s'ils s'améliorent tous les deux, je verrai si je peux consacrer du temps à régler ce problème.

@Iiridayn Ce serait génial !
J'y ai jeté un coup d'œil, mais je n'ai pas trouvé comment obtenir le paquet de poignée de main de TLSSocket, bloqué au même point que https://github.com/tediousjs/tedious/issues/515#issuecomment -283191248 :confused:
J'aimerais entendre si vous avez des idées à ce sujet.

Des progrès là-dessus ? Je suis confronté au même problème en essayant de me connecter à Azure, juste si cela peut aider.
Je serais reconnaissant si quelqu'un m'expliquait rapidement quelle est la conséquence de l'exécution d'une application alors qu'elle est obsolète, les requêtes SQL que je demande ne sont pas exécutées et j'ai besoin de savoir si c'est la cause, mais les textes à ce sujet je ' ai lu ne sont pas très éloquents.

Merci d'avance.

@ Jorgeee1 Ceci n'est qu'un avertissement, il est peu probable que ce soit la raison de vos ennuis. J'utilise également fastidieux pour me connecter à Azure DB et cela fonctionne bien.

J'ai écrit une preuve de concept rapide pour remplacer createSecurePair par TLSSocket + un serveur TCP pour obtenir les données brutes de la poignée de main. Vous pouvez y jeter un œil ici . Les tests d'intégration que j'ai pu exécuter ont réussi.

Ce n'est évidemment pas une vraie solution au problème en question (à moins que manger des prises supplémentaires, etc. ne soit acceptable). Il s'agit plutôt d'un déclencheur de discussion. Ce serait bien d'avoir des suggestions et des discussions sur https://github.com/nodejs/help/issues/1010.

@joux3 c'est génial 😃 Pouvez-vous créer un PR ? Il sera plus facile d'examiner et de discuter là-bas.

Les projets lourds ne se sont pas allégés, un troisième a été ajouté et nous avons également migré vers MySQL. Désolé, je ne pourrai pas résoudre ce problème - bonne chance à vous :).

Veuillez le corriger, c'est un problème important

Salut tout le monde,

permettez-moi de donner une mise à jour rapide sur l'état actuel ici. Je comprends que le message de dépréciation puisse être une nuisance, mais ce n'est pas vraiment un problème. tls.createSecurePair peut-être obsolète, mais à court et moyen terme, il n'ira nulle part. Selon https://github.com/nodejs/node/pull/17882 , il ne sera pas supprimé de sitôt.

Aussi, https://github.com/nodejs/node/pull/17882 propose une ré-implémentation de tls.createSecurePair en termes d'API publique node.js, introduisant un (pour l'instant) interne DuplexSocket classe. Les bases de cette implémentation sont exactement ce dont nous avons besoin pour s'éloigner de tls.createSecurePair ennuyeux, sans recourir à des hacks intéressants mais pas vraiment viables comme le propose @joux3. Nous devrons probablement créer notre propre version DuplexSocket pour le moment, mais au moins j'ai maintenant une bonne idée de la façon de résoudre ce problème une fois qu'il sera clair quand tls.createSecurePair sera réellement supprimé .

S'il vous plaît laissez-nous savoir ce que vous pensez! ??

@arthurschreiber Fwiw, je viens également de publier cette implémentation de DuplexPair sur https://www.npmjs.com/package/duplexpair. Je suppose que vous pourriez créer un wrapper autour de cela pour avoir un sosie de tls.createSecurePair() assez facilement ?

@addaleax Doux ! ❤️ C'est super et je vais voir si je peux brancher ça et nous éloigner de tls.createSecurePair plus tôt possible ! Merci beaucoup! ??

@arthurschreiber Je pense qu'un patch pour cela pourrait sembler aussi simple que ceci :

diff --git a/package.json b/package.json
index bca5b266849d..8cc0ed957577 100644
--- a/package.json
+++ b/package.json
@@ -43,6 +43,7 @@
     "babel-runtime": "^6.26.0",
     "big-number": "0.3.1",
     "bl": "^1.2.0",
+    "duplexpair": "^1.0.1",
     "iconv-lite": "^0.4.11",
     "readable-stream": "^2.2.6",
     "sprintf": "0.1.5"
diff --git a/src/message-io.js b/src/message-io.js
index 6c2a15c32a9f..a1de3a1e91c0 100644
--- a/src/message-io.js
+++ b/src/message-io.js
@@ -1,7 +1,9 @@
+'use strict';
 const tls = require('tls');
 const crypto = require('crypto');
 const EventEmitter = require('events').EventEmitter;
 const Transform = require('readable-stream').Transform;
+const DuplexPair = require('duplexpair');

 const Packet = require('./packet').Packet;
 const TYPE = require('./packet').TYPE;
@@ -84,10 +86,14 @@ module.exports = class MessageIO extends EventEmitter {
   startTls(credentialsDetails, hostname, trustServerCertificate) {
     const credentials = tls.createSecureContext ? tls.createSecureContext(credentialsDetails) : crypto.createCredentials(credentialsDetails);

-    this.securePair = tls.createSecurePair(credentials);
+    const duplexpair = new DuplexPair();
+    this.securePair = {
+      cleartext: new tls.TLSSocket(duplexpair.socket1),
+      encrypted: duplexpair.socket2
+    };
     this.tlsNegotiationComplete = false;

-    this.securePair.on('secure', () => {
+    this.securePair.cleartext.on('secure', () => {
       const cipher = this.securePair.cleartext.getCipher();

       if (!trustServerCertificate) {

Mais cela ne semble pas être testé dans le cadre de la suite de tests régulière, donc je ne sais pas comment m'y prendre…

J'ai encore essayé de remplacer SecurePair. Les tests d'intégration semblent bien se passer, testés sur Node 9. https://github.com/joux3/tedious/commit/6d255fbdaa2f9afd388617e6e34815cae95292a0

Cependant, j'ai quelques observations (mais peut-être que le patch est assez bon pour qu'un PR discute des problèmes ?) :

• Node.js 6 semble totalement planter sur Assertion failed: (uv__stream_fd(stream) >= 0), function uv_read_start, file ../deps/uv/src/unix/stream.c, line 1517.
• J'ai dû supprimer la falsification de la minuterie du test de temporisation de nouvelle tentative, la fausse minuterie semble casser DuplexPair en interne
• Je n'ai pas testé les connexions non cryptées. Ceux-ci pourraient être affectés par les changements de flux logique (les signaux ne semblaient pas se propager correctement à travers les tuyaux, il y a donc un gestionnaire manuel close sur le socket)'

Un grand merci à @addaleax pour votre travail !

@joux3 est-ce que votre fork est prêt à être utilisé avec Node 8 - la version LTS actuelle ? et est-ce possible d'ouvrir une pull request ? J'aimerais voir si cela résout un problème que j'ai en l'utilisant en conjonction avec https://github.com/patriksimek/node-mssql/ merci !

J'ai dû supprimer la falsification de la minuterie du test de temporisation de nouvelle tentative, la fausse minuterie semble casser DuplexPair en interne

@joux3 De quel test s'agirait-il ? (Je suis désolé, je ne connais pas particulièrement cette base de code au-delà de ce que j'ai examiné pour ce problème)

@addaleax , le test défaillant est https://github.com/tediousjs/tedious/blob/f5a0f95a5a522ad6a312170201b829e70c866976/test/integration/connection-retry-test.js#L73 -L104
La désactivation du minuteur est ici : https://github.com/tediousjs/tedious/pull/689/files#diff -ed1dc3ba8a10a8fb4b18a528b35bad00.
Edit: j'ai restauré la falsification de la minuterie en simulant uniquement setTimeout https://github.com/tediousjs/tedious/pull/689/commits/ff5d5eb1a3603db05266306a823fa49a98b50209.

@jimmont , j'ai ouvert une pull request sur https://github.com/tediousjs/tedious/pull/689 (on dirait que référencer l'identifiant du problème dans le nom du PR n'est pas suffisant...). Les tests d'intégration passent sur Node 8, mais il y a encore du travail à faire.

Pour réparer ça au plus vite !

Des progrès sur celui-ci ? Ce serait bien si nous pouvions obtenir une mise à jour sur ce problème.

Lier le PR #689 pour le suivi.

Dans un monde où les avertissements sont envoyés à stderr au lieu de stdout. <fail/>

toute mise à jour?

738 contient un correctif et sera fusionné et publié une fois examiné par un membre de l'équipe @tediousjs/microsoft-contributors.

Après une longue période de va-et-vient, cela a finalement été (et correctement) corrigé via https://github.com/tediousjs/tedious/pull/738. [email protected] est maintenant disponible sur npm. Il est actuellement étiqueté comme next et je m'assurerai qu'il sera bientôt étiqueté comme latest .

Merci à tous pour votre patience et votre aide pour résoudre ce problème ! ??