Etherpad-lite: Exportar pads com o nome * resulta em uma instância de etherpad sem resposta

https://github.com/ether/etherpad-lite/tree/fix/export-wildcards como uma solução alternativa. No passado, antes de https://github.com/ether/etherpad-lite/commit/a0fb65205c7d7ff95f00eb9fd88e93b300f30c3d , era possível especificar um prefixo e obter uma exportação de pads correspondentes a esse prefixo.

Para entender melhor esse bug, alguém precisa entender a parte do construtor de consultas no ueberdb.

Ao usar um backend sql, ter um pad nomeado para ex. ___ exportará todos os blocos com um nome de 3 letras.

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

O que o ueberdb fará para encontrar a chave (* e% são filtrados no etherpad corrigido, mas _ também é um caractere especial):
SELECIONE key FROM store WHERE key COMO?

Obrigado! Como o ueberdb suporta muitos back-ends de banco de dados diferentes, provavelmente precisamos verificá-los também?

Também seria bom se nós suportássemos os caracteres em nomes de pad e não apenas os filtrássemos, mas, em vez disso, escapássemos deles antes que cheguem ao banco de dados. Vou investigar isso amanhã.

Pelo menos sqlite e postgresql terão o mesmo problema.

Não tenho certeza sobre os outros back-ends de banco de dados.

desculpe, demora tanto ...
mysql, postgresql, sqlite e crate usam% e _
cassandra, couch, rethink, mongo, dirty, redis provavelmente suporta regex no estilo PCRE

leveldb e lmdb não implementam findKeys

Acima? Este é um sério problema de confidencialidade.

FWIW, desativamos o endpoint de exportação do etherpad por este motivo específico. Conforme eu estava lendo o código, percebi que o endpoint de exportação do etherpad não usa o padmanager como o endpoint txt, por exemplo, faz, mas sim chama as funções db diretamente. Eu vou admitir 0 conhecimento interno do ethepad a partir deste ponto, mas como o endpoint export txt não tem esse problema, talvez valha a pena corrigir o endpoint etherpad para usar o padmanager também em vez de lutar contra isso no nível do banco de dados?

Oi,
Qual é o status desse bug?

Acho que esse problema também deve ser criado em https://github.com/Pita/ueberDB. A biblioteca implementa e exporta métodos para escapar dos operadores dependendo do banco de dados com o qual estamos trabalhando (por exemplo, os operadores regex devem ser ignorados ao trabalhar com dirtydb).

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

Esse problema não é tanto sobre travar o nó (que acontece quando sua consulta coincide com muitas entradas), mas sobre ser capaz de exportar o conteúdo completo do servidor etherpad sem saber os nomes dos pads.

Então, na minha opinião, faz sentido filtrar todos os caracteres especiais sql LIKE até que isso seja corrigido no ueberDB.

Deve ser corrigido em https://github.com/ether/etherpad-lite/commit/806c9207e365304ef0f3130d7d3ec59f362f8f9d , já que não está mais chamando findKeys . Você pode confirmar?

ola mesmo problema mas um pouco diferente

assim que eu abrir um pad, o nó fica muito ganancioso 100% de uso da CPU, por favor, faça ???