Etherpad-lite: Das Exportieren von Pads mit dem Namen * führt zu einer nicht reagierenden Etherpad-Instanz

https://github.com/ether/etherpad-lite/tree/fix/export-wildcards als Problemumgehung. In der Vergangenheit vor https://github.com/ether/etherpad-lite/commit/a0fb65205c7d7ff95f00eb9fd88e93b300f30c3d war es möglich, ein Präfix anzugeben und einen Export von Pads zu erhalten, die diesem Präfix entsprechen.

Um diesen Fehler besser zu verstehen, muss jemand den Query-Builder-Teil in ueberdb verstehen.

Wenn Sie ein SQL-Backend verwenden, haben Sie ein Pad mit dem Namen ex. ___ exportiert alle Pads mit einem 3-Buchstaben-Namen.

Sehen:
https://dev.mysql.com/doc/refman/5.7/en/pattern-matching.html
https://github.com/Pita/ueberDB/blob/5c2ef4dc1476ef24bc475885817816c3e602ec8b/mysql_db.js

Was ueberdb tut, um den Schlüssel zu finden (* und% werden im gepatchten Etherpad herausgefiltert, aber _ ist auch ein Sonderzeichen):
SELECT key FROM store WHERE key LIKE?

Vielen Dank! Da ueberdb viele verschiedene Datenbank-Backends unterstützt, müssen wir diese wahrscheinlich auch überprüfen?

Es wäre auch schön, wenn wir die Zeichen in Pad-Namen unterstützen und sie nicht nur filtern, sondern ihnen entkommen, bevor sie in die Datenbank gelangen. Ich werde mich morgen darum kümmern.

Zumindest SQLite und Postgresql haben das gleiche Problem.

Ich bin mir nicht sicher über die anderen Datenbank-Backends.

Entschuldigung, es dauert so lange ...
MySQL, Postgresql, SQLite und Kiste verwenden% und _
Cassandra, Couch, Rethink, Mongo, Dirty, Redis unterstützen wahrscheinlich Regex im PCRE-Stil

leveldb und lmdb implementieren findKeys nicht

Oben? Dies ist ein ernstes Vertraulichkeitsproblem.

FWIW, wir haben den Etherpad-Exportendpunkt aus diesem speziellen Grund deaktiviert. Beim Lesen des Codes wurde mir klar, dass der Etherpad-Exportendpunkt den Padmanager nicht wie den zB txt-Endpunkt verwendet, sondern db-Funktionen direkt aufruft. Ich gebe zu, dass ich von diesem Punkt an keine Kenntnisse über die Interna von ethepad habe, aber da der Export-txt-Endpunkt dieses Problem nicht hat, lohnt es sich vielleicht, den Etherpad-Endpunkt so zu ändern, dass er auch den Padmanager verwendet, anstatt dies auf DB-Ebene zu bekämpfen?

Hallo,
Wie ist der Status dieses Fehlers?

Ich denke, dieses Problem sollte auch in https://github.com/Pita/ueberDB erstellt werden. Die Bibliothek implementiert und exportiert Methoden, um Operatoren abhängig von der Datenbank, mit der wir arbeiten, zu maskieren (z. B. sollten Regex-Operatoren bei der Arbeit mit Dirtydb maskiert werden).

https://github.com/Pita/ueberDB/issues/107

Bei diesem Problem geht es nicht so sehr um den Absturz eines Knotens (was passiert, wenn Ihre Abfrage mit zu vielen Einträgen übereinstimmt), sondern darum, den gesamten Inhalt des Etherpad-Servers exportieren zu können, ohne die Namen der Pads zu kennen.

Meiner Meinung nach ist es also sinnvoll, alle SQL-ähnlichen Sonderzeichen herauszufiltern, bis dies in ueberDB behoben ist.

Sollte in https://github.com/ether/etherpad-lite/commit/806c9207e365304ef0f3130d7d3ec59f362f8f9d behoben werden, da es nicht mehr findKeys aufruft. Kannst du bestätigen?

Hallo, das gleiche Problem, aber ein bisschen anders

Sobald ich ein Pad öffne, wird der Knoten sehr gierig 100% CPU-Auslastung, koi do ????