nicht angemeldet
Cookies o.ä.
kann ich zb mit einem cookie oder einer anderen Technik auf meiner website 'den letzten zugriff' auf der Seite feststellen ?
d.h.: wenn ein besucher zb heute morgen auf der page war (sagen wir mal 12:31) - und ich dann um 14:51 schauen geh, dass dann auf der page steht wann der letzte zugriff war (vor mir) also: der zugriff von 12:31.
Cool wäre dann noch wenn ich eine technik entwickeln könnte in der man auch noch sieht wer das war (also wieder cookie technik).
aber das ist wieder ein anderes kapitel ;)
freue mich auf antwort.
-
Hi!!
Du kannst doch eine Information in document.cookie = "Besuch=12:31" hinlegen. Geht doch einfach, nur mein auslesen muß man halt nach dem = suchen und dann den String aufsplitten. Die Uhrzeit zum Einschreiben der Info ist ja über die Standardmethoden zu bekommen.
GVT
-
Hi,
Du kannst doch eine Information in document.cookie = "Besuch=12:31" hinlegen. Geht doch einfach, nur mein auslesen muß man halt nach dem = suchen und dann den String aufsplitten. Die Uhrzeit zum Einschreiben der Info ist ja über die Standardmethoden zu bekommen.
Ich hab das anders verstanden, er meinte nämlich, "wenn ein Be-
sucher um 12:31 kommt und ich um 14:51" oder so. "Surferüber-
greifende Scripts" lassen sich nicht mit Cookies programmieren,
da die Informationen nicht vom einen Surfer zum anderen kommen.
Dazu brauchst du schon eine serverseitige Scriptsprache.Bye,
Peter-
Hallo Peter!
Ich will nicht mit Dir streiten, aber der Satzteil "wann der letzte zugriff war (vor mir) also: der zugriff von 12:31" impliziert bei mir schon das es um ein und die selbe Person, also nicht surferübergreifend sein soll.
Für surferübergreifende *g* Lösungen sollte ehr ohnehin PHP, CGI und Konsorten nehmen ==> e'seiden er will sich in der Server hacken *gg*!!
GVT
-
Hallo Peter!
Sorry. Ich hatte nicht "vor mir" sondern "von mir" gelesen.
Für surferübergreifende *g* Lösungen sollte ehr ohnehin PHP, CGI und Konsorten nehmen ==> e'seiden er will sich in der Server hacken *gg*!!
GVT
-
Moin Shir Khan,
Sorry. Ich hatte nicht "vor mir" sondern "von mir" gelesen.
Macht nix, ich auch, aber er hat sich zweimal anders geäußert,
also: 2/3-Mehrheit *g*Bye,
Peter
-
-
-
-
Du hast satte 25 Kilobyte mit deinem Banner verbraten. Ist ja nicht so, daß hier alle mit DSL oder besserem surfen. Ich würde bei 10 Kilobyte die Schamgrenze setzen (für alles darüber sollte man sich schämen).
Abgesehen davon ist deine Art Banner besser als GIF geeignet, nicht als JPEG: Nicht viele verschiedene Farben, dafür aber eine große einfarbige Fläche.
Nur so zur Info... :)
- Sven Rautenberg
-
Hi Michael,
kann ich zb mit einem cookie oder einer anderen Technik
Letzteres, ja.
auf meiner website 'den letzten zugriff' auf der Seite feststellen ?
d.h.: wenn ein besucher zb heute morgen auf der page war (sagen wir
mal 12:31) - und ich dann um 14:51 schauen geh, dass dann auf der page
steht wann der letzte zugriff war (vor mir) also: der zugriff von 12:31.Du kannst im Moment eines Zugriffes diesen auf Deiner Site vermerken (so wie der Webserver das in seiner Protokolldatei auch tut). Beispielsweise könnte ein zu diesem Zeitpunkt aufgerufenes CGI-Skript einfach das Änderungsdatum einer Datei lesen, anzeigen und _danach_ auf 'jetzt' setzen (UNIX: touch <datei>).
Schon bei einem reload wärest aber Du selbst der 'vorherige' Besucher. HTTP erzwingt kein 'Ausloggen' Deines Besuchers - Du kannst also nicht warten, bis sich dieser 'verabschiedet', sondern Du muß auf jede seiner Anforderungen reagieren - denn jede könnte die letzte sein.
Außerdem ist der Begriff 'vorheriger' Besucher reichlich undefiniert, wenn mehrere Besucher zeitlich überlappend Deine Seiten betrachten ...Cool wäre dann noch wenn ich eine technik entwickeln könnte in der man
auch noch sieht wer das war (also wieder cookie technik).Cookie kannst Du in diesem Zusammenhang vergessen - denn der nächste Besucher sieht die Cookies eines vorherigen Besuchers ja nicht.
Diese Information mußt Du schon auf dem Server selbst speichern (beispielsweise in der oben erwähnten Datei).Das Problem ist eher, wie Deine Besucher überhaupt eine "Identität" bekommen sollen. Woran möchtest Du denn erkennen, ob zwei Anforderungen von demselben oder von zwei unterschiedlichen Benutzern gekommen sind? Das können sehr wohl zwei verschiedene IP-Adressen sein, aber dennoch derselbe Benutzer. Oder zwei gleiche IP-Adressen, aber unterschiedliche Benutzer, welche ihre IP-Adressen aus einem Pool ihres Providers haben.
Würdest Du einen per Server Authentication zugriffsgeschützten Bereich verwenden, so daß sich die Besucher über Benutzerkennung und Kennwort ausweisen müssen, dann stünde Deinem CGI-Skript der Benutzername als Environment-Variable zur Verfügung - ein solcher Benutzer wäre wiedererkennbar.
Dasselbe gilt, wenn der Benutzer sich über ein Formular 'anmeldet', von Deiner Site einen Cookie mit dem Inhalt seiner Anmeldung gesetzt bekommt und diesen bei jedem Request immer wieder mit sendet - auch darauf könntest Du reagieren.Normalerweise haben HTTP-Clients keine Identität - dazu müßtest Du erst etwas erfinden. HTTP ist kein Session-Protokoll.
Viele Grüße
Michael-
Dasselbe gilt, wenn der Benutzer sich über ein Formular 'anmeldet', von Deiner Site einen Cookie mit dem Inhalt seiner Anmeldung gesetzt bekommt [...]
genau an sowas dachte ich, aber ich kann mir in der richtung kein bild machen. ich brüchte etwas zum abgucken.
-
Hi Michael,
Dasselbe gilt, wenn der Benutzer sich über ein Formular 'anmeldet',
von Deiner Site einen Cookie mit dem Inhalt seiner Anmeldung gesetzt
bekommt [...]
genau an sowas dachte ich,Das hatte ich befürchtet. ;-)
aber ich kann mir in der richtung kein bild machen.
Es sind auch noch jede Menge Freiheitsgrade drin. Du kannst Dir aussuchen,
mit welcher serverseitigen Intelligenz Du das Formular auswertest, einen
Cookie daraus bastelst und diesen als Bestandteil des HTTP-Headers an den
Browser sendest - und bei nachfolgenden Aufrufen dann immer wieder prüfst,
ob der Cookie vorhanden ist und was drin steht. Da gibt es massenhaft
Möglichkeiten: Perl, PHP, ASP, JSP, ... kommt halt darauf an, was Du kannst
und was Du darfst.Bei Server Authentication brauchst Du das alles nicht zu programmieren -
das erledigt der Webserver für Dich. Deine dynamische Seite (CGI, SSI, ...)
erhält die Benutzerkennung als Environment-Variable und fertig.Deshalb würde ich so etwas generell nur dann selbst bauen, wenn ich mehr
übertragen muß als eine Identität - beispielsweise, wenn ich die Eindeutig-
keit der Kommunikationsinstanz technisch sicherstellen muß.
Wenn ein Benutzer bei Dir zweimal 'angemeldet' ist, dann tut das Deiner
Logik nicht weh, also reicht eine Benutzerkennung; wenn ein Benutzer
dagegen mit derselben Kundennummer etc. in einem online-Shop gleichzeitig
zweimal angemeldet ist, dann darf der Shop nicht mit den beiden Warenkörben
dieses Kunden durcheinander kommen. Deshalb wäre im letzteren Fall vermut-
lich eine zusätzliche Session-Kontrolle erforderlich - und dafür muß dann
zusätzliche Information übertragen werden, um diese beiden Sessions von-
einander zu unterscheiden.
Beispielsweise eben in Form eines Cookies mit einer Session-Nummer drin.ich brüchte etwas zum abgucken.
Das hatte ich auch befürchtet. :-\ Dazu müßte ich aber - wie oben erwähnt - weitere Randbedingungen kennen.
Viele Grüße
Michael-
Hallo Michael,
Es sind auch noch jede Menge Freiheitsgrade drin. Du kannst Dir aussuchen, mit welcher serverseitigen Intelligenz Du das Formular auswertest, einen Cookie daraus bastelst und diesen als Bestandteil des HTTP-Headers an den Browser sendest
... usw. Aber meinst du nicht, es waere das einfachste, Michael zu raten, mal in seine Logfiles zu gucken? Da sieht er doch, wann jemand auf seinen Seiten war ;-)
Fuer mich ist das mal wieder so ein Thema, wo ich nur ins Gruebeln komme. Warum sich den Kopf zerbrechen ueber komplizierte Programmier-Loesungen, wenn es etwas gibt, das genau fuer diese Zwecke gedacht ist?viele Gruesse
Stefan Muenz-
Hallo Stefan,
... usw. Aber meinst du nicht, es waere das einfachste, Michael zu raten, mal in seine Logfiles zu gucken? Da sieht er doch, wann jemand auf seinen Seiten war ;-)
ich sag's ja wirklich äußerst ungerne, aber: Hast Du den gesamten Thread gelesen?
Im Ausgangsposting war m. E. verlangt, diese Information auf der Seite selbst einzublenden.
Und dafür per CGI-Skript das komplette, ggf. viele MB große access_log zu parsen, würde die Sache nicht vereinfachen (und den Server belasten) - vorausgesetzt, er hat überhaupt Zugriff auf diese Log-Datei.Fuer mich ist das mal wieder so ein Thema, wo ich nur ins Gruebeln komme. Warum sich den Kopf zerbrechen ueber komplizierte Programmier-Loesungen, wenn es etwas gibt, das genau fuer diese Zwecke gedacht ist?
Ich halte die Aufgabenstellung noch für unterdefiniert. Mir ist im Laufe des threads noch nicht klar geworden, ob diese Information separat pro Seite oder für einen gesamten Bereich erfaßt werden soll; davon aber hängt es ggf. ab, aus welchen Daten sich diese Information mit welchem Aufwand gewinnen ließe.
Zudem gab es ja Interpretationsspielräume, ob der Besucher wiedererkannt werden muß oder nicht. Letzteres ist sicherlich mit dem access_log alleine nicht lösbar (bzw. nur mit Server Authentication, falls Combined Log Format verwendet wird - das allerdings ist wieder eine Frage der Server-Konfiguration, und diese eine Frage der Zuständigkeiten bzw. Befugnisse ...)Je nachdem, unter welchen Randbedingungen die Lösung eingesetzt werden soll, hat man halt mehr oder weniger Möglichkeiten zur Hand. Die Realisierung als CGI-Skript ist von relativ wenigen Randbedingungen abhängig und somit universell einsetzbar, dafür aber ggf. aufwändiger zu realisieren; andere Lösungen mit weniger Aufwand erfordern ggf. mehr Rechte bzw. Kenntnisse auf dem Server. Dies zu diskutieren und nach einer _passenden_ Lösung zu suchen macht mir am meisten Spaß; deshalb ist die Suche nach einer exakten Definition der Aufgabenstellung ein wesentlicher Teil meiner Beiträge in diesem Forum.
Viele Grüße
Michael
-
-
-
-