Neue Page Restrictor Version:
- sollte ggf. ein Rechenaufforderungs Captcha anbieten bei Sperren, Bsp auf http://www.bot-trap.de/captcha-calc.php∞ - um so versehentlich gesperrte User wieder freigeben zu koennen. WICHTIG: die Freischaltungen MUESSEN festgehalten werden um unsere Sperren zu verbessern. Vielleicht im Log? jedesmal ne eMail koennte boese enden..
- das Log ist ab ner bestimmten Groesse nicht mehr tragfaehig. Vielleicht sollte es z.B. alle 100 KB geloescht und wieder neu begonnen werden..

- fast unnoetig: Client Browser Caching Deactivation forcen fuer ein ?pres=update , z.B. mit zufaelliger rndNr in der URL - lieber von Hand forcen (shift oder control + aktualisieren)?

- fast unnoetig: nicht sooo wichtig, faellt evtl. raus: feststellen des Dateinamen und des Verzeichnisses des PRES + Logs + incs, so koennte man es auch pres.php in /timbuktu/plugins/ oder so ablegen.. Code blaeht sich aber dafuer auf, fast unnoetig..

--

Da hatte ich mir gestern auch Sorgen drüber gemacht! Das Teil "explodiert" geradezu! Allerdings würde ich es nicht nach 100kB komplett löschen.
Kann man nicht einfach automatisiert jede Woche ein neues Logfile anlegen mit beispielsweise der KW* als Dateiendung? So hat man auch später noch Zugriff auf vergangene Logfiles und kann diese nach belieben löschen.

Waere auch ne Idee, dann muesste man bspw. aber ein /log/ Verzeichnis anlegen und dem 777 chmod Rechte geben. Dort wird dann jede Woche ein File begonnen ungefaehr so:
page.restrictor.20060710.log
das ist uebersichtlicher als mit Karenzwochen..
d.h. jede Karenzwoche kommt der Wochenstart-Termin rein. Oder man machts gar nicht mit Karenzwochen sondern sagt: ab Startzeitpunkt alle 7 (oder 3 ..? oder 5..?) Tage.

• Das klappt schon: siehe "Aendern der LogDatei"

--

Wünsche / Anregungen von Sebastian Blum btw (at) sblum [d0t] de

(Habe selbst eine Seite mit über 2.000.000 Seitenabrufen täglich, 3 Webservern im Cluster, studiere Wirtschaftsinformatik in Regensburg)

Finde das Projekt super, jedoch bei der Ausführung der Programmierung ein paar Eigenheiten, die ich kurz vorstellen möchte.
- Einrichtung einer eigene Konfigurationsdatei, z.B. page-restrictor.config.inc.php, die auch Pfade enthält und die wichtigsten Einstellungen
(Problem: bei mir am Cluster gibt es Ordner, die Werten automatisch alle 3 Minuten per rSynch überschrieben und es gibt Pfade, die per NFS auf dem File Server liegen - aktuell wird mir die Datei immer vom Fileserver überschrieben)
- Automatisch aktualisierte Datei: page.restrictor.autoupdate.inc.php
die soll sich automatisch Updaten vom Server und sich danach ausführen
- Eigene Datei zum Aussperren / Aufheben von Sperrungen
z.b. page.registrictor.ownentries.inc.php
Dort können eigene Werte eingetragen werden
- Cache Datei page.restrictor.cache.inc.php, die den Cache enthält

Jetzt die gewünschte Funktionsweise:
1. page.restrictor.config.php wird includet vom Skript
Definiert Konstanten und überprüft, ob Auto-Update durchgeführt werden soll.
Falls Auto-Update: Herunterladen der page.registrictor.autoupdate.php und diese danach ausführen.
Danach: page.restrictor.cache.inc.php ausführen

SPEED ALTERNATIVE
es wird die page.restrictor.cache.php direkt aufgerufen, damit braucht man nur 1 Include ausser beim Update und die Werte der page.restrictor.config.php werden "kompiliert" mit in die age.restrictor.cache.php übernommen.

2. Beim Autoupdate:
Auto-Update enthält neue Aussperrungen, neuen Quelltext.
Danach wird page.registrictor.ownentries.inc.php geladen, die Aussperrungen hinzugefügt und falls Freigeben erteilt werden, aufgehoben. Danach wird das ganze auf Konsistenz (ob sich IP Ranges überschneiden oder in anderen Einträgen enthalten sind). Wenn dieser komplizierte Vorgang abgeschlossen ist, werden alle Kommentare entfernt und eine neue PHP-Datei, die page.restrictor.cache.inc.php erzeugt, die jetzt die Aussperrung vornimmt.
Somit ist zwar die Last beim Update besonders groß, aber bei den einzelnen Seitenabrufen möglichst gering.

3. Cache-Datei: enthält die Funktionsweise in kürzester Form, ohne Kommentare und ist komplett auf Speed optimiert.

4. NEUE FUNKTIONEN:
Einteilung in beispielsweise 3 Kategorien:
- Bots / Suchmaschinen / Personen

Ziel:
eine Konstante geliefert bekommen, um welche Kategorie es sich handelt für die weiteren PHP Scripte

Wieso?
nicht für cloaking, sondern um beispielsweise bei Suchmaschinen keinen Sessions zu starten, da die meisten Suchmaschinen nicht das /datei.php?phpsessid=blablabla haben möchten, sondern nur /datei.php

das ist der Funktionsumfang, den ich mir vorstellen würde und ich würde mich gerne bei der Programmierung auch beteiligen.
vielen Dank fürs Lesen
Sebastian Blum
www.ednetz.de∞


evtl. genauer:
17120235x: du includest page.restrictor.cache.php 1 mal
17120235x: das reicht für alle abrufe wenn nichts upgedatet wird
17120235x: erst beim autoupdate wird die config geladen, die neue update datei, meine eigenen erweiterungen,
17120235x: danach werden meine erweiterungen und die autoupdate liste auf konsistenz überprüft
17120235x: und anschließend eine neue page.restrictor.cache.php auf grundlage der config / autoupdate datei / eigenen erweiterungen erzeugt