Etherpad-lite: Mengekspor pad bernama * menghasilkan instance etherpad yang tidak merespons

https://github.com/ether/etherpad-lite/tree/fix/export-wildcards sebagai solusinya. Sebelumnya, sebelum https://github.com/ether/etherpad-lite/commit/a0fb65205c7d7ff95f00eb9fd88e93b300f30c3d dimungkinkan untuk menentukan awalan dan mendapatkan ekspor pad yang cocok dengan awalan itu.

Untuk lebih memahami bug ini, seseorang perlu memahami bagian query-builder di ueberdb.

Saat menggunakan backend sql, memiliki pad yang dinamai ex. ___ akan mengekspor semua pad dengan nama 3 huruf.

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

Apa yang akan dilakukan ueberdb untuk menemukan kunci (* dan% disaring di etherpad yang ditambal, tetapi _ juga merupakan karakter khusus):
PILIH key DARI store DI MANA key SUKA?

Terima kasih! Karena ueberdb mendukung banyak backend database yang berbeda, kami mungkin perlu memeriksanya juga?

Juga akan lebih baik jika kita mendukung karakter dalam nama pad dan tidak hanya memfilternya, tetapi menghindarinya sebelum masuk ke database. Saya akan memeriksanya besok.

Setidaknya sqlite dan postgresql akan memiliki masalah yang sama.

Tidak yakin dengan backend database lainnya.

maaf butuh waktu lama ...
mysql, postgresql, sqlite dan peti gunakan% dan _
cassandra, couch, rethink, mongo, dirty, redis mungkin mendukung regex ala PCRE

leveldb dan lmdb tidak mengimplementasikan findKeys

Naik? Ini adalah masalah kerahasiaan yang serius.

FWIW, kami telah menonaktifkan titik akhir ekspor etherpad karena alasan khusus ini. Ketika saya membaca kode, saya menyadari bahwa titik akhir ekspor etherpad tidak menggunakan padmanager seperti yang dilakukan oleh titik akhir misalnya txt, melainkan memanggil fungsi db secara langsung. Saya akan mengakui 0 pengetahuan tentang internal ethepad mulai saat ini, tetapi karena titik akhir ekspor txt tidak memiliki masalah ini, mungkin ada baiknya untuk mengubah titik akhir etherpad untuk menggunakan padmanager juga daripada melawan ini di tingkat DB?

Hai,
Apa status bug ini?

Saya pikir masalah ini juga harus dibuat di https://github.com/Pita/ueberDB. Pustaka mengimplementasikan dan mengekspor metode untuk keluar dari operator bergantung pada database yang kita gunakan (misalnya, operator regex harus di-escape saat bekerja dengan dirtydb).

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

Masalah ini bukan tentang node yang crash (yang terjadi ketika kueri Anda kebetulan cocok dengan terlalu banyak entri), tetapi tentang kemampuan untuk mengekspor konten lengkap dari server etherpad tanpa mengetahui nama pad.

Jadi menurut saya masuk akal untuk menyaring semua sql seperti karakter khusus sampai ini diperbaiki di ueberDB.

Harus diperbaiki di https://github.com/ether/etherpad-lite/commit/806c9207e365304ef0f3130d7d3ec59f362f8f9d , karena tidak lagi memanggil findKeys . Bisakah kamu mengkonfirmasi?

halo, masalah yang sama tapi sedikit berbeda

segera setelah saya membuka pad, node menjadi sangat serakah 100% penggunaan CPU, lakukan ????