Spero che qualcuno possa offrire qualche consiglio; vi sarei in debito. Spiegherò la situazione.
Ho configurato Discourse più volte sul mio dominio, hostballs[.]com. Ogni volta, visitare www[.]hostballs[.]com reindirizza correttamente a hostballs[.]com, perché il certificato LetsEncrypt copre sia la versione con www che quella senza. Questo è ciò che conosco come comportamento predefinito e standard di Discourse con la sua implementazione di LE.
Attualmente, la mia nuova installazione di Discourse sta configurando SSL per il sito senza www (come configurato nell’URL), ma non copre la versione con www. Ciò significa che chiunque visiti www[.]hostballs[.]com non verrà reindirizzato, ma vedrà invece un errore SSL. Dato che so che il comportamento predefinito è diverso da questo e che l’installazione di Discourse è troppo controllata per permettermi di ricorrere semplicemente a certbot e fare tutto manualmente (non renderebbe forse più divertente l’aggiornamento regolare?), sono incerto sulla strada migliore da percorrere.
Nel tentativo di risolvere il problema, ho commentato i template SSL e LE, nonché l’indirizzo email LE, nel file app.yml. Ho quindi rimosso le directory letsencrypt e ssl da /shared/standalone. Ho ricostruito il sito senza SSL, quindi ho riattivato quelle opzioni in app.yml e ho ricostruito nuovamente per generare nuovi certificati e configurazioni SSL. Sebbene ciò abbia avuto successo, non ha comunque risolto il problema relativo al www.
Qualcun altro ha mai affrontato una situazione simile e ha trovato una soluzione?
Se il consiglio sopra è troppo intimidatorio, puoi anche configurare un semplice reindirizzamento DNS. La maggior parte dei registrar lo offre.
Discourse non può essere pubblicato sotto più URL; il record root (non www) e il record ‘A’ di www sono indirizzi separati. Una volta che hai assegnato un FQDN al tuo sito, eventuali indirizzi aggiuntivi devono essere gestiti con un reindirizzamento.
Se non ti piace nessuna delle due soluzioni proposte, puoi optare per l’uso di www.example.com e utilizzare http://forcewww.com/ per reindirizzare al sito con www.
Grazie, amici. Lasciate che vi esponga alcuni dettagli che potrebbero essere utili a qualcun altro in futuro.
Tutto è iniziato perché un utente mi ha detto che visitare www non funzionava, restituendo un errore relativo al certificato. Quando ho visitato direttamente il loro link https fornito nel thread di segnalazione, ho riscontrato lo stesso problema. In passato, quando usavo www, non avevo mai incontrato questo problema, ma venivo invece reindirizzato al dominio radice senza alcun inconveniente. Questo mi ha portato a concludere che la mia installazione, dopo una recente migrazione, fosse in qualche modo danneggiata e non si comportasse secondo le caratteristiche predefinite di una nuova installazione di Discourse.
Quindi ho installato una copia fresca di Discourse su un nuovo dominio per dimostrare che www funzionasse di default quando si utilizza il dominio radice. Sono andato sul dominio, poi ho modificato l’URL nella barra degli indirizzi e ho aggiunto “www.” all’inizio. È stato reindirizzato al dominio radice senza problemi, come mi aspettavo. Poi ho pensato di provare un’ultima cosa. Ho digitato manualmente “https://” prima di esso. A quel punto si è verificato un errore con lo stesso problema relativo al certificato.
Quindi, ciò che potrebbe avermi portato a credere che la configurazione per www fosse un comportamento predefinito nell’implementazione di LE di Discourse, potrebbe in realtà essere stato il mio browser che si è impostato automaticamente sulla porta 80, nascondendo la parte http/https dell’URL dalla mia vista mentre riscrivevo l’URL nella barra degli indirizzi.
Questa è la mia migliore valutazione della situazione, almeno.
Sì, qualsiasi richiesta che raggiunge l’indirizzo IP del tuo server sulla porta 80 verrà reindirizzata al FQDN effettivo tramite HTTPS; ‘www’ non è un caso speciale.
Soluzione più semplice per chi utilizza il dominio radice e desidera che www sia firmato da LE per un reindirizzamento HTTPS corretto, senza complicazioni eccessive o l’uso di un altro server web per gestire il reindirizzamento:
Sì, non vedo un modo per ottenerlo che non rischi di rompersi con gli aggiornamenti. Questo sembra proprio il destino di chi ha domini dedicati per le community e non gradisce sottodomini non necessari.
A meno che, naturalmente, non si faccia girare un altro server web altrove.
Giusto, vedo già un tentativo che è stato interrotto perché un file è cambiato, rompendo il modo in cui stavano configurando la modifica del file in app.yml:
Che si stia modificando direttamente un file o che app.yml lo modifichi in seguito, un aggiornamento ha il potenziale di cambiare quel file e rompere il metodo di modifica che state utilizzando, indipendentemente dal caso.
Il mio punto è che qualsiasi modifica a quel modello lo romperà di nuovo. Negli ultimi anni, solo un cambiamento ha rotto il metodo PUPS/hooks: l’introduzione del supporto per l’ECC.