Impostazioni disponibili per i limiti di velocità globali e il throttling

[Discourse]

Discourse è fornito con 3 diversi limiti di frequenza globali che possono essere configurati dagli amministratori del sito.

Limiti di frequenza globali per IP

Questi limiti si applicano a ogni indirizzo IP univoco che accede all’applicazione Discourse. (i file serviti direttamente dal filesystem o dal CDN sono esclusi)

Predefinitamente, questo limite di frequenza è abilitato; è possibile disattivarlo o impostarlo in modalità di reporting.

DISCOURSE_MAX_REQS_PER_IP_MODE: predefinito block, questo limite di frequenza è applicato di default. (le altre opzioni sono warn, warn+block e none)

DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE: numero di richieste per IP al minuto (predefinito 200)

DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS: numero di richieste per IP ogni 10 secondi (predefinito 50)

DISCOURSE_MAX_ASSET_REQS_PER_IP_PER_10_SECONDS: numero di richieste di risorse (avatar/css) per IP ogni 10 secondi (predefinito 200)

DISCOURSE_MAX_REQS_RATE_LIMIT_ON_PRIVATE: il limite di frequenza deve essere applicato agli IP privati che accedono a Discourse? Il valore predefinito è false.

DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL: utilizzare i limiti di frequenza per utente anziché per IP per gli utenti con questo livello di fiducia o superiore (predefinito 1)

DISCOURSE_MAX_REQS_PER_IP_EXCEPTIONS: un elenco separato da spazi di indirizzi IP o blocchi CIDR da esentare dal limite di frequenza per IP. Ad esempio: 14.15.16.32/27 216.148.1.2

Limiti di frequenza per l’API utente

Le applicazioni mobili acquisiscono una chiave API utente per dispositivo per accedere a Discourse in nome di un utente (utilizzando un protocollo aperto). Queste chiavi API sono strettamente limitate.

DISCOURSE_MAX_USER_API_REQS_PER_MINUTE: predefinito 20
DISCOURSE_MAX_USER_API_REQS_PER_DAY: predefinito 2880

Limiti di frequenza per l’API di amministrazione

Le chiavi API di amministrazione possono essere generate tramite la pagina yoursite.com/admin/api/keys. Queste chiavi possono operare in nome degli utenti, ma richiedono privilegi di amministrazione per essere generate. C’è un limite di 60 richieste al minuto, condiviso tra tutte le chiavi.

Gli utenti che ospitano il servizio in autonomia (self-hosted) possono modificarlo nel loro file app.yml. I clienti ospitati dovranno contattare il proprio provider di hosting.

DISCOURSE_MAX_ADMIN_API_REQS_PER_MINUTE: 60

Limiti di frequenza per l’API del plugin Data Explorer

DISCOURSE_MAX_DATA_EXPLORER_API_REQ_MODE: predefinito warn, questo limite di frequenza è applicato di default. (le altre opzioni sono block, warn+block e none)

DISCOURSE_MAX_DATA_EXPLORER_API_REQS_PER_10_SECONDS: 2

Nota: le richieste effettuate tramite l’interfaccia utente di Data Explorer non vengono conteggiate nel limite di frequenza.

Cosa devo fare se supero un limite di frequenza e vengo limitato (throttled)?

Se stai consumando l’API in modo programmatico e ricevi in risposta un codice di stato 429 di throttling, dovresti rispettarlo e rallentare.

Come utente finale, in genere non dovresti incontrare limiti di frequenza; se ciò accade, rallenta. Potresti averli attivati aprendo rapidamente 50 schede o facendo qualcosa di simile.

Avvertenza su firewall e proxy!

Se stai eseguendo un proxy inverso configurato in modo errato, Discourse potrebbe ritenere che tutte le richieste provengano da un singolo indirizzo IP; è molto probabile che raggiungerai i limiti di frequenza in anticipo. Assicurati di configurare il tuo proxy inverso per inoltrare correttamente l’IP.

Come posso modificare questi limiti?

Per modificare i limiti, aggiungi la modifica desiderata nella sezione env del tuo file app.yml.

Se sei ospitato da Discourse e hai un piano Enterprise, contatta team@discourse.org se hai bisogno di regolare uno di questi limiti.

I limiti di frequenza globali non sono regolabili nei piani Free, Starter, Pro o Business.

[pfaffman (Jay Pfaffman)]

Mi sembra che se hai installato web.ratelimited.template.yml, allora questi non hanno importanza poiché le cose vengono limitate per frequenza da NGINX prima che raggiungano Discourse, giusto?

Questo è ciò che sembra dai miei log di nginx.

La mia soluzione a breve termine è aggiungere il mio indirizzo IP all’elenco IP locali, in modo che superi NGINX. Immagino che la cosa da fare sia rimuovere il template ratelimited per dare un senso a questi?

[guidoleenders]

Riguardo al seguente testo:

Avviso firewall e proxy!

Se stai eseguendo un reverse proxy mal configurato, Discourse potrebbe pensare che tutte le richieste provengano da un singolo indirizzo IP, è molto probabile che raggiungerai presto i limiti di frequenza. Assicurati di configurare il tuo reverse proxy per inoltrare correttamente l’IP.

Nella nostra configurazione, inoltriamo tutte le chiamate API tramite un proxy. Questo proxy gestisce l’autenticazione e molte altre cose prima di interrogare a volte Discourse.

Qual è il modo consigliato (header specifico?) per inoltrare l’indirizzo IP del richiedente originale?

Correlati

Rate Limiting w/ Reverse Proxy

Had a question on what header is being used for rate-limiting. For context we have an nginx.conf w/ set_real_ip and we’re using a provider that sends us traffic with the client’s actual IP in Some-Client-IP header. sendfile on; set_real_ip_from ...; set_real_ip_from ...; set_real_ip_from ...; set_real_ip_from ...; real_ip_header Some-Client-IP; real_ip_recursive on; Some-Client-IP is what we get from upstream w/ the actual user’s IP. In the current discourse.conf in conf.d for nginx. We ha…

[Richie (Richie Rich)]

Qualcuno potrebbe aiutarmi a capire questa impostazione di configurazione, per favore?

@Discourse

DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL: usa limiti di frequenza per utente anziché limiti di frequenza per IP per gli utenti con questo livello di fiducia o superiore (predefinito 1)

Sto pensando correttamente che sia già impostato su 1 e che i limiti di frequenza siano già impostati per utente anziché per indirizzo IP (se l’utente è TL1 o superiore)?

[Ethsim2 (Ethan)]

@j.jaffeux

dov’è il 429?

in realtà non esisteva per farmi specificare una o più di queste impostazioni.

my script ha sempre rispettato l’header Retry-After, come possiamo vedere dalla riga originale 101;

retry_after = r.headers.get("Retry-After")

tuttavia questo header stava diventando inutilmente grande poiché pianifico diverse unità di servizio per l’esecuzione di questo stesso script in momenti diversi della giornata.

Pertanto, multipli di alcune di queste impostazioni dall’impostazione predefinita hanno migliorato la recapito delle e-mail tramite mail-receiver, il che rimane importante.