DiscourseConnect genera redirect HTTP anche con force_https attivo

Installazione
1

Sto eseguendo Discourse dietro Traefik in una configurazione personalizzata: dare a Discourse una VM dedicata non è un’opzione qui.

Il mio Discourse non ha abilitato i template SSL/Let’s Encrypt, poiché Traefik non consente richieste HTTP semplici al container: è impostato per reindirizzare le richieste HTTP a HTTPs.

Sto riscontrando problemi nella configurazione di DiscourseConnect, perché, dato che la richiesta Traefik -> nginx[Discourse] viene inviata tramite HTTP in chiaro (poiché nginx non ha SSL configurato), la regola in /etc/nginx/conf.d/discourse.conf che tenta di preservare il proto, deve essere nel contesto http fa sì che Discourse (l’app Rails) riceva una richiesta HTTP in chiaro, restituendo così un reindirizzamento HTTP in chiaro a /session/sso - anche se ho abilitato force_https.

Penso che questo sia il bug: indipendentemente dalla mia configurazione, con force_https abilitato, Discourse dovrebbe sempre generare URL HTTPs, cosa che non sta facendo.

Penso che il codice incriminato sia application_controller#redirect_to_login, ma non ho scavato abbastanza nel codice sorgente di Discourse per esserne sicuro.

È risolvibile nel codice stesso?

Come soluzione alternativa, sto cercando di aggiungere una regola che modifichi il discourse.conf di nginx per rimuovere quella regola.

2

Dovremmo avere un certo supporto per gli header inoltrati che useresti per segnalare a NGINX qual è l’origine.

3

Hai impostato

proxy_set_header X-Forwarded-Proto https;

4

La cosa più semplice per me è stata impostare un’etichetta aggiuntiva in app.yml di Discourse per dire al mio Traefik di aggiungere un’intestazione X-Forwarded-Proto: https, ma poi nginx sovrascriveva quel parametro con la propria versione.

E la configurazione nginx di Discourse gioca un ruolo qui:

Qui Discourse cerca di indovinare il protocollo dalla richiesta originale (che, nella mia configurazione, è sempre plain-text poiché è ciò che Traefik invia). E poi lo usa per impostare X-Forwarded-Proto più volte.

Alla fine, ho modificato il mio containers/app.yml per codificare queste intestazioni in https:

run:
  - exec: echo "Beginning of custom commands"
  ## If you want to set the 'From' email address for your first registration, uncomment and change:
  ## After getting the first signup email, re-comment the line. It only needs to run once.
  # - exec: rails r "SiteSetting.notification_email='no-reply@forum.cabana.network'"
  - replace:
     filename: "/etc/nginx/conf.d/discourse.conf"
     from: /# attempt to preserve the proto, must be in http context\nmap \$http_x_forwarded_proto \$thescheme {\n  default \$scheme;\n  "~https$" https;\n}/\n
     to: |
       # force https scheme so Discourse generates HTTPs links and redirects (ie, `/login`)
  - replace:
     filename: "/etc/nginx/conf.d/discourse.conf"
     from: "$thescheme"
     global: "true"
     to: "https"
  - exec: echo "End of custom commands"

Ancora una volta, penso che se ci fosse un’impostazione force_https, Discourse-the-rails-app dovrebbe rispettarla, indipendentemente da ciò che il reverse proxy o altre parti gestiscono o meno.

5

Questo è come lo facciamo sulla nostra piattaforma di hosting; abbiamo uno strato di bilanciamento del carico che imposta X-Forwarded-Proto per il downstream nginx+Discourse da consumare.

Non abbiamo bisogno di trucchi aggiuntivi per farlo funzionare: non sono sicuro di cosa stia andando storto per te qui.

Questo è infatti ciò che accade:

  def self.generate_sso(return_path = "/", secure_session:)
    sso = new(secure_session: secure_session)
    sso.nonce = SecureRandom.hex
    sso.register_nonce(return_path)
    sso.return_sso_url = Discourse.base_url + "/session/sso_login"
    sso
  end

e base_url proviene da:

  def self.base_protocol
    SiteSetting.force_https? ? "https" : "http"
  end

  def self.base_url_no_prefix
    "#{base_protocol}://#{current_hostname_with_port}"
  end

  def self.base_url
    base_url_no_prefix + base_path
  end
1 Mi Piace