Etherpad-lite: *という名前のパッドをエクスポートすると、応答しないetherpadインスタンスが生成されます

回避策としてhttps://github.com/ether/etherpad-lite/tree/fix/export-wildcards 。 以前はhttps://github.com/ether/etherpad-lite/commit/a0fb65205c7d7ff95f00eb9fd88e93b300f30c3dの前に、プレフィックスを指定して、そのプレフィックスに一致するパッドのエクスポートを取得することができました。

このバグをよりよく理解するには、誰かがueberdbのクエリビルダーの部分を理解する必要があります。

SQLバックエンドを使用する場合、exという名前のパッドを使用します。 ___は、3文字の名前を持つすべてのパッドをエクスポートします。

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

キーを見つけるためにueberdbが行うこと（*と％はパッチが適用されたイーサパッドで除外されますが、_も特殊文字です）：
key FROM store WHERE key LIKE？

ありがとうございました！ ueberdbは多くの異なるデータベースバックエンドをサポートしているので、おそらくそれらもチェックする必要がありますか？

また、パッド名の文字をサポートし、それらをフィルタリングするだけでなく、データベースに到達する前にエスケープするとよいでしょう。 これを明日調べます。

少なくともsqliteとpostgresqlには同じ問題があります。

他のデータベースバックエンドについてはよくわかりません。

すみません、時間がかかります...
mysql、postgresql、sqlite、およびcrateは％と_を使用します
cassandra、couch、rethink、mongo、dirty、redisはおそらくPCREスタイルの正規表現をサポートしています

leveldbとlmdbはfindKeysを実装していません

アップ？ これは重大な機密性の問題です。

FWIW、この特定の理由により、etherpadエクスポートエンドポイントを無効にしました。 コードを読んでいると、etherpadエクスポートエンドポイントは、たとえばtxtエンドポイントのようにpadmanagerを使用せず、db関数を直接呼び出すことに気付きました。 この時点からethepadの内部に関する知識は0と認めますが、export txtエンドポイントにはこの問題がないため、DBレベルでこれと戦うのではなく、etherpadエンドポイントを修正してpadmanagerも使用する価値がありますか？

こんにちは、
このバグのステータスはどうですか？

この問題はhttps://github.com/Pita/ueberDBでも作成する必要があると思い

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

この問題は、ノードのクラッシュ（クエリが多すぎるエントリに一致する場合に発生します）ではなく、パッドの名前を知らなくても、etherpadサーバーの完全なコンテンツをエクスポートできることに関するものです。

したがって、私の意見では、これがueberDBで修正されるまで、すべてのsqlLIKE特殊文字を除外することは理にかなっています。

findKeys呼び出さなくなったため、 https：//github.com/ether/etherpad-lite/commit/806c9207e365304ef0f3130d7d3ec59f362f8f9dで修正する必要があります。 確認できますか？

こんにちは、同じ問題ですが少し異なります

パッドを開くとすぐに、ノードは非常に貪欲な100％のCPU使用率になります。実行してください????