Ciao.
Abbiamo un’installazione Discourse v2.4.0.beta2 +346 che era originariamente disponibile su include.metaring.com,
utilizzando Apache HTTP Server su Ubuntu che:
- Reindirizza tutte le richieste HTTP verso HTTPS
- Gestisce autonomamente il certificato SSL (LetsEncrypt)
- Tutte le richieste venivano reindirizzate tramite Proxy verso nginx http sock, quindi le porte Docker di Discourse 80 e 443 sono disabilitate/non utilizzate
Abbiamo eseguito
./launcher enter app
rails c
[1] pry(main)> SiteSetting.force_https = true
=> true
Per essere assolutamente certi che tutto venisse servito in HTTPS (avevamo diversi errori altrimenti)
E tutto funzionava correttamente.
Poi abbiamo deciso di spostare l’applicazione (senza toccare il DB o altro) sotto include.metaring.com/discourse, quindi abbiamo modificato il file app.yml come segue:
DISCOURSE_HOSTNAME: include.metaring.com<— Invariato, uguale a primaDISCOURSE_RELATIVE_URL_ROOT: /discourse
Poi, per essere assolutamente certi, abbiamo eseguito:
./launcher stop app
./launcher destroy app
./launcher cleanup
./launcher rebuild app
Naturalmente abbiamo anche inserito nel file di configurazione di Apache le regole per ProxyPass correttamente da /discourse a unix:/../../nginx.http.sock|http://localhost/*discourse*
Dopo questo, l’applicazione era ovviamente online, ma presentava molti problemi:
-
Tutto il contenuto statico (plugin, asset, immagini, javascript, upload) non era disponibile. Dopo lunghe sessioni di debug e ricerche web infruttuose per farli funzionare, abbiamo creato alcune regole di proxy in Apache per instradarli verso il percorso root localhost, senza il prefisso /discourse (ad esempio /discourse/plugins punta a → unix:/../../nginx.http.sock|http://localhost/plugins e così via)
-
Alcuni percorsi /uploads provenivano dalle pagine web senza il prefisso /discourse, quindi abbiamo dovuto scrivere un’altra regola di proxy Apache che spostasse da /uploads/ a unix:/../../nginx.http.sock|http://localhost/discourse/uploads
-
Ora la cosa più strana: quando il client invia richieste contenenti /uploads/default/ o /discourse/uploads/default/ (contenuto statico) dobbiamo seguire la soluzione descritta al punto 1 e reindirizzarle entrambe a
http://localhost/uploads/default/(senza il prefisso /discourse), mentre altre richieste /uploads/ o /discourse/uploads/ che non contengono il prefisso /default nel percorso devono essere reindirizzate ahttp://localhost/discourse/uploads/(notate che senza il percorso default significa che si tratta di chiamate a servizi web)
Con tutte queste 9 regole di proxy inserite, tutto funziona di nuovo correttamente anche sotto il percorso /discourse. Ma troviamo estremamente strano che abbiamo dovuto scrivere tutto questo per far funzionare di nuovo tutto.
Stiamo facendo qualcosa di sbagliato?
Esiste qualche altro metodo intelligente per gestire questa situazione?
=== EDIT ===
Ho dimenticato un’altra cosa che forse è collegata:
Quando l’utente tenta di caricare un’immagine personalizzata da usare come avatar personale, il caricamento ha successo e la miniatura dell’immagine viene mostrata correttamente.
Ma quando viene premuto il pulsante Salva modifiche e la pagina viene ricaricata, l’avatar torna all’avatar predefinito dell’utente
Controllando il file
produciton.log, si vede che l’errore è Codice 418.Altri caricamenti di immagini funzionano correttamente.
Grazie in anticipo per le risposte e per il vostro straordinario lavoro!