Come posso proteggere il mio server Meteor da un loop infinito sul client?

Question

Ho incontrato una situazione in cui un loop infinito sul client sta bloccando il server Meteor. Il ciclo infinito è un bug che risolverò, e non l'argomento di questa domanda. La mia preoccupazione è che un utente malintenzionato possa creare il proprio loop infinito e mandare in crash il server Meteor.

Il loop infinito in questione effettua ripetutamente chiamate a e Meteor.call(...). Sembra che queste richieste siano state accodate sul server fino al punto di inabilitazione, anche se l'intenzione del cliente era di abbandonarle. C'è un modo per dire al server che la richiesta è stata abbandonata e rimuoverla dalla coda?

Suppongo che questo non possa proteggere il server da un client che fa migliaia di richieste successive senza abbandonarle, in modo che la domanda sostituisca questa se qualcuno ha una risposta. Come posso limitare il numero di richieste che possono essere fatte da un singolo cliente?

In questi grafici APM, è possibile vedere come il ciclo infinito ha influito sulle prestazioni. L'ho iniziato verso le 13:17 e alle 13:25 l'app si è bloccata (terminata da Heroku per aver superato la sua quota di memoria).

Answer 1

Quando Meteor.subscribe viene chiamato, la funzione Meteor.publish viene eseguito sul server. In questo modo è possibile decidere nella funzione di pubblicazione di non servire i dati.

Dipende se si prevede che gli utenti debbano accedere o meno ai dati. Se si prevede che gli utenti effettuino l'accesso, è possibile creare una raccolta che registra qualsiasi chiamata alla funzione di pubblicazione (ossia qualsiasi richiesta di sottoscrizione del cliente) con l'ID utente utilizzato. Chiederai a questa raccolta ogni volta che un utente registrato tenta di iscriversi e controlla se questo utente ha fatto più richieste di recente. Se questo cliente ti colpisce, la quota della richiesta è definita, puoi semplicemente restituire null.

È possibile fare lo stesso con utenti che non hanno effettuato il login utilizzando il pacchetto https://github.com/gadicc/meteor-headers e registrando l'indirizzo IP.

Si può fare lo stesso all'interno dei metodi server che vengono ripetutamente chiamati dal client meteor.call().

Penso che il controllo in questo database (che rimarrebbe piccolo come solo la connessione recente deve essere tenuto nel database) e decidere di servire i dati o meno richiederebbe meno tempo a servire i dati ogni volta.

Spero che questo aiuti.