Lamentablemente, no existe tal característica, ya que es el fallo del protocolo de enlace TLS, que es antes de que deba golpear la lógica de la aplicación. Sin embargo, es posible que se esté perdiendo el verdadero problema aquí con toda verdad y honestidad si alguien ha liberado un código que no está verificando el TLS correctamente o está ignorando activamente los errores del TLS.
El problema de los programadores inexpertos que no saben cómo probar su código
Porsupuesto,aestecómiclefaltaelprogramadorexpert:"Oh, finalmente está pasando todas sus pruebas. Bien".
Creo que una pregunta más importante es "¿Por qué un desarrollador necesita un certificado autofirmado?" y si la respuesta es "Pruebas" entonces hay mucho mejores, más seguros , y formas más fáciles de manejar las pruebas que no requieren certificados o servidores . Si un desarrollador no puede descubrir cómo probar el código para un servidor o una aplicación cliente fuera de un entorno de cliente y servidor, entonces, ¿qué está haciendo ese código en la base de código de producción y por qué ese desarrollador no recibe ayuda para llevarlos a un nivel más rápido y seguro? ¿Prácticas y patrones de diseño?
Con el código siendo solo eso: código; hay infinitas formas de probarlo que no requieren un servidor, certificado o incluso horas de trabajo. Deben adoptar esas formas de avanzar e integrar esos patrones en el código más antiguo de manera retroactiva.
"¿Pero qué pasa si un desarrollador no quiere?" Es un argumento común contra esto. Para eso, la respuesta es "Entonces, busque un desarrollador que crea en las prácticas de diseño adecuadas y seguras". Fin. De. Historia. No vale la pena los errores, los dolores de cabeza y la pérdida de tiempo / beneficio que presentarán con su falta de respeto por los estándares establecidos por aquellos más experimentados que ellos mismos de los que podrían aprender. Tampoco importa si tienen más años de experiencia, porque su experiencia es incorrecta. Es especialmente cierto, ya que estas prácticas de diseño son gratuitas y están disponibles.
Con una carga de recursos gratuitos y una instrucción adecuada, es una maravilla que cualquier otra cosa que no sea una pequeña empresa sin experiencia alguna vez se encontraría en esta situación, pero sucede. Incluso entonces, no es sorprendente que muchas de estas empresas lleguen al mismo punto en el tiempo en que adoptan estas prácticas.
Un ejemplo
Ahora, esto puede parecer como si solo estuviera despotricando y deseando (sería catártico), pero con toda honestidad, este es un patrón fácil de adoptar. Veamos un ejemplo para el controlador de ruta NodeJS
En este ejemplo, vamos a escribir un controlador de ruta que registrará un visitante en el sitio y luego procederá al siguiente controlador.
handler.js
module.exports = route //export the route for importing and compilation in another file
function route(req, res, next){
req.app.locals.plugins.logVisit(req)
.then(error => error ? next(error) : next())
}
Ahora tenemos que probar esta ruta. Permite escribir una prueba sin ninguna biblioteca de pruebas que arroje la cantidad de pruebas exitosas y las pruebas fallidas y solo probar esta ruta
test.js
let handler = require('./handler')
let passed = 0;
let failed = 0;
let goodReq = {
app: {
locals: {
plugins: {
logVisit(req){
req != null
? ++passed && console.log('Properly passed the request object for logging')
: ++failed && console.log('Did not pass the request object for logging')
return Promise.resolve()
}
}
}
}
}
let goodNext = function (error){
if (error){
return ++failed && console.log('Improperly handled a good logVisit call')
}
++passed && console.log('Properly handled a good logVisit call')
}
let badReq = {
app:{
locals:{
plugins:{
logVisit(req){
req != null
? ++passed && console.log('Properly passed the request object for logging')
: ++failed && console.log('Did not pass the request object for logging')
return Promise.resolve(new Error('Failed logVisit called'))
}
}
}
}
}
let badNext = function (error){
if (!error){
return ++failed && console.log('Failed handling an error logVisit call')
}
++passed && console.log('Properly handled an errored logVisit call')
}
typeof handler == 'function'
? ++passed && console.log('The handler is a function')
: ++failed && console.log('The handler is not a function')
if (failed) {
throw new Error('The handler is not a function. It cannot be called as such, aborting future tests')
}
console.log('Handler will call logVisit and recieve a non errored state')
handler(goodReq, null, goodNext)
if (failed) {
throw new Error('The handler did not properly call and handle logVisit success. Aborting future tests')
}
console.log('Handler will call logVisit and recieve an errored state')
handler(badReq, null, badNext)
if (failed) {
throw new Error('The handler did not properly call and handle logVisit error. Aborting future tests')
}
setTimeout(() => {
console.log('All tests for the handler passed! It is now ready for integration testing')
console.log('# of Tests: ', (passed + failed))
console.log('Number of failed tests: ', failed)
console.log('Number of passed tests: ', passed)
}, 1000);
Como puede ver, ni siquiera NECESITAMOS un servidor para probar el código, un certificado autofirmado o incluso una biblioteca de pruebas (aunque eso probablemente hubiera facilitado la prueba). Antes de que este controlador entrara en un servidor, se probaría. En ese punto, el desarrollador ya sabe que funciona según lo previsto. No necesita un certificado autofirmado. También se puede probar que las pruebas funcionan ejecutándolas.
Mientras tenga las pruebas adecuadas, no necesita un certificado autofirmado.