Ein kompakter und noch ressoucenschonender Webserver, der weder mit PHP noch mit sonst etwas externem gekoppelt wird dafür aber auch nativ API Endpunkte anbieten wird. Die Kommunikation wird dann ausschließlich über Unix Sockets ablaufen und das ganze Webinterface wird aktualisiert um kein PHP mehr zu brauchen (Stichwort React)
Das klingt spannend. Webserver Eigenbau? Bleibt die Möglichkeit weiterhin seinen eigenen Webserver zu betreiben?
Ich glaube PHP ist hier nicht wirklich das Problem, das läuft doch auf den meisten Servern so oder so 
Wenn Ihr das aber eh umstrukturiert, dann berücksichtigt doch mal das https blocking 
Aktuell ist das ja wirklich ein Krampf, besser wäre hier die Möglichkeit die Blockingpage auf eine fixe Domain umzuleiten und die geblockte Seite als Parameter zu übergeben um die Sperre auf der Blockingpage aufzuheben zu können 
Damit kann man die Zertifikatsprobleme umgehen und brauch kein gefrickel.
Sry @ThiloG für das Offtopic
Hmm... das heißt, dass ich beim geblocktem Aufruf kein eigenes PHP-Script (Stichwort custom.php) mehr ausführen lassen kann?
Ja. Wir können natürlich schauen ob sich das was Du mit custom.php umgesetzt hast für alle nutzbringend in den API Server implementieren kann.
Das wird eher nichts für alle sein.
Ich hatte mir überlegt in die custom.php die aufgerufene Domain auszulesen, eine Weiterleitung per Javascript auf eine weitere PHP-Datei einzubauen, wo zusätzlich die Domain als Variabel mit übergeben wird. Das JS würde somit nur ansprechen, wenn User auch wirklich die gesperrte Domain im Browser aufrufen und der Browser dies ausführt. In der PHP-Datei, wohin weitergeleitet wird, würde ich diese Variabel auslesen und in ein Log schreiben. Das Log müsste somit viel kleiner und übersichtlicher werden als das Query Log.
Der Gedanke kam mir wegen meiner Kinder, die so langsam in ein surffähiges Alter kommen.
Hmm, ich sehe anhand Deiner Beschreibung noch nicht so ganz wieso das einen Vorteil gegenüber dem Query Log bietet (außer dass es evtl. kompakter wäre?). Würde es vielleicht etwas bringen, wenn wir einen Hook vorsehen würden, sodass z.B. beim Aufruf einer "bösen" Seite immer ein Skript mit der aufgerufenen Seite als Parameter aufgerufen wird, also z.B.
bash custom.sh www.boese.de
Ich hatte die Vorstellung, dass dadurch die geloggten Domains viel (!) weniger werden würden. Es würden nach meiner Vorstellung nur noch Domains im Log landen, die wirklich im Browser vom User aufgerufen werden.
Das Querylog ist im Grunde zum Durchschauen nicht praktikabel. Man kann es zwar auf den User begrenzen, aber durch diese Vielzahl von Werbe- und Trackingdomains, die sich zum Teil mehrfach stündlich sogar noch wiederholen, wird man Erschlagen von der Menge. Wirklich im Browser aufgerufene gesperrte Domains sind damit nicht leicht zu finden. Daher kam ich auf die Idee mit dem Javascript, halt nur ein billiger Workaround, fast und dirty.
Wenn ich deine Idee richtig verstehe, würde das nur bei wirklich aufgerufenen Domains funktionieren, sprich wenn eine HTTP-Anfrage erfolgt, oder? Das könnte klappen.
Aber die Anfrage käme ja für jeden Inhalt, sei es nun die Hauptseite oder ein Teilinhalt... Vielleicht gibt es nützliche Details in den Headers?...
Mir fallen da keine ein.
Bei mir lag der Hauptaugenmerk auf den Kindern bezüglich XXX-Seiten.
Ich lasse mich einfach mal überraschen, was ihr da so baut und wie man das neueSystem dann nutzen kann. Irgendeine Lösung wird sich dann schon ergeben.
1 Like