Etherpad-lite: Exporting pads named * result in a non-responding etherpad instance

https://github.com/ether/etherpad-lite/tree/fix/export-wildcards as a workaround. In the past before https://github.com/ether/etherpad-lite/commit/a0fb65205c7d7ff95f00eb9fd88e93b300f30c3d it was possible to specify a prefix and get a export of pads matching that prefix.

To better understand this bug someone needs to understand the query-builder part in ueberdb.

When using a sql backend, having a pad named for ex. ___ will export all pad's with a 3 letter name.

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

What ueberdb will do to find the key (* and % are filtered out in the patched etherpad, but _ is also a special character):
SELECT key FROM store WHERE key LIKE ?

Thank you! Because ueberdb supports many different database backends we probably need to check them as well?

Also it would be nice if we support the characters in pad names and don't just filter them, but instead escape them before they hit the database. I will look into this tomorrow.

At least sqlite and postgresql will have the same problem.

Not sure about the other database backends.

sorry it takes so long...
mysql, postgresql, sqlite and crate use % and _
cassandra, couch, rethink, mongo, dirty, redis probably support PCRE-style regex

leveldb and lmdb don't implement findKeys

Up? This is a serious confidentiality issue.

FWIW, we have disabled the etherpad export endpoint for this specific reason. As I was reading through the code I realized that the etherpad export endpoint does not use the padmanager as the e.g. txt endpoint does, but rather calls db functions directly. I 'll admit 0 knowledge of ethepad's internals from this point on, but since the export txt endpoint does not have this problem, maybe it's worth it to amend the etherpad endpoint to use the padmanager as well instead of fighting this at the DB level ?

hi,
Whats the status of this bug?

I think this issue should also be created in https://github.com/Pita/ueberDB. The library implement and exports methods to escape operators depending of the database we are working with (for instance, regex operators should be escaped when working with dirtydb).

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

This issue is not so much about crashing node (which happens when your query happens to match too much entries) , but about being able to export the complete contents of the etherpad server without knowing the names of the pads.

So in my opinion it makes sense to filter out all sql LIKE special characters untill this is fixed in ueberDB.

Should be fixed in https://github.com/ether/etherpad-lite/commit/806c9207e365304ef0f3130d7d3ec59f362f8f9d, since it's not calling findKeys anymore. Can you confirm?

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 ????