Sto ricevendo molti bot/crawler indesiderati che colpiscono il mio sito Discourse con uno user agent vuoto. Normalmente modificherei la configurazione di nginx per fare questo, ma non è accessibile quando si utilizza il metodo di installazione Docker. Non voglio davvero aggiungere un RP extra solo per questo se posso evitarlo.
Puoi consultare discourse_docker/templates/web.ratelimited.template.yml at main · discourse/discourse_docker · GitHub come esempio di come modificare la configurazione di nginx all’interno del container.
Per chiunque altro voglia fare questo specificamente, ho creato /var/discourse/templates/web.blockemptyua.yml con il seguente contenuto:
run:
- replace:
filename: "/etc/nginx/conf.d/discourse.conf"
from: /listen 443 ssl http2;/
to: |
listen 443 ssl http2;
if ($http_user_agent = "") { return 403; }
Quindi in /var/discourse/containers/app.yml ho aggiunto questo nuovo file di template alla fine dell’elenco dei template in cima al file, seguito da ./launcher rebuild app
Nginx ora rifiuta tutte le richieste con un UA vuoto.
Modifica: Modificato il match/replace per essere in un posto migliore.
Non conosco Docker, quindi per sicurezza, perché ogni volta che vedrò replace ovunque sarò nervoso…
Questo non sostituisce completamente il contenuto di discourse.conf ma vi aggiunge qualcosa, vero?
Sta sostituendo una riga all’interno del file. Quindi trova la prima istanza di:
listen 443 ssl http2;
E la sostituisce con
listen 443 ssl http2;
if ($http_user_agent = "") { return 403; }
In modo da aggiungere semplicemente una nuova riga al file nel posto giusto. Nessun’altra parte del file viene toccata. Utilizza lo stesso meccanismo dei template ufficiali per applicare patch al file in modo sicuro.
Come ho detto prima, non conosco Docker. Sono solo un povero utente finale con un dottorato in copia e incolla.
Ecco perché un avviso per i futuri ricercatori:
web.blockemptyua.yml non può essere il primo dei template dichiarati. Più precisamente, deve venire dopo web.template.yml (o forse anche dopo ogni template web.*).
L’ordine ha un significato qui, credo, e se io/noi stiamo cercando di lavorarci come primo, la ricostruzione/il bootstrapping si interrompe con un errore perché in quel momento non esiste alcun /etc/nginx/conf.d/discourse.conf.
Beh, ogni giorno qualcosa di nuovo ![]()
In effetti, deve andare alla fine. Ho modificato il mio post per includerlo ![]()
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.