기본적으로 내 '비공개'미디어 위키 인스턴스는 유아 돼지 저금통만큼 안전합니다. 지금은 강화했지만 수백 명의 무작위로 생성 된 수백 명의 사용자가 생성 한 약 100여 개의 새로운 페이지와 개정판이 남았습니다.

2 부분 질문; 고아 페이지를 모두 삭제하는 방법이 있습니까? 특정 사용자 (me)가 아닌 모든 개정을 롤백 할 수 있습니까?

danlefree가 제안한 내보내기 및 재설치 방법을 사용하지 않으려면 Nuke 확장이 유용 할 수도 있습니다 . 일단 설치되면 특별 페이지 Special : Nuke를 방문하여 관리자에게 다음과 같은 양식을 제공합니다.

다음과 같은 유용한 내장 미디어 위키 유지 보수 스크립트 도 있습니다.

• cleanupSpam.php- 특정 호스트 이름에 대한 링크가 포함 된 모든 개정판을 롤백 및 / 또는 삭제하는 데 사용할 수 있습니다.

• 파일에 나열된 모든 페이지를 삭제하는 데 사용할 수있는 deleteBatch.php

• rollbackEdits.php (현재 적절한 위키 문서가없는 것)는 지정된 사용자의 모든 편집을 롤백하는 데 사용할 수 있습니다.

직접 데이터베이스 액세스를 사용한 스팸 정리

데이터베이스를 직접 조작하여 원하는 작업을 수행 할 수도 있습니다. 상황에 따라 세부 사항이 약간 다를 수 있지만 기본 단계는 다음과 같습니다.

1. 위키를 읽기 전용 모드 로 설정하십시오 . 당신은 할 수 없습니다 누군가가 데이터베이스와 당신 중에있는 거 메싱을 위키 편집을 시도합니다.

2. 위키를 백업하십시오. (어쨌든 돌이킬 수없는 대량 삭제 전에 강력히 권장됩니다.)

3. 스패머가 만든 모든 사용자 계정을 삭제하십시오. 위의 질문에서와 같이 유일하게 유효한 사용자 인 경우 다음을 수행 할 수 있습니다.

   DELETE FROM user WHERE user_id != YOUR_USER_ID;

   또는 스패머가 위키를 발견 한 후 새 유효한 계정이 작성되지 않은 경우, 가장 유효한 사용자 ID 번호를 찾아서 다음을 수행 할 수 있습니다.

   DELETE FROM user WHERE user_id > LAST_VALID_USER_ID;

   또는 phpMyAdmin과 같은 관리 도구를 사용하여 유효한 계정을 수동으로 선택하고 나머지를 삭제할 수 있습니다.

4. 삭제 된 계정과 관련된 추가 데이터를 정리하십시오. 이것은 꼭 필요한 것은 아니지만 고아 레코드는 사용하지 않으며 삭제하지 않으면 데이터베이스가 복잡해집니다.

   DELETE FROM user_groups WHERE ug_user NOT IN (SELECT user_id FROM user);
   DELETE FROM user_properties WHERE up_user NOT IN (SELECT user_id FROM user);
   DELETE FROM user_newtalk WHERE user_id NOT IN (SELECT user_id FROM user);

5. 유효한 사용자가 작성하지 않은 개정판을 삭제하십시오.

   이것은 큰 단계입니다. 준비 전의 모든 것, 청소 후의 모든 것. 모든 스팸 계정을 삭제 한 상태에서 다음을 수행하면됩니다.

   DELETE FROM revision WHERE rev_user > 0 AND rev_user NOT IN (SELECT user_id FROM user);

   위키에서 익명 편집을 사용하지 않도록 설정 한 경우 (비공개 / 테스트 위키에 강력히 권장) 위의 쿼리는 모든 스팸 개정을 제거하기에 충분해야합니다. 그러나 익명 편집을 사용하도록 설정 한 경우 익명 스팸을 개별적 으로 압축 해야합니다 .

   위키의 모든 anon 편집이 스팸 인지 확실하다면 , UID 0에 의해 우리가 보존해야 할 유일한 편집은 MediaWiki 자체 (wiki 외부에서 가져온 페이지 등)에 의한 것입니다. 이 경우 다음과 같은 쿼리가 작동해야합니다.

   DELETE FROM revision WHERE rev_user = 0 AND rev_user_text BETWEEN '1' AND '999';

   사용자 이름이 IPv4 주소처럼 보이는 UID 0에 의해 수정 된 내용이 삭제됩니다. 즉, 1에서 9 사이의 숫자로 시작합니다.

   위키에 실제 합법적 인 anon 편집이있는 경우 좀 더 창의적으로 만들어야 할 수도 있습니다. 합법적 인 미등록 편집자가 사용하는 IP 주소의 수가 제한되어 있으면 AND rev_user_text NOT IN ('1.2.3.4', '5.6.7.8', '9.10.11.12')위의 쿼리 와 같은 절을 추가하여 해당 IP의 기여를 삭제에서 제외 할 수 있습니다 . 예를 들어 AND rev_user_text NOT LIKE '192.168.%'특정 접두사로 시작하는 IP 주소의 모든 편집 내용을 저장하는 조건을 추가 할 수도 있습니다 .

6. 위의 쿼리는 스팸 개정을 제거하지만 (내용은 여전히 text테이블에 남아 있지만) page_latest영향을받는 페이지 의 필드는 존재하지 않는 개정을 가리 킵니다. 이로 인해 혼란이 발생할 수 있으므로 문제를 해결하는 것이 좋습니다.

   먼저 page_latest모든 페이지 의 열 을 정리해야 합니다.

   UPDATE page SET page_latest = 0;

7. 다음으로, attachLatest.php 유지 보수 스크립트 (권장; --fix스크립트가 실제로 데이터베이스를 변경하도록 매개 변수 를 사용해야 함 )를 실행하거나 수동 SQL 조회 를 사용 하여 열을 다시 빌드합니다 .

   UPDATE page SET page_latest =
       (SELECT MAX(rev_id) FROM revision WHERE rev_page = page_id);

8. 마지막으로 유효한 개정을 찾을 수없는 모든 페이지를 삭제합니다 (스패머가 작성했으며 유효한 컨텐츠는 없었기 때문에).

   DELETE FROM page WHERE page_latest = 0;

9. 마지막으로 rebuildall.php 유지 보수 스크립트를 실행하여 링크, 텍스트 색인 및 최근 변경 사항 테이블을 다시 빌드하십시오 . purgeOldText.php 유지 관리 스크립트를 실행하여 데이터베이스에서 삭제 된 스팸 개정 내용을 제거하여 불필요한 공간을 차지하지 않도록 할 수도 있습니다 .

모든 것이 끝나면 모든 것이 좋아 보이는지 확인하고, 그렇다면 스팸 방지 기능 을 설치 한 후 문제가 다시 발생하지 않도록 읽기 전용 모드를 끄십시오 .

소규모 위키의 경우 간단한 사용자 정의 텍스트 기반 보안 문자를 구성 할 수 있는 QuestyCaptcha 확장을 강력히 권장합니다 . 비결은 모든 위키에 고유 한 질문 세트가 있기 때문에 스팸봇을 올바르게 응답하도록 프로그래밍하는 것은 별다른 이득이없는 작업 일 것입니다. XRumer 에 두 번 공격을 가한 후 내 위키에 설치했으며 그 이후로 스팸을 보지 못했습니다.

추신. 이 지침을 사용 하여 소규모 위키의 많은 사용자가 만든 약 35,000 개의 스팸 개정판을 만들었습니다 . 모든 것이 잘되었습니다. 이 특별한 경우에, 위키 (다행히도!)는 익명의 편집을 허용하지 않았으며, 스팸 발송자가 위키를 찾기 전에 거의 모든 합법적 인 사용자가 생성되었으므로 모든 스팸 계정을 먼저 쉽게 삭제 한 다음 모든 수정본을 쉽게 삭제할 수있었습니다. 그들은 만들었습니다. (우연히 하나의 합법적 인 계정을 실수로 삭제 했으므로 백업에서 복원하고 프로세스를보다 신중하게 다시 실행해야했습니다.) 위의 지침을 업데이트하여 실제로 완료 한 작업을 더 잘 반영하고 좀 더 일반적으로 만들었습니다. .

이 상황을 처리하는 가장 쉬운 방법은 nuke'n'pave가 마음에 들지 않는 경우 사용자 이름으로 만들거나 편집 한 모든 Wiki 페이지를 내보내고 Wiki를 다시 설치 한 다음 생성 한 내보내기 파일을 가져 오는 것입니다.

이 문맥에서 "다시 설치"는 다음을 의미합니다.

1. 귀하가 작성한 기사 내보내기 (아마도 WikiSysop 사용자 또는 이와 유사한 것으로 로그인 된)
2. MW 데이터베이스 삭제
3. 빈 MW 데이터베이스 생성
4. LocalSettings.php파일을 안전한 위치에 복사
5. /config/디렉토리를 다시 업로드
6. 새 MW 데이터베이스에서 설치 프로세스를 실행하십시오 (이전 관리자를 다시 작성하려고합니다).
7. /config/디렉토리를 삭제하고 이전 LocalSettings.php파일을 MW 루트로 다시 이동하십시오.
8. 1 단계에서 생성 된 파일 가져 오기

편집 : 이 프로세스에 문제가 발생하거나 스팸을 제거하는 다른 방법을 실험하려는 경우 데이터베이스 백업 (스팸 개정 포함)을 풀고 싶을 수 있습니다.

이론적으로 MediaWiki 확장을 작성하여 언급 한 작업을 포함하여 MediaWiki 인스턴스에 원하는 모든 작업을 수행 할 수 있습니다.

그 중에서도 danlefree가 제안한 "nuke'n'pave"가 부족하면 User Merge and Delete 확장 기능이 유용 할 것입니다.이 기능을 사용하면 여러 스팸봇 계정을 단일 계정으로 통합하여 더 많은 수정 사항을 해결할 수 있습니다. 용이하게.

이 상황을 처리하는 가장 쉬운 방법은 확장 DeleteBatch 를 설치하는 것 입니다. 위키에서 Special : AllPages를 사용하여 삭제하려는 페이지 이름의 스크립트 파일을 가져 와서 Special : DeleteBatch에로드하십시오.

스팸 페이지가 100 개에 불과하다면 너무 나쁘지 않은 것입니다. 스팸 페이지가 수천 개인 위키를 정리해야했습니다. 나는 사용자에 의해 좋은 팁 건너 온 : Halz이 페이지에 : https://www.mediawiki.org/wiki/User:Halz/Mass_despamming 다양한 도구의 한계에 대한 분석을 포함.

맨 아래에는 약간 느리게 실행되지만 스팸 일 가능성이 높은 페이지를 찾는 데 도움이되는 유용한 SQL 쿼리가 제공됩니다. Halz는 또한 대량의 삭제를 위해 이러한 종류의 쿼리 가능 매개 변수를 제공하는 Extension : Nuke의 해킹 된 버전을 보유하고 있습니다. 그는 나에게 사용할 사본을 주었지만 나는 그것을 출판했다고 생각하지 않는다.

MediaWiki의 SQL을 망설이지 말 것을 강력히 권장합니다! MediaWiki는 Wikipedia에 최적화 된 복잡한 짐승입니다. SQL에는 이상한 일이 있으며 단순히 행을 삭제하면 일관성이 떨어질 수 있습니다.

프로그래밍 기술이 있다면 API를 살펴보십시오. Pywikibot 이 좋은 선택입니다.

그렇지 않으면 maintenance/디렉토리 에서 도구를 확인하십시오 . 당신은 내 자신의 도구, mewsh 를 시도해 볼 수 있습니다 (그리고 방금 "스팸 방지 도구"를 추가했습니다).

나는 설치를 인수하고 user표 에서 47,000 개가 넘는 스팸 항목 과 거의 900,000 개의 스팸을 발견했습니다 externallinks. Sequel Pro를 사용 하고 각 테이블을 방문하여 인증 된 사용자가 작성하지 않은 항목을 삭제했습니다. 나는 스팸을 발견 externallinks, page, searchindex, user, watchlist. 상당히 시간 효율적이었습니다. 내 시간의 대부분은 삭제 쿼리가 실행되기를 기다리고있었습니다. 정통 편집의 대부분이 일의 순서대로 이루어 졌기 때문에 운이 좋았습니다.