ArgumentError (fallimento del confronto tra Time e String) nel controller dello stylesheet

Bug
1

Ho una configurazione di sottocartella/reverse proxy abbastanza tipica con Apache come reverse proxy.

Prima c’erano problemi con asset non sicuri, quindi ho forzato force_https in ENV. Ora, quando recupero asset come stylesheets/color_definitions_light_7_1_6cfae4de9c47a1b8ed3d5748018236d10ea9107e.css?__ws=site.com

Forse sto facendo qualcosa di stupido, ma ottengo questo:

ArgumentError (comparison of Time with String failed)
app/controllers/stylesheets_controller.rb:66:in `<='
app/controllers/stylesheets_controller.rb:66:in `show_resource'
app/controllers/stylesheets_controller.rb:19:in `show'
app/controllers/application_controller.rb:414:in `block in with_resolved_locale'
app/controllers/application_controller.rb:414:in `with_resolved_locale'
lib/middleware/omniauth_bypass_middleware.rb:74:in `call'
lib/middleware/content_security_policy/middleware.rb:12:in `call'
lib/middleware/anonymous_cache.rb:369:in `call'
config/initializers/100-quiet_logger.rb:20:in `call'
config/initializers/100-silence_logger.rb:29:in `call'
lib/middleware/enforce_hostname.rb:24:in `call'
lib/middleware/request_tracker.rb:228:in `call'
1 Mi Piace
2

Bene, guardando a

Sembra che stylesheet_time sia una stringa, quindi cambiare quella riga in

    if cache_time && stylesheet_time && stylesheet_time.to_date <= cache_time

risolve il problema. Non capisco come stia succedendo ora, dato che non vedo commit recenti che influenzino questo.

Quindi ecco come è impostato:

    stylesheet_time = query.pick(:created_at)

Sembrerebbe che :created_at dovrebbe essere una data corretta. Qualche gemma sottostante potrebbe essere cambiata? E come non sarebbe stato rilevato nei test?

1 Mi Piace
3

Ecco cosa sembra risolverlo:

    if !cache_time.to_date.nil? && !stylesheet_time.to_date.nil? 
      if (stylesheet_time.to_date <= cache_time.to_date)
        return render body: nil, status: 304
      end 
    end

Sembra che sia possibile che to_date trasformi qualcosa che è truthy in una data nil, immagino.

No. Nemmeno questo funziona. Alla fine ho racchiuso la sezione in un begin/rescue/end.

Sono molto confuso su come questo possa interessare solo questa sottocartella/sito con reverse proxy.

Forse ha a che fare con

      cache_time = request.env["HTTP_IF_MODIFIED_SINCE"]

e forse questo non viene passato da Apache o qualcos’altro - o arriva una stringa di data non valida.

C’era un rescue nil su quello, ma sono passati 5 anni.

E penso che sia difficile da debuggare poiché è una cache, quindi per debuggare dovrei svuotare quella cache per testare se funziona.

1 Mi Piace
4

Ho avuto lo stesso problema (anche durante l’utilizzo della configurazione della sottocartella). Dopo aver risolto un avviso di contenuto misto non correlato impostando l’impostazione force_https su true, il problema è scomparso…

2 Mi Piace
5

Accidenti. Speravo che questo mi salvasse, ma ho già DISCOURSE_FORCE_HTTPS: true nello yml.

Ora sono ancora più confuso su come sia solo questo sito ad avere il problema.

6

Ho modificato l’impostazione “forza https” nell’interfaccia di amministrazione, ma probabilmente è la stessa cosa

1 Mi Piace
7

Ciao!

Ho riscontrato esattamente lo stesso problema con NGINX al posto di Apache come proxy inverso.
Hai trovato una soluzione?

Tra l’altro, ha fallito solo con la versione Desktop, nessun problema con la versione mobile.
Lo aggirò disabilitando il buffering sul proxy inverso.

1 Mi Piace
8

@pfaffman Ho semplicemente eseguito il downgrade da una 3.1.0.beta3 a una 3.1.0.beta2, tutto è andato liscio e ora funziona perfettamente come dovrebbe.

Non ho abbastanza esperienza con Discourse per verificare cosa è andato storto o per segnalare un bug, specialmente su un’installazione non supportata.

Ma se posso essere d’aiuto, sarò felice di farlo!