Kändes inte helt OK att köra ett perl-script med root-rättigheter som uppdaterar sig själv via nätet ...

Jag har gjort ett script i NodeJS (JavaScript) för er som kör Nginx:

https://github.com/Z3TA/letsencrypt-nodejs-nginx

Fritt att kopiera och modifiera.

certbot och följande crontab rad löser problemet:

https://bjornjohansen.no/lets-encrypt-for-nginx
https://www.digitalocean.com/communi...n-ubuntu-14-04

Även cPanel har nu detta inbyggt via deras AutoSSL funktion i v58. Man måste aktivera det bara via ett script man kör som root, sen så fungerar det riktigt smidigt!

Har man inte tillgång till root utan kör bara vanligt webbhotellskonto kan man använda "WP Encrypt" i Wordpress och sedan läsa key-file som man lägger in i t.ex. Cpanel som en vanlig SSL installation.

Pluginet kan autouppdatera certifikatet efter 90 dagar med.

SSL hanteras enklast sen i Wordpress med pluginet "Really Simple SSL".

Tog en snabb titt på koden. Du har en del try-catch block på asynkrona metod-anrop som inte kommer fungera. Ett tips är att använda en linter om du är osäker på vad som fungerar och ej.

Edit: EsLint med Googles regler ger 499 fel och Flow Type runt 100.

Tack för din feedback! readFileSync är dock en synkron funktion !!

Angående "linters" så är min erfarenhet att de nästan aldrig upptäcker buggar. Av de 499 "felen" du hittade beror troligtvis de flesta på att jag använder tab i stället för mellanslag som indentering ...

Helt rätt, mitt fel.

Stängde av indenteringsreglerna för filen. En majoritet försvann, men 196 återstår. Några exempel är '==' istället för '===', dubbeldeklarering av variabler, ohanterade callback-fel, importering utanför headern, djup nästade callback, långa rader, användning av variabler ej ännu deklarerade.

Vad är din uppfattning av en linter, dess användning och vilken funktion anser du att den fyller?

En linter kan vara bra om man arbetar i ett team, och kommit överens om att koden ska se ut på ett speciellt sätt. Jag tycker dock det läggs allt för mycket tid på meta-programmering, till exempel omstrukturering av koden för att hålla raderna under 80 tecken, vilket ibland kan kräva kluriga lösningar som gör koden svårare att förstå.



importering i headern uppmanar till att använda globala variabler! Jag försöker undvika globala variabler så långt som möjligt. En unik grej med modul-systemet common-js är att man kan importera moduler lokalt!! Koden blir så mycket lättare att förstå då.


'==' istället för '===' ... Om jag skulle skriva if(foo===undefined) skulle jag även behöva lägga till if(foo===null). Så det är lite av en bekvämlighet, jag fångar två flugor i en smäll. Man bör dock undvika att jämföra olika typer. Ex: if("42"==42) . Men vad hjälper det om det blir false i stället för true !? Eventuella buggar kvarstår ändå. Man bör i stället konvertera alla nummer till den typ man vill ha. Ex: var age=parseInt(request.form.age) för att vara på den säkra sidan.

Den är inte heller till för att upptäcka buggar, det har du andra verktyg till. Den är till för att få en bättre och mer överskådlig kodstruktur för alla som tittar på koden och minska risken för att man skapar buggar från första början.

Kan du rekommendera några verktyg som hittar buggar i JavaScript?