ArgumentError (comparação de Time com String falhou) no controlador de stylesheet

Bug
1

Tenho uma configuração de subpasta/proxy reverso bastante típica com o Apache como proxy reverso.

Primeiro, houve problemas com ativos inseguros, então forcei https no ENV. Agora, ao recuperar ativos como stylesheets/color_definitions_light_7_1_6cfae4de9c47a1b8ed3d5748018236d10ea9107e.css?__ws=site.com

Talvez eu esteja fazendo algo estúpido, mas estou recebendo isso:

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 curtida
2

Bem, olhando para

Parece que stylesheet_time é uma string, então mudar essa linha para

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

resolve o problema. Não entendo como isso está acontecendo agora, pois não vejo nenhum commit recente afetando isso.

Então, é assim que está configurado:

    stylesheet_time = query.pick(:created_at)

Pareceria que :created_at seria uma data adequada. Algum gem subjacente pode ter mudado? E como isso não teria sido pego nos testes?

1 curtida
3

Aqui está o que parece corrigir:

    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

Parece que é possível to_date transformar algo que é truthy em uma data nula, eu acho.

Não. Isso também não funciona. Acabei envolvendo a seção em um begin/rescue/end.

Estou muito confuso sobre como isso poderia estar afetando apenas esta subpasta/site com proxy reverso.

Talvez tenha a ver com

      cache_time = request.env["HTTP_IF_MODIFIED_SINCE"]

e talvez isso não esteja sendo passado pelo Apache ou algo assim - ou alguma string de data inválida esteja chegando.

Costumava haver um rescue nil nisso, mas isso foi há 5 anos.

E acho que é difícil depurar, pois é um cache, então para depurar eu precisaria limpar esse cache para testar se está funcionando.

1 curtida
4

Tive o mesmo problema (também ao usar a configuração de subpasta). Depois de corrigir um aviso de conteúdo misto não relacionado, definindo a configuração force_https como true, o problema desapareceu …

2 curtidas
5

Droga. Eu esperava que isso fosse me salvar, mas eu já tenho DISCOURSE_FORCE_HTTPS: true no yml.

Agora estou ainda mais confuso sobre como é apenas este um site com o problema.

6

Eu alterei a configuração "forçar https" na interface do administrador, mas provavelmente é a mesma coisa

1 curtida
7

Olá!

Tive exatamente o mesmo problema com o NGINX em vez do Apache como proxy reverso.
Você encontrou uma solução?

A propósito, falhou apenas com a versão Desktop, nenhum problema com a versão mobile.
Eu contornei desabilitando o buffering no proxy reverso.

1 curtida
8

@pfaffman Eu simplesmente fiz o downgrade de um 3.1.0.beta3 para 3.1.0.beta2, tudo correu bem e agora funciona perfeitamente como deveria.

Não tenho experiência suficiente com o Discourse para verificar o que deu errado ou registrar um bug, especialmente em uma instalação não suportada.

Mas se eu puder ajudar de alguma forma, ficarei feliz!