Hello,
I tried using Force https and it seemed to work for me except it was causing login problems. However, the logos are loaded using http by default. They should use the // protocol and let the browser decide which one to use, right? Or maybe there is another solution I’m missing?
Thanks
Hi Eddie,
What version of Discourse are you running? In recent versions logos are uploaded via site settings, instead of being linked using a URL, so this should no longer be an issue.
Hi Joshua, We recently upgraded to v2.2.5. During the previous upgrade, before force https, I believe I deleted the post where the logos were uploaded and switched to the site settings. Everything was fine. Then with v2.2.5, I can’t get rid of the http:// part without force https. I tried reuploading, the wizard, even modifying the images so their hash was different. No luck
Sorry, now I’m confused. Is force_https enabled or not? Is there any possibility you’re overriding the uploaded logos via themes? If your force_https is enabled, and your logos are served via site settings, there should not be a mixed content warning. Are you able to share a link to your site so I can take a look?
It was enabled, thought the upgrade was over. Then our QA reports that logins are not working. so we disabled force https for now. You can test here //forum.y8.com
I checked the themes and didn’t spot anything that might cause this https problem. We mostly use stock, though it is an old stock theme.
With force_https disabled, I can’t test this. We rely on that setting to ensure assets are served over https, not http. Regarding the login issue, it appears you’re using SSO, so ensure the SSO redirect from your provider links to your site via https://, not http://. Once you’ve re-enabled force_https I can take another look.
This forum is using the oauth2 basic plugin. Maybe there is a problem with that, might require a version roll back. Not sure yet. I did check the settings, all addresses were using https, so no obvious problem there.
Ho un problema simile qui:
Dopo aver scoperto che il logo e la grande icona vengono caricati tramite HTTP, causando contenuti misti, l’attivazione di force_https ha risolto il problema. Tuttavia, il login non era più possibile, portando a un ciclo di reindirizzamento. Dopo aver disattivato questa opzione, il login funziona di nuovo.
Perché sta succedendo questo?
E perché solo queste due immagini vengono caricate tramite HTTP, mentre tutte le altre risorse vengono caricate correttamente tramite HTTPS?
Qual è il tuo metodo di accesso? Immagino che non sia un accesso locale (nome utente/password), vero?
C’è qualche proxy o altro servizio davanti alla tua installazione?
Sto utilizzando SSO tramite un’altra applicazione web.
nginx viene utilizzato come reverse proxy.
Come è stato configurato nginx?
Nginx sta reindirizzando tutte le richieste HTTP verso HTTPS, quindi non dovrebbe essere possibile caricare contenuti tramite HTTP in ogni caso.
La mia prima idea sarebbe di ricontrollare la configurazione SSO per vedere dove reindirizza gli utenti e quali origini accetta. Assicurati che tutto nella configurazione SSO utilizzi https://. È anche possibile che si tratti di un problema legato a Nginx. Sarà difficile eseguire il debug qui con molte variabili…
Ho esattamente lo stesso problema segnalato da altre persone qui e in questo thread.
Il problema non è legato all’implementazione SSO né al server web: nel mio caso, le richieste HTTP vengono reindirizzate a HTTPS, che vengono poi inoltrate tramite il reverse proxy. L’SSO funziona perfettamente se reindirizzo l’utente a https://discourse.fqdn.top/session/sso_login?sso=PAYLOAD&sig=SIGNATURE e force_https è impostato su false. Questo dimostra che sia la parte SSO che il proxy funzionano correttamente. Il problema si presenta solo quando attivo force_https impostandolo su true. Se ho già una sessione attiva, posso cambiare force_https su true e usare Discourse senza problemi (ulteriore conferma che il problema non è legato al reverse proxy). Lasciare force_https su false non è un’opzione perché rompe i loghi e Chrome non è soddisfatto quando vengono mescolati asset HTTP e HTTPS (mostra un piccolo avviso nella barra degli indirizzi che la pagina non è sicura).
Com’è la tua configurazione nginx e hai un header X-Forwarded-Proto al suo interno?
Grazie mille. Sì, ha risolto il problema. Quindi era effettivamente legato al proxy. Mi scuso per aver assunto il contrario, solo perché il contenuto veniva caricato.
Per completezza, sto utilizzando Apache come reverse proxy e non nginx. Ecco le righe di configurazione pertinenti:
RequestHeader set X-Forwarded-Proto "https"
ProxyPass / http://[::1]:2045/ retry=10
ProxyPassReverse / http://[::1]:2045/
L’aggiunta della prima riga ha risolto il problema.
Ciao,
scusa se torno sull’argomento, ma non riesco a eliminare gli avvisi di contenuto misto su Firefox. La cosa curiosa è che ho una configurazione abbastanza simile… più o meno. Forse qualcuno può dare qualche idea o suggerimento di miglioramento. Non sono un grande esperto di direttive Apache, ma il ragionamento mi sembra sensato, almeno in parte.
Abbiamo Discourse in Docker su Apache tramite Reverse Proxy e gestiamo i certificati Let’s Encrypt con ISPConfig, dato che sul nostro server girano molti domini “normali”.
Abbiamo configurato il Reverse Proxy con direttive Apache gestite da ISPConfig. La nostra configurazione è questa:
ProxyPreserveHost On
ProxyPass /.well-known/acme-challenge !
RequestHeader set X-Forwarded-Proto "https"
ProxyPass / unix:///var/discourse/shared/standalone/nginx.http.sock|http://localhost/
ProxyPassReverse / unix:///var/discourse/shared/standalone/nginx.http.sock|http://localhost/
RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteRule (.*) https://sub.domain.de$1 [R,L]
Tuttavia, Firefox continua a mostrare avvisi di contenuto misto. Ho provato a impostare l’opzione “force SSL” nelle impostazioni. Come primo effetto, non siamo più riusciti ad accedere. Autentichiamo solo tramite utente e password. Allora ho provato la soluzione menzionata:
Ora, con “force SSL” attivo, l’accesso è possibile. Ma Firefox continua a mostrare avvisi di contenuto misto. La console indica:
e
vengono serviti via HTTP… Abbiamo anche provato a ricaricare le immagini di branding tramite sub.domain.de/wizard, ma il problema persiste… C’è un modo per… non so, forzare il re-rendering delle immagini ottimizzate usando HTTPS? C’è qualcosa di sbagliato nella nostra configurazione del Reverse Proxy?
Sarei davvero grato per ulteriori assistenza. È come un oceano di possibili configurazioni di Reverse Proxy con forzatura SSL tramite Let’s Encrypt (gestito da) Apache (e non dalla configurazione integrata di Discourse), quindi mi sembra di affogare. E ho la sensazione che ci siano poche persone che usano Apache come host con Reverse Proxy e la configurazione Let’s Encrypt che stiamo utilizzando. Oppure siamo noi a configurarlo male.
Come dicevo, apprezzerei qualsiasi suggerimento. Grazie in anticipo!
Prova SiteIconManager.ensure_optimized! da una console di Rails.
Wow, che risposta veloce! Grazie mille.
Nel frattempo… non so se sia stato innescato dal fatto di aver lasciato passare del tempo, così che qualcosa accadesse. Ma dopo aver inviato il mio primo post, ho ricaricato quelle due immagini (favicon e icona per Apple) non usando la procedura guidata, bensì le impostazioni di amministrazione (branding), e proprio in quel momento, mentre volevo chiudere la scheda per ricontrollare se il login e tutto il resto funzionassero correttamente… indovinate un po’? Gli errori di contenuto misto di Firefox sono spariti!
Wow!
Comunque @RGJ, grazie ancora, penso che questo abbia risolto anche il ridisegno delle immagini ottimizzate. Pensi che sia stato attivato nel frattempo a causa di una soglia temporale o perché ho ricaricato le immagini di nuovo tramite il pannello di amministrazione e non la procedura guidata?
Grazie ancora, specialmente a @alphanoob1337 per essere finalmente riuscito a farlo funzionare!
Wow, è piuttosto scomodo per un lunedì, ma lascio l’ufficio con una piacevole sensazione di felicità 
