Wie kann ich meinen Meteor Server vor einer Endlosschleife auf dem Client schützen?
Ich bin in eine Situation geraten, in der eine Endlosschleife auf dem Client den Meteor-Server zum Absturz bringt. Die Endlosschleife ist ein Fehler, den ich beheben werde, und nicht der Gegenstand dieser Frage. Meine Sorge ist, dass ein böswilliger Benutzer seine eigene Endlosschleife erstellen und den Meteor-Server zum Absturz bringen könnte.
Die betreffende Endlosschleife ruft wiederholt Meteor.subscribe(...) und Meteor.call(...) auf. Es sieht so aus, als würden diese Anfragen auf dem Server bis zur Entmündigung in die Warteschlange gestellt, obwohl die Absicht des Clients war, sie zu verlassen. Gibt es eine Möglichkeit, dem Server mitzuteilen, dass die Anforderung abgebrochen wurde, und sie aus der Warteschlange zu entfernen?
Ich nehme an, dass dies den Server nicht vor einem Client schützen würde, der tausende aufeinanderfolgender Anfragen abgibt, ohne sie aufzugeben, so dass die Frage diese ersetzen würde, wenn jemand eine Antwort darauf hätte. Wie kann ich die Anzahl der Anfragen begrenzen, die von einem einzelnen Client gestellt werden können?
In diesen APM-Diagrammen können Sie sehen, wie sich die Endlosschleife auf die Leistung auswirkt. Ich startete um 13:17 Uhr und um 13:25 Uhr stürzte die App ab (beendet von Heroku wegen Überschreitung des Speicherkontingents).
1 Antwort
Wenn Meteor.subscribe aufgerufen wird, wird die Meteor.publish-Funktion auf dem Server ausgeführt. Sie können also in der Publish-Funktion entscheiden, die Daten nicht zu liefern.
Dies hängt davon ab, ob Sie von Benutzern angemeldet sind oder die Daten nicht bereitstellen. Wenn Sie erwarten, dass die Benutzer angemeldet sind, können Sie eine Sammlung erstellen, die jeden Aufruf der Veröffentlichungsfunktion (dh jede Client-Abonnementanforderung) mit der verwendeten Benutzer-ID registriert. Sie würden diese Sammlung immer dann anfordern, wenn ein angemeldeter Benutzer versucht, sich anzumelden und zu überprüfen, ob dieser Benutzer in letzter Zeit mehrere Anfragen gestellt hat. Wenn dieser Client Ihr definiertes Anforderungskontingent erreicht, können Sie einfach null zurückgeben.
Sie können dasselbe mit nicht angemeldeten Benutzern tun, indem Sie das Paket Ссылка verwenden und die IP-Adresse registrieren.
Dasselbe können Sie innerhalb der Servermethoden tun, die wiederholt vom Client meteor.call () aufgerufen werden.
Ich denke, dass das Einchecken dieser Datenbank (die klein bleiben würde, da nur die letzte Verbindung in der Datenbank gehalten werden muss) und das Entscheiden, die Daten zu liefern oder nicht, weniger zeitaufwändig wäre, als die Daten jedes Mal zu bedienen.
Ich hoffe, das hilft.
Tags und Links infinite-loop meteor denial-of-service ddp