Etherpad-lite: L'exportation de pads nommés * aboutit à une instance etherpad non-répondante

https://github.com/ether/etherpad-lite/tree/fix/export-wildcards comme solution de contournement. Dans le passé avant https://github.com/ether/etherpad-lite/commit/a0fb65205c7d7ff95f00eb9fd88e93b300f30c3d, il était possible de spécifier un préfixe et d'obtenir une exportation des pads correspondant à ce préfixe.

Pour mieux comprendre ce bogue, quelqu'un doit comprendre la partie du générateur de requêtes dans ueberdb.

Lors de l'utilisation d'un backend SQL, avoir un pad nommé par ex. ___ exportera tous les pads avec un nom de 3 lettres.

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

Que fera ueberdb pour trouver la clé (* et% sont filtrés dans le patché etherpad, mais _ est aussi un caractère spécial):
SELECT key FROM store O key COMME?

Je vous remercie! Parce que ueberdb prend en charge de nombreux backends de bases de données différents, nous devons probablement les vérifier également?

Ce serait également bien si nous prenions en charge les caractères dans les noms de pad et que nous ne les filtrions pas simplement, mais que nous les échappions avant qu'ils n'atteignent la base de données. J'examinerai cela demain.

Au moins sqlite et postgresql auront le même problème.

Pas sûr des autres backends de base de données.

désolé, cela prend si longtemps ...
mysql, postgresql, sqlite et crate utilisent% et _
cassandra, canapé, repenser, mongo, sale, redis probablement supporte l'expression régulière de style PCRE

leveldb et lmdb n'implémentent pas findKeys

Up? C'est un grave problème de confidentialité.

FWIW, nous avons désactivé le point de terminaison d'exportation etherpad pour cette raison spécifique. En lisant le code, j'ai réalisé que le point de terminaison d'exportation etherpad n'utilise pas le padmanager comme le fait par exemple le point de terminaison txt, mais appelle plutôt les fonctions db directement. J'admettrai 0 connaissance des composants internes d'ethepad à partir de maintenant, mais comme le point de terminaison d'exportation txt n'a pas ce problème, peut-être vaut-il la peine de modifier le point de terminaison etherpad pour utiliser également le padmanager au lieu de lutter contre cela au niveau de la base de données?

salut,
Quel est le statut de ce bug?

Je pense que ce problème devrait également être créé dans https://github.com/Pita/ueberDB. La bibliothèque implémente et exporte des méthodes pour échapper aux opérateurs en fonction de la base de données avec laquelle nous travaillons (par exemple, les opérateurs regex doivent être échappés lorsque vous travaillez avec dirtydb).

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

Ce problème ne concerne pas tant le crash du nœud (ce qui se produit lorsque votre requête correspond à trop d'entrées), mais la possibilité d'exporter le contenu complet du serveur etherpad sans connaître les noms des pads.

Donc, à mon avis, il est logique de filtrer tous les caractères spéciaux SQL LIKE jusqu'à ce que cela soit corrigé dans ueberDB.

Doit être corrigé dans https://github.com/ether/etherpad-lite/commit/806c9207e365304ef0f3130d7d3ec59f362f8f9d , car il n'appelle plus findKeys . Pouvez-vous confirmer?

bonjour, même problème mais un peut différant

des que je ouvre un pad, le node devient tros gourmand 100% utilisation du CPU, koi faire ????