nicht angemeldet
Halihallo Andreas
Die Zeit... Die Zeit ist wie ein Raubtier. Du kannst ihm vielleicht
einige male entrinnen, aber am Ende holt es dich immer ein.
In diesem Sinne erst jetzt meine Antwort.
Ich überlege ja schon nebenbei, wie sowas deutlich schonender funktioniert. Den Traffic lasse ich mal außer acht, es ist erheblich "schlimmer" wenn alle User alle 2 Sekunden den Server dazu veranlassen ein komplettes PHP-Framework zu laden, 20 DB-Abfragen abzufeuern... nur weil man wissen will ob der User das überhaupt darf! So ist es halt der einfachste Weg - fürs erste.
Ich halte den Traffic ebenfalls nicht für so problematisch, wie der
erhebliche Aufwand der Scripte. Aber liesse sich diese
Authentifizierung und Überprüfung nicht irgendwie in eine Session
abbilden? - Also: Session einmal eröffnet, ist alles überprüft und es
muss nur noch die Session-Authentizität sichergestellt werden?
Hm. Die Grösse eines Gif's von 1x1 Pixel ist so etwa
50 Bytes. Die einer Header ca. 15 Bytes. Der Unterschied halte ich
doch für verschwindend klein, warum also nicht einfach ein 200 OK
mit 1x1 Bild (und ggf. Cookie) senden? - Das Bild gehört
natürlich Hart-Codiert in einen String der ausgegeben wird (sonst
müsste das OS noch eine weitere Datei öffnen).Naja, es funktiniert halt nur im IE, frag mich nicht warum ;-)
Oh, jeh. OK, das ist natürlich übel...
Ich hab wirklich _alles_ probiert (zumindest das was mit eingefallen ist), aber Firefox und Netscape gehen mit Resourcen (in diesewm Fall Bildern) die per JS geladen werden anders um, als mit HTML. Ich weiß gar nicht ob ich das alles noch zusammenbekomme, jedenfalls hat es im Firefox nur funktioniert, wenn ich _kein_ Bild sende. Sobald ich ein Bild sende - egal mit welchen Headern, auch wenn er es in HTML eingebunden sofort neu laden würde, bzw. "revalidieren", macht er das bei JS nur das erste mal. Der einzige Ausweg ist einen Zähler mitzuführen, und als Parameter an die URL anzuhängen. Da habe ich aber die Befürchtung, dass es da client-seitig irgendwann Probleme mit dem Cache/RAM gibt. Auf alle Fälle kann man den Prozessen zusehen wie sie sich nur dadurch langsam aber sicher ca. 8KB-weise aufblähen. Keine Ahnung unter welchen Bedingingen hier was "gesäubert" wird (wie gesagt, die JS-Implementierungen scheinen nicht dasselbe HTTP zu sprechen ;-)).
Ja, Firefox scheint in der Tat nur Bilder zu cachen... Andere
Ressourcen werden stets neu geladen; habe ich gerade auch bei mir
reproduziert. Nun, wenn es bei allen anderen ähnlich läuft, warum
nicht einfach kein Bild senden (ich z.B. habe es mit einem Flash-Film
versucht, der wurde immer neu geladen).
Wenn NS dann seinen Cache nicht richtig organisiert, trifft
dich wenigstens nicht die Schuld.Wenn das so einfach wäre, erzähl das mal nem Kunden ;-)
Hach ja, richtig...
Eine sehr interessante Idee! Mein Problem mit diesen Dingen ist das folgende: Ich muss eine ganze Menge prüfen und initiieren, bevor ich weiß dass der Anwender ein entsprechendes Recht hat diese Information überhaupt zu bekommen. Es wäre recht angenehm wenn ich immer noch HTTP-Auth verwenden würde, aber leider konnte HTTP-Auth meinen Anforderungen nicht genügen, daher habe ich ein Session-basiertes Login. Der zweite Punkt ist, dass nicht jeder Anwender der eingeloggt ist, auch darauf Zugriff hat. Das Problem solcher performanten Lösunge ist jetzt, dass sie diese Prüfungen umgehen.
Ich sehe das Problem...:
Damn if I do, damn if I don't...
Ich hatte (mal wieder) an mod_rewrite gedacht, welches den Request entsprechend dem Session-Cookie und der "Verzeichnis-ID" im Query-String in das Dateisystem abbildet. Das hatte ich mir schonmal als "performanten Cache" für PHP überlegt. Man könnte aus der Applikation heraus ein Verzeichnis mit einer ID für den Vorgang als Name ablegen, wo eben nur gewisse User Zugriff haben. In das Verzeichnis dann die aktuellen Session-IDs schreiben. Müsste man dann zur Not bei jedem "normalen" Request prüfen/aktualisieren. Mal etwas vereinfacht sowas:
RewriteCond %{QUERY_STRING} ID=([0-9]+)
RewriteCond %{HTTP_COOKIE} SID=([0-9a-z]{32})
RewriteCond %{DOCUMENT_ROOT}/ckeck/%0/%1 -f
Ein sehr interessanter Ansatz, wirklich!
ich bin noch nicht ganz sicher wie die RewriteRule aussehen sollte, aber die könnte ja z.B. wie Du es beschreibst auf eine fertige Datei inkl. Headern gelenkt werden, die bei jeder Änderung der Daten geändert wird. Aber selbst wenn ich hier auf ein PHP-Script leite, hätte ich immer noch den Vorteil, dass bei allen Requests wo sich nichts geändert hat, die Entscheidung und die Antwort selbst direkt vom Apache kommt.
Nun, falls es denn für deine Aufgabe überhaupt möglich ist eine
staatische Datei als Ausgabe zu definieren, so würde immer noch
einiges an Script-Traffic entstehen. Nur: wesentlich weniger als
vorher, im Normalfall. Denn: Das Script müsste nur noch im Falle
einer Datenänderung ausgeführt werden (Trigger) und nicht mehr im
Falle jedes (Lese-)Zugriffs auf "detector.php" (was jetzt eben die
as-is Datei wäre). Da Änderungen im genannten Normalfall wesentlich
weniger Häufig sind, als Anfragen auf das Set-Cookie-File
(detector.php), sinkt der Traffic auf das Script stark und wird durch
die schnellere "as-is-Architektur" (nur noch Apache, kein PHP!)
ersetzt.
Aber den
Gedanken wollte ich dennoch kurz loswerden (für die Script-Kiddies,
die mal einen so geilen HTTP-Chatroom haben möchten :-)).
Woher weißt Du... ;-)
... na, ich will natürlich auch so'n Ding! :-)
Viele Grüsse und schönen Abend wünscht dir
Das wünsch ich Dir auch und vielen Dank für die Anregungen (mal wieder ;-))!
HTH, natürlich :-)
Ach, die Servergeschichte von mir ist auch in Arbeit, aber du weisst
ja, wie es in der Wirtschaft läuft... laaaangsaaaam.
----
Aus dem anderen Posting:
Vielen Dank für den Test! (wenn Du den nicht gemacht hättest hätte ich Deine andere Antwort wohl nicht mehr gelesen ;-))
Warum hättest du meine erste Antwort nicht mehr gelesen? *lange-
leitung-hab-heute*
Viele Grüsse
Philipp