Purtroppo non esiste una funzionalità di questo tipo in quanto è l'errore di handshake TLS che è prima che si verifichi la logica dell'applicazione. Ad ogni modo, potresti perdere il vero problema qui in tutta verità e onestà se qualcuno ha rilasciato codice che non sta verificando correttamente TLS o sta ignorando attivamente gli errori TLS.
Il problema dei programmatori inesperti che non sanno come testare il loro codice
Ovviamenteaquestofumettomancailprogrammatoreesperto:"Oh, sta finalmente superando tutti i test. Bene."
Penso che una domanda più importante sia "Perché uno sviluppatore ha bisogno di un certificato autofirmato?" e se la risposta è "Test" allora ci sono molto meglio, più sicuro e modi più semplici per gestire i test che non richiedono certificati o server . Se uno sviluppatore non riesce a capire come testare il codice per un server o un'applicazione client al di fuori dell'ambiente client e server, cosa sta facendo quel codice nella base del codice di produzione e perché lo sviluppatore non riceve aiuto per renderli più veloci e sicuri pratiche e modelli di progettazione?
Il codice è solo questo: codice; ci sono infiniti modi per testarlo che non richiedono un server, un certificato o anche l'orario di lavoro. Dovrebbero adottare quei modi per andare avanti e integrare retroattivamente questi modelli nel vecchio codice.
"E se uno sviluppatore non lo desidera?" è un argomento comune contro questo. Per questo la risposta è "Allora vai a trovare uno sviluppatore che crede in pratiche di progettazione corrette e sicure". Fine. Di. Storia. Non vale la pena di bug, mal di testa e tempo / profitto persi che introdurranno con il loro dilagante disprezzo per gli standard stabiliti da quelli più esperti di loro stessi da cui potrebbero imparare. Non importa se hanno più anni di esperienza, perché la loro esperienza è sbagliata. Lo è soprattutto perché queste pratiche di progettazione sono gratuite e prontamente disponibili.
Con un carico di risorse gratuite e istruzioni corrette è una meraviglia che qualcosa di diverso da una piccola società inesperta possa mai imbattersi in questa situazione, ma succede. Anche allora non sorprende che molte di queste aziende raggiungano lo stesso punto nel tempo in cui adottano queste pratiche.
Un esempio
Ora questo può sembrare che io stia scherzando e vaneggiando (con sarebbe catartico) ma in tutta onestà questo è un modello facile da adottare. Vediamo un esempio per il gestore delle rotte di NodeJS
In questo esempio scriveremo un gestore di route che registrerà un visitatore sul sito e poi passerà al gestore successivo.
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())
}
Ora dobbiamo testare questa rotta. Consente di scrivere un test senza alcuna libreria di test che emetterà il numero di test riusciti e test non riusciti e testerà solo questa rotta
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);
Come puoi vedere, non abbiamo nemmeno bisogno di un server per testare il codice, un certificato autofirmato o anche una libreria di test (anche se probabilmente avrebbe reso più facile il test). Prima che questo gestore entrasse in un server, sarebbe testato. A quel punto lo sviluppatore sa già che funziona come previsto. Non ha bisogno di un certificato autofirmato. Può anche essere provato che i test funzionano eseguendoli.
Se hai un test corretto, non hai bisogno di un certificato autofirmato.