Etherpad-lite: *라는 패드를 내 보내면 응답하지 않는 etherpad 인스턴스가 생성됩니다.

해결 방법으로 https://github.com/ether/etherpad-lite/tree/fix/export-wildcards . 과거에는 https://github.com/ether/etherpad-lite/commit/a0fb65205c7d7ff95f00eb9fd88e93b300f30c3d 이전에 접두사를 지정하고 해당 접두사와 일치하는 패드를 내보낼 수있었습니다.

이 버그를 더 잘 이해하려면 누군가 ueberdb의 query-builder 부분을 이해해야합니다.

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가 키를 찾기 위해 수행 할 작업 (* 및 %는 패치 된 etherpad에서 필터링되지만 _는 특수 문자이기도합니다) :
SELECT key FROM store 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 수준에서이 문제를 해결하는 대신 padmanager를 사용하도록 etherpad 엔드 포인트를 수정하는 것이 좋습니다.

안녕하세요,
이 버그의 상태는 어떻습니까?

이 문제는 https://github.com/Pita/ueberDB 에서도 생성되어야한다고 생각합니다

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

이 문제는 노드 크래시 (쿼리가 너무 많은 항목과 일치 할 때 발생 함)가 아니라 패드의 이름을 몰라도 이더 패드 서버의 전체 내용을 내보낼 수 있다는 것입니다.

따라서 제 생각에는 ueberDB에서 수정 될 때까지 모든 sql LIKE 특수 문자를 필터링하는 것이 좋습니다.

더 이상 findKeys 호출하지 않기 때문에 https://github.com/ether/etherpad-lite/commit/806c9207e365304ef0f3130d7d3ec59f362f8f9d 에서 수정해야합니다. 확인 할수 있어요?

안녕하세요, 같은 문제지만 조금 다릅니다

패드를 열 자마자 노드는 100 % CPU 사용량을 매우 탐욕스럽게 만듭니다. koi do ????