BotTrapWiki: PageRestrictorCustomLocks

NEU: Page Restrictor Sperrdaten auf Whitelist oder Blacklist setzen

Tipp: Loesung ueber ZentralDatei : moechte man ein- und die selben Definitionen fuer mehrere seiner Webseiten anwenden, kann man sich eine Config-Datei basteln, dort die defines definieren, und jeweils vor dem PRES einbinden. Dann muss man nur an einer Stelle die defines anpassen. Man kann auch in diese Datei als letztes den PRES aufrufen. Mehr steht unter ZentralDatei.

Wichtige Kurzinfo: UAs (oder spaeter REFs und URIs) muessen grundsaetzlich komplett (!) kleingeschrieben werden, also "offline explorer" und nicht etwa "Offline Explorer". Moechte man mehrere Daten angeben, bitte die Daten mit | trennen. Beachtet auch den Unterschied zwischen _IP (nur single IPs) und _IPR (nur IPRanges) - und ja, es gibt einen - wirklich ;)

Whitelists wie Blacklists muessen VOR der Einbindung des PRES (also das mit dem require_once) definiert sein, NICHT DANACH und auch NICHT DARIN. Beispiel:

define('PRES_BLACKLIST_IP', '129.69.212.1'); # sperre bspw. einen User der in Deinem Forum Kriege anzettelt, und ueber statische IP daherkommt (sinnlos wenn dynamische Einwahl-IP!)
define('PRES_WHITELIST_UA', 'offline explorer|wget'); # ermoegliche Saugern Deine Seite leerzusaugen
require_once('page.restrictor.php');

Nutzer koennen EIGENE Sperren ueber die jeweilige Blacklist hinzufuegen, wobei mehrere Daten voneinander mit | getrennt und UserAgents klein geschrieben werden:

define('PRES_BLACKLIST_IP', '91.18.216.141'); # sperrt die single IP 91.18.216.141
define('PRES_BLACKLIST_IPR', '91.18.216.140/91.18.216.142'); # sperrt den IPRange von 91.18.216.140 bis 91.18.216.142
define('PRES_BLACKLIST_UA', 'opera|konqueror'); # sperrt die browser Opera und Konqueror [zugegeben ein bloedes Beispiel]
require_once('page.restrictor.php');

Nutzer koennen UNSERE Sperren ueber die jeweilige Whitelist entfernen, wobei mehrere Daten voneinander mit | getrennt und UserAgents klein geschrieben werden:

define('PRES_WHITELIST_IP', '91.18.216.141'); # entsperrt die single IP 91.18.216.141, WENN sie durch uns durch eine Single-IP-Sperrung gesperrt WAERE
define('PRES_WHITELIST_IPR', '91.18.216.140/91.18.216.142'); # entsperrt den IPRange von 91.18.216.140 bis 91.18.216.142, WENN er durch uns durch eine GENAU SOLCHE IPRange-Sperrung gesperrt WAERE
define('PRES_WHITELIST_UA', 'libwww'); # entsperrt den UA libwww, WENN er durch uns GENAU SO gesperrt WAERE
require_once('page.restrictor.php');

Vorsicht Falle: Waehrend man bei der Blacklist voellig frei und flexibel eigene Sperren hinzufuegen darf, muss man bei der Whitelist aus Effizienzgruenden genau das Sperrdatum angeben, das wir urspruenglich sperren. 'offline' in der PRES_WHITELIST_UA wuerde also bspw. nicht ausreichen den 'offline explorer' entsperren, hier muss exakt der selbe string stehen! ebenso wuerde die iprange 1.2.3.20/1.2.3.60 nicht entsperrt werden, wenn die durch uns gesperrte iprange 1.2.3.0/1.2.3.255 waere!

dieser text kann ggf. noch ausgebuat werden, sollte als einstieg schon mal reichen.. hopefully!

ACHTUNG: Dies wurde implementiert, da viele Nutzer mit der Verwendung der alten INCs zum einen ueberfordert waren, zum anderen dies oft Quell unsaeglicher Fehlerquellen war. Die INCs werden daher zum 01.07.2008 unwiderruflich "ABGESCHALTET" (konkreter: nicht mehr eingebunden).

Haben die Whitelists sicher immer wieder eine Berechtigung, weil man dies und jenes doch erlauben moechte, ueberlegt bitte bei den Blacklists erst ob ihr wirklich eine eigene Blacklist fuehren wollt oder muesst, oder den "poesen Puben" stattdessen bei uns meldet. Die Blacklist kann aber sinnvoll sein, wenn man bspw. einen nervenden User im eigenen Forum - sofern er ueber statischer IP daher kommt - dauerhaft aussperren kann.

Weiterfuehrende Gedanken, noch offene Problematik:
1. wir sperren iprange 1.2.3.50/1.2.3.60
2. der nutzer entsperrt iprange 1.2.3.50/1.2.3.60 auf seiner whitelist
3. es kommt bei uns ein user request rein dass 1.2.3.55 eine gute ip ist, wir splitten auf und haben
4. nun 1.2.3.50/1.2.3.54 und 1.2.3.56/1.2.3.60 gesperrt
5. nun greift die whitelist entsperrung nicht mehr

DER FOLGENDE TEXT IST VERALTET UND NICHT MEHR AKTUELL

ALTLASTEN: Page Restrictor Sperrdaten auf Whitelist oder Blacklist setzen

VERALTETE ZWISCHENVERSION ("zweitaeltest"), die so NIE zum Einsatz kam:

Derzeit ist nur die PRES_WHITELIST implementiert, die PRES_BLACKLIST folgt ggf. noch, hat jedoch niedrigere Prioritaet, da man vorrangig lieber boese Bots melden sollte, damit alle was davon haben und man nicht wieder in den Wahn verfaellt fuer jede Domain seine eigene Suppe kochen zu muessen. Die PRES_WHITELIST wurde eingefuehrt, um es fuer Laien einfacher und vor allem narrensicherer zu machen, durch uns gesperrte IPs, IPRanges oder UserAgents einfach freizuschalten.

Wie geht das? Grundsaetzlich muss eine Konstante namens PRES_WHITELIST definiert werden und zwar VOR dem dem Einbinden des PRES mittels z.B.: require_once('page.restrictor.php'). Beispiel:

define('PRES_WHITELIST', '|IP:1.2.3.4|IP:5.6.7.8|UA:sumabot|IPR:10.20.30.0/10.20.30.255|');

Jeder "Datensatz" wird von | eingeschlossen, nach dem ersten | folgt die sperrart, dies kann derzeit sein [Achtung, diese muessen in GROSSBUCHSTABEN sein]:
IP: - fuer single ips im format 1.2.3.4
IPR: - fuer ipranges im format 1.2.3.0/1.2.3.255
UA: - user agents, in kleinbuchstaben, also z.b. sumabot, nicht aber SumaBot

Nochmal, wichtig ist das Einschliessen eines jeden "Datensatzes" mit |, also z.B. |IP:1.2.3.4| und nicht nur IP:1.2.3.4 - diese Begrenzerzeichen sind fuer ein "schnelles Abtasten" durch das Script noetig. Das Leerzeichen konnte als Trenner nicht verwendet werden, da es in user agent strings vorkommen kann, z.b. in "offline explorer". das was man entsperren moechte muss bei ipranges 1:1 so durch uns urspruenglich gesperrt werden, zumindest bei ipranges und bei user agents. wenn wir

1.2.3.20/1.2.3.27

sperren, und man durch die whitelist mit |IPR:1.2.3.0/1.2.3.255| entsperren will, klappt dies nicht, die sperre waere trotzdem aktiv. nur nur |IPR:1.2.3.20/1.2.3.27| entsperrt hier wirklich. dies hat laufzeit-optimierungsgruende.

es folgen noch ein paar beispiele:

define('PRES_WHITELIST', '|IP:1.2.3.4|');
--> entsperrt die ip 1.2.3.4. es ist egal ob diese durch uns gesperrt wird oder nicht, die ip 1.2.3.4 wird immer entsperrt sein!

define('PRES_WHITELIST', '|IPR:1.2.3.0/1.2.3.255|');
--> entsperrt die iprange 1.2.3.0/1.2.3.255 , dies aber (derzeit) nur wenn diese genauso durch uns gesperrt wird!

define('PRES_WHITELIST', '|UA:offline explorer|')
--> entsperrt den user agent "Offline Explorer", aber nur wenn dieser durch uns gesperrt wird. wichtig ist dass der teilstring kleingeschrieben wird!

verknuepfen ist einfach moeglich, siehe beispiel ganz oben. dabei reicht ein begrenzerstrich zwischen je zwei daten, also z.b. "|IP:1.2.3.4|IP:5.6.7.8|"

wer mag kann diesen text noch etwas ausbessern und verschoenern. ich habe gescripted, getestet obs geht und diesen text geschrieben. alles moechte ich auch nicht machen ;)

ALTLASTEN

Der folgende Text ist die Art und Weise wie dies bisher konfiguriert wurde. Da sich herausstellte, dass dies mit einigen Problemen behaftet ist, insbesondere bei Laien, sollte man dies moeglichst zukuenftig vermeiden.
Es besteht sogar die CHANCE dass die alten INC irgendwann ganz abgeschaltet werden.

ALTLASTEN: Page Restrictor Sperrdaten aendern/hinzufuegen/loeschen (optional)

Hierzu ist im selben Verzeichnis des Page Restrictors eine PHP Datei namens

page.restrictor.inc

anzulegen. Bitte auch nicht darin das <?php ... ?> vergessen.
ACHTUNG: auch hier gilt: KEINEN TEXT AUSGEBEN, weder vor dem <?php noch nach dem ?> ... sonst funktioniert die Freischaltung durch die Rechenaufgabe NICHT. Bitte auch keine zwei <?php ?> Bloecke, unterbrochen von einer Leerzeile, auch dies fuehrt zum NICHT-Funktionieren der Freischaltung der Rechenaufgabe. Hatten wir alles schon!

Diese Datei ermoeglicht die Manipulation der folgenden Sperrdaten:
$forbiddenReferers $forbiddenIPRanges $forbiddenIPs $forbiddenUAs .
und das Ändern von Meldungen, z.B. $forbiddenCustomMessage.

Es folgen Beispiele:

NEUer Page Restrictor "Turbo" (ab v0.2)

Die Turbo Version befindet sich derzeit noch im Code Review und in der Pruefung. Teilnehmen kann man u.a. als DevelopMentor (siehe entsprechendes UnterForum) oder per eMail. Aber irgendwann (hoffentlich bald) ist es soweit!! :)
In einer Uebergangsphase wird davor geWARNINGt, wenn man noch alte INCs einsetzt. Das geschieht durch die Ausgabe einer kleinen Meldung via echo.. (ggf. gefolgt von einem return, d.h. der Nutzer wird gleich 2x darauf aufmerksam: 1. eine Warnmeldung und 2. blockt der PRES nicht mehr)

Die SperrDaten heissen derzeit (kann noch geanedert werden) und sind alles "einfache Arrays" (Achtung, die IPs sind etwas "speziell"):
$presIPs = array(iplongBegin => iplongEnd, ...);
$presUAs = array('ua1', 'ua2', ...);
$presREFs = array('ref1', 'ref2', ...);

todo: beschreiben wie man loescht, hinzufuegt, aendert..

das ab hier war (bald) einmal

ALTer Page Restrictor (vor v0.2)

Hinzufügen von Sperrdaten

Ein Beispiel: (Operator .= beachten sonst ueberschreibt ihr alles! )

IPs sind in vielen Schreibweisen moeglich:

Einzeilig:

$forbiddenIPs .= ' 83.142.57.246 213.255.157.41 ';

oder mehrzeilig (mit Kommentaren)

$forbiddenIPs .= <<<MYIPS_END
83.142.57.246 PERMAMENT TRACKBACK FAKER
213.255.157.41 ging in bot-trap
MYIPS_END;

IPRanges, Referer, UA sind nur in einer Schreibweise moeglich:

Hinzufuegen mehrerer zu sperrender Referer (wie auch bei UAs und IPRanges) geht nur auf diese Art: (Zeilenumbruch beachten, muss ein Linuxsches "\n" sein).

$forbiddenReferers .= <<<MYREFERERS_END
ottosuch.de
.dealx.info
MYREFERERS_END;

Entfernen von Sperrdaten

Der andere Weg: Zulassen von durch Page Restrictor gesperrten IPs, UAs, IPRanges, Referers:

Beispiel:wir moechten ottosuch.de erlauben: (das anschliessende \n beachten, bei single IPs nicht noetig)

$forbiddenReferers = str_replace("ottosuch.de\n", "", $forbiddenReferers);

Beispiel: Wir möchten eine Liste von Server-IPs explizit wieder freigeben, unabhängig aus welchem IP-Rage sie kommen und mit welchem User-Agent zugegriffen wird (um die Kommunikation zwischen eigenen Servern zu ermögliche, die in gesperrten Rechenzetren stehen) und diese Zugriffe in einem eigenen Log speichern:

// enter in this block allowed IPs, line for line, single IP, comments possible
$allowedIPs = <<<IPS_END
213.239.215.208
IPS_END;

$thisIP = $_SERVER['REMOTE_ADDR'];
if (strpos($allowedIPs, $thisIP) !== FALSE) 
{
	if (session_id() == '') session_start();
	$_SESSION['pres_unlock'] = 1;
	$presLogFile = './page.exceptions.log';
}