Page Restrictor Installation und Test

Bitte immer sicherstellen dass RegisterGlobals OFF sind! Dies dient der eigenen Sicherheit - sonst empfehlen wir grundsaetzlich gar nichts auf Ihrem Webserver zu installieren, auch nicht unser Script.

Generische Installationsanweisung:


1. Download des PHP Scripts, siehe http://www.bot-trap.de/
2. Auf dem eigenen Server speichern, (derzeit noch) zwingend unter dem Namen page.restrictor.php (fuer Auto Updater)
3. Diese Datei mit genuegend Schreibrechten versehen, z.b. mit chmod 664 setzen (fuer Auto Updater) => Laien hierin EMPFEHLEN WIR UNBEDINGT den Absatz unten mit (*) LESEN!
4. In die eigene Seite (moeglichst als erstes ganz ganz oben!) einbinden, z.B. in die index.php einbinden mit require_once('page.restrictor.php'); => Laien hierin EMPFEHLEN WIR UNBEDINGT den Absatz unten mit (#) LESEN
5. Pruefen ob sich das Script selber updaten kann, dazu eigene-domain.de/ page.restrictor.php?pres=check aufrufen, dort muss bei writeable ein YES stehen, dann ggf. mit eigene-domain.de/ page.restrictor.php?pres=update pruefen ob sich das Script WIRKLICH updaten kann!

(*) Achtung, dies kann bei manchen Anbietern zu Problemen führen - und bitte unbedingt immer erst testen ob mit den gesetzten Dateirechten ueberhaupt ein Update geht!)
Einen schoenen Text fuer Laien hat hierzu Master_D geschrieben: als PDF oder Text
Wir empfehlen zu pruefen, ob das Script auch mit weniger (chmod) Rechten funktioniert. Leider ist es jedoch so, dass es immer vom ServerAdmin abhaengt, ob es nun ein chmod 664 sein muss, oder noch weniger Rechte ausreichen.
Wir empfehlen keinesfalls den Auto Updater abzuschalten indem er zu wenig Rechte erhaelt, da staendig neue Sperrdaten hinzukommen, und alte Sperrdaten entfernt werden koennen, aber auch das Sperrscript selbst laufend verbessert und erweitert wird.
Immer wieder muessen wir PRES Nutzer darauf hinweisen dass sie mit voellig veralteten Sperrdaten arbeiten, und im Forum schlagen dann deshalb entruestete User auf. Es ist geradezu Unsinn, den Auto Updater des Schutzscripts abzuschalten,
ist er doch eigentlich ein wesentlicher Bestandteil (wenn nicht gar die Grund-Intention!) des PRES Schutzscripts. Oft entbrennt eine Diskussion wie gefaehrlich nun chmod 777 eigentlich waere. Fakt ist, dass dies i.e.S. nur eine Gefahr darstellt, wenn der Eindringling
es sowieso schon auf den Server geschafft hat. ABER: man sollte auch mal die folgende Seite bedenken: wer den Auto Updater abschaltet verhindert auch dass evtl. entdeckte Fehler im Script korrigiert werden - was u.U. viel gefaehrlicher ist als chmod 777 ;-)

NICHT IN JEDES UNTERVERZEICHNIS KOPIEREN
Es reicht vollkommen aus, den Page Restrictor an eine einzige Stelle hochzuladen, z.B. ins Hauptverzeichnis. Es ist Unsinn bis Wahnsinn, ihn in jedes Unterverzeichnis zu kopieren. Bei der Einbindung mittels require_once() einfach darauf achten ggf. den Pfad mit anzugeben!

(#)
BITTE BEIM EINBAU UNBEDINGT BEACHTEN: den PRES ganz OBEN ALS ERSTES EINBINDEN
Der Page Restrictor sollte moeglichst weit oben / frueh eingebunden werden, denn es darf keinesfalls zuvor ein Header oder eine Ausgabe an den Browser geschickt werden/worden sein (kein <html> davor etc., auch keine Sprachdefinition ala '<!DOCTYPE HTML PUBLIC "-/W3C/DTD HTML 4.0 Transitional/EN">') und keine sogen. Byte-Order-Mark durch UTF-8, bevor der Page Restrictor eingebunden wird. Ist dies naemlich der Fall, dann kann ein versehentlich gesperrter User durch die Mathe Captcha Aufgabe NICHT temporaer freigeschaltet werden (Warning: "headers already sent"..).
UTF-8 Dokumente koennen Probleme verursachen!
dies wurde von einem User berichtet: "... das die oben erwähnten Sonderzeichen zzgl. der Page-Restrictor-Meldungen für "Headers allready send" etc. pp. und diverser Meldungen von WP auftauchten. Grund für das "Erscheinen" der Sonderzeichen ist weniger das Programm an sich - ich benutze nicht "MS Expression Web" sondern "Notepad++". Verantwortlich dürfte viel mehr eine Einstellung zur Bearbeitung der Quelltexte sein. Unter NP++ lässt sich im Menü unter "Format" die Kodierung des Quelltextes einstellen. Steht diese Einstellung auf "UTF-8", erscheinen die Sonderzeichen (Anmerkung: die sogen. Byte-Order-Mark fuer UTF-8). Zurückgestellt auf "ANSI" und alle Dateien überarbeitet ist wieder alles in Ordnung."

Wer mag, kann im selben Verzeichnis in dem das Script liegt, eine page.restrictor.log Datei anlegen und mit mindestens chmod 664 Schreibrechte vergeben, fortan werden alle Gesperrten dort protokolliert.

Eine ausfühlichere Anleitung sowie Tipps für einzelne Fertigsysteme sind hier zu finden.

Valid XHTML 1.0 Transitional :: Valid CSS :: Powered by WikkaWiki