Etherpad-lite: Экспорт площадок с именем * приводит к тому, что экземпляр etherpad не отвечает

https://github.com/ether/etherpad-lite/tree/fix/export-wildcards в качестве временного решения. Раньше до https://github.com/ether/etherpad-lite/commit/a0fb65205c7d7ff95f00eb9fd88e93b300f30c3d можно было указать префикс и получить экспорт контактных площадок, соответствующих этому префиксу.

Чтобы лучше разобраться в этой ошибке, кому-то нужно разобраться в части построения запросов в ueberdb.

При использовании серверной части sql наличие панели с именем ex. ___ экспортирует все панели с трехбуквенным именем.

Видеть:
https://dev.mysql.com/doc/refman/5.7/en/pattern-matching.html
https://github.com/Pita/ueberDB/blob/5c2ef4dc1476ef24bc475885817816c3e602ec8b/mysql_db.js

Что ueberdb будет делать, чтобы найти ключ (* и% отфильтрованы в пропатченном etherpad, но _ также является специальным символом):
ВЫБЕРИТЕ key ОТ store ГДЕ key LIKE?

Спасибо! Поскольку ueberdb поддерживает множество различных бэкэндов баз данных, нам, вероятно, нужно их проверить?

Также было бы неплохо, если бы мы поддерживали символы в именах площадок и не просто фильтровали их, а вместо этого избегали их до того, как они попадут в базу данных. Я займусь этим завтра.

По крайней мере, у sqlite и postgresql будет такая же проблема.

Не уверен насчет других бэкэндов базы данных.

извините, это занимает так много времени ...
mysql, postgresql, sqlite и crate используют% и _
cassandra, couch, rethink, mongo, dirty, redis, вероятно, поддерживает регулярное выражение в стиле PCRE

leveldb и lmdb не реализуют findKeys

Вверх? Это серьезная проблема с конфиденциальностью.

FWIW, мы отключили конечную точку экспорта etherpad по этой конкретной причине. Читая код, я понял, что конечная точка экспорта etherpad не использует padmanager, как это делает, например, конечная точка txt, а скорее вызывает функции db напрямую. С этого момента я допускаю, что не знаю ничего о внутреннем устройстве ethepad, но, поскольку конечная точка экспорта txt не имеет этой проблемы, возможно, стоит изменить конечную точку etherpad, чтобы также использовать padmanager вместо борьбы с этим на уровне БД?

Привет,
Каков статус этой ошибки?

Я думаю, что эту проблему также следует создать в https://github.com/Pita/ueberDB. Библиотека реализует и экспортирует методы для экранирования операторов в зависимости от базы данных, с которой мы работаем (например, операторы регулярных выражений должны экранироваться при работе с dirtydb).

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

Эта проблема касается не столько сбоя узла (что происходит, когда ваш запрос соответствует слишком большому количеству записей), сколько возможности экспортировать все содержимое сервера etherpad, не зная имен контактных площадок.

Поэтому, на мой взгляд, имеет смысл отфильтровать все специальные символы sql LIKE, пока это не будет исправлено в ueberDB.

Должно быть исправлено в https://github.com/ether/etherpad-lite/commit/806c9207e365304ef0f3130d7d3ec59f362f8f9d , поскольку он больше не вызывает findKeys . Можешь подтвердить?

привет, та же проблема, но немного другая

как только я открываю панель, узел становится очень жадным до 100% загрузки ЦП, пожалуйста, сделайте ????