Wenn ich mir so meinen Geldbeutel angucke: Ja, es macht Sinn :) Der Provider, über den ich mich einwähle, bietet sekundengenaue Taktung und das ohne Verbindungsgebühren oder Mindestnutzungsdauer.

Wie Sessions von Helma/Java/JSP etc. unterstützt werden kann ich leider nicht sagen, beim Programmieren eines WBT-Tools für die FHTW (http://musical.fhtw-berlin.de) benutzte ich Sessions auf PHP-Basis.

Beim Einloggen wird eine Session-ID erstellt, beim Ausloggen zerstört. Die zur Session gehörigen Daten fristen ihr kurzes Leben auf dem Server, so dass der User keine ungewollten Veränderungen vornehmen kann. Der Browser des Users speichert nur seine ihm zugewiesene Session-ID als Cookie oder reicht sie bei jedem Seitenaufruf als Übergabeparameter weiter. Eine Lebenszeit (TTL) der Sessions und der zugehörige Timeout sind festlegbar, soweit ich es rekonstruieren kann im config-file des (Apache-)Webservers.

.. wäre auch für unseren ::collabor:: Server sinnvoll. Einzige Frage die offen bleibt: was passiert mit der ID, wenn der User nicht ausloggt, sondern einfach den Browser bzw. das Browserfenster schließt. So handhaben es wahrscheinlich die meisten ...

Dann TTL ?

H. Mittendorfer

Ja ich denke wenn der TTL auf 20 Minuten gesetzt wird, sollten sich sicherheitsrelevante Probleme reduzieren.

Natürlich gibt es dann immer noch das Problem, was mit öffentlichen Computern passiert, bei denen sich der Nutzer nicht ausloggt und ein neuer Nutzer gleich wieder das collabo benutzt. Dieses Problem gab es ja bei CLIX, dort wurde es allerdings nicht gelöst.

Meine Idee für einen solchen Fall wäre ein checkbox (Dies ist ein öffentlicher Computer) bei dem das TTL dann aggressiver behandelt wird und sich die session nur von refresh zu refresh "schleppt" ;)

M Plogas

.. doch es könnte auch angemessen sein, das eine oder andere Problem einfach "stehen zu lassen". Die Frage ist, wie relevant bzw. wahrscheinlich ist der von Ihnen soeben beschriebene Fall.

Die Vernachlässigung des "Restrisikos" bringt auf alle Fälle Komplexitätsreduktion. Und dieses ist auch von "wert".

H. Mittendorfer

PS: Dennoch wäre eine Umstellung auf Seseion ID als solche sehr überlegenswert!

ich denke die relevanz ist abhängig von der Nutzung des Weblogs. Wenn der Dozent auf die Nutzung des Weblogs wert legt ist die Relevanz deutlich größer für oben beschriebenes Problem. Denn dann werden sich die Studenten von den öffentlichen PCs in der Hochschule natürlich auch einloggen...

Ist das Weblog allerdings "privater" Natur (darf man das hier überhaupt?) wird sich sicher keiner während der Vorlesung von einem öffentlichen PC einloggen, zumindest kann ich mir das schwer vorstellen.

M.Plogas

BTW: gibt es die Möglichkeit einer e-mail Benachrichtung im Falle einer Antwort?

Das Thema haben wir schon mal mit der Admin-Gruppe diskutiert, weil es ein schönes Feature wäre. Im WS03 hat eine Projektgruppe auch schon daran gearbeitet. Leider darf man an der FHTW aus nachvollziehbaren Gründen keinen eigenen SMTP-Server betreiben, was die Sache schwierig macht.
Vorerst hilft ein RSS-FEED-READER.(siehe Tip von Frau Ackermann). Wenn Sie einen solchen installiert haben, können Sie den Datenabruf selbst konfigurieren, wozu Chritian Köppe eine hilfreiche Übersicht der RSS-FEEDS in seinem nützlichen Weblog angefertigt hat.
Um jetzt die letzten 20 Änderungen (Stories und Kommentare) zu erhalten könnte man bspw. folgenden Feed abbonieren: /s0503552kimss042/rss?typ=lastchanged&count=20.

Ich benutze den Feedreader seit ein paar Wochen: An sich empfehlenswert (klein, einfach, nicht überladen ...), allerdings wird die "Z"-Taste intern als Shortkey zum Ein-/Ausblenden der abonnierten Weblogs benutzt. Die Links der RSS-Feeds werden im Feedreader internen Frame (IE-Instanz) angezeigt, wer darin schreiben will muss sich also auf Texte ohne den Buchstaben Z beschränken, was mich zumindest nervt... .