Letztens hatte ich mal ein wenig Zeit und habe einen Gedanken aufgegriffen, der uns schon länger im Kopf herumgeisterte: Sessiontracking in CF-Anwendungen bzw. die Möglichkeit beispielsweise als Admin gezielt CF-Sessions einer Anwendung beenden zu können.
Die ganzen Variablen Scopes in CFMX werden ja intern als Structures verwaltet. Cool wäre es daher, wenn es ein “Ober-Struct” gäbe, in dem beispielsweise alle Session-, alle Application- und das Server-Struct läge. Naja, man kann ja nicht alles haben 😉
Also selbst gebaut, Grundidee:
Jedesmal, wenn sich ein User an der Anwendung anmeldet, geniert man eine UUID und schreibt diese in den Session-Scope des Users (bzw. in den Request-Scope) und in eine applikationsweit verfügbare Variable (sinnvollerweise auch ein Struct). In der Variable im Application-Scope legt man ein Unter-Struct mit Namen der erzeugten UUID an, in dem man nun verschiedene Variablen speichern kann.
Wichtig ist dabei zunächst einmal ein Timestamp, der auch bei jedem Request dieses Users im Unterstruct aktualisiert werden muss, um nachhalten zu können, wann die Benutzer-Session ggf. einen Timeout erzeugt hat. In der Application-Variablen kann man aber nun noch weitere Informationen speichern, beispielsweise die letzte aufgerufene URL eines Users, Benutzernamen etc. Damit ist es dann ein leichtes, saubere Mechanismen zu generieren, die den User beim erneuten Login auf die zuletzt besuchte Seite führen. Eine andere Idee könnte ein Messaging-System sein, ein Admin versendet an bestimmte Benutzer eine Meldung über das System, beim nächsten Request der betreffenden User öffnet sich ein kleines JavaScript-Alert-Fenster… der Phantasie sind da keine Grenzen gesetzt.
Wichtig ist noch, dass man beim Logout die entsprechenden Informationen aus dem Struct im Application-Scope wieder entfernt.
Was kann schiefgehen: Der User könnte einfach den Browser schliessen – oder einfach auf eine andere Seite springen, ohne sich auszuloggen. OK, dieses Problem ist da, lässt sich teilweise mit JavaScript-Basteleien verbessern, aber lohnt kaum den Aufwand… Der Effekt den man jetzt hat, ist der dass der User mit einer Verhaltensweise wie eben geschildert noch für x Minuten (x sollte für den oben erwähnten Vergleich genauso gewählt sein wie der Session-Timeout) als eingeloggt angezeigt wird und dann rausfliegt. Wenn dieser Timeout-Wert nicht zu lang gewählt ist, kann man gut damit leben…
Um einer Frage direkt vorzubeugen, warum das alles? Klar, man kann natürlich hergehen und Messaging-Systeme, User-Counter etc. in Datenbanken abbilden. Aber ist das wirklich schön und sinnvoll, wenn CFMX doch eigentlich ein wirklich nettes Application Framework bietet? Davon mal ganz abgesehen – auch bei einer DB-basierten Lösung hat man das Problem, dass irgendwelche Flags noch falsch gesetzt sind, wenn User einfach den Browser schliessen 😉
Kai, sind das jetzt nur wilde Ideen, oder hast Du das schon mal richtig implementiert? Sollte ja eigentlich nicht zu sehr auf die Performance gehen.
Wäre sehr interessant wenn man einen Shop damit ausstattet, so könnte man mal statistisch auswerten, wer sich wann was ansieht, in welcher Reihenfolge, und wo der Besucher keinen Bock mehr auf die Webseite hat.
Jens
😉 Ist so wie es hier beschrieben steht fertig implementiert. Allerdings ist es noch nicht soweit, dass ich sagen würde, dass es total allgemein verwendbar ist – weil es im Moment noch auf die eine App bezogen ist, in der ich es gebaut habe.
Comments on this entry are closed.