Gelesen-Funktion - wie funktioniert das?

Hi ciruZ

Das "normale" Session-Timeout liegt bei 30 min.
was du meinst, ist:
wenn der User den Browser zumacht, und sofort bzw. in einen bestimmten Zeitraum die seite betritt, das er die selbe SessionID bekommt.

das ist Möglich, da wenn du das normale Session-Handlinfg von PHP verwendest, die Session nicht abläuft, sobald man den Browser zumacht.
Ist ein großer grober Fehler.
Warum das passiert ist auch logisch.
da viele Systeme die SessionId im Table speichern und zusätzlich ein Cookie absetzten.

So bekommt er falls die Session noch ned abgelaufen ist die selbe.

@DaddyCool
Sicher sollte man das Cookie klein halten, bzw gar ned verwenden.
Bin nicht gerade der Freund von Cookies, aber manchmal können diese schon sehr nützlich sein.
Wenn man Cookies verwendet, soll man auch wissen warum, bzw. welche Nachteile sie bringen können.

Was ich bei meinem Kommentar im anderen Thread "RechteSystem" vergessen habe, ist das ich auch einen GastID habe.
aber das werde ich drüben noch nachziehn

Der größte Nachteil dürfte wohl sein das der User solche Daten manipulieren kann (was bei verschiedenen Systemen schon zu unschönen Sicherheitslöcher geführt hat).

Aus diesem Grund limitiere ich soetwas aufs nötigste und speicher nur dort Werte die sich wirklich nirgends anders unterbringen lassen.

Nun könnte man natürlich den Einwand bringen das meine Guest ID Methode auch nicht das wahre ist, da man soetwas übernehmen kann. Dies ist auch korrekt, jedoch können keine Werte verändert werden und in der Tabelle werden nur ungefährliche Daten gespeichert.

Hi @gain

Du musst auch unterscheiden, welche Cookie-art du verwendest.

Wenn du ein permanetes Cookie hast, kannst du daten sehr leicht manipulieren.

bei einem Session-Cookie wird es schon sehr schwer.

Gebe dir aber recht, das man so wenig Daten wie möglich dort reinspeichern sollte.

Werde das wahrscheinlich auch in meinen neuen System umändern, so das hier nix mehr bzw ganz wenig drinsteht.

Falls was drin steht, mit denen er nichts anfangen kann.

Eine andere Lösung wäre es das Cookie zu verschlüsseln.

Dann müsste es aber eine Methode sei die sich rückgängig machen lässt und wo z.B. der Admin den "salt" (siehe crypt()) bestimmen kann. Ansonsten wäre die methode bereits nachdem Release der Software für den Ar...

Hat mal jemand nen Link zu Verschlüsselungsmethoden parat wo auch beschrieben wird wie diese arbeiten, so das man dieses umsetzen könnte?? (ich will keinen Verweis auf mcrypt )

Ich bin auch gerade am überlegen, ob ein unregistrierter Gast den "Komfort" einer gelesen/ungelesen-Funktion nutzen soll/darf.

Ist ein Gast nicht immer unregistriert bzw. nicht angemeldet??

Wenn du das System für die Nutzer ohne Probleme auch auf die Gäste anwenden kannst (kann man z.B. bei dem System welches ich einsetze) dann solltest du es auch nutzen. Nutzt du ein System wie das YaBB nutzt(e). So ist dies nur mit einem sekundären System möglich. Dann solltest du ggf. darauf verzichten.

Wenn eins drin ist erhöht es aber den komfort.

Jaja, unregistrierter Gast
Ich meine nur, man sollte den Gästen einen (zusätzlichen) Anreiz geben, sich zu registrieren.

Sollten nicht die Diskussionen der Grund sein warum sich ein Nutzer registriert??

Kommt dann wieder darauf an, ob man Gästen das posten erlaubt.

Sorry dann, habe ich das falsch rausgelesen.

Was wolltest du nun wissen? Kenn mi ned mehr aus.

hat sicher vorteile, die ich derzeit aber nicht sehe, wenn ich das jetzt "richtig" verstanden habe.

Wenn er vor dem "Session"-Timeout die Seite wiederbetritt, bekommt er die alte "Session"??

Hi.
Ich habe mir auch mal Gedanken über dieses Thema gemacht. Nun wollte ich euch mal Fragen, was ihr davon haltet.
Das ganze basiert auf Cookies. In dem Cookie werden alle besuchten Topics in einem serializiertem Array der Form $array[$threadid] = $visittime; gespeichert.
Dann wird noch ein zweites Array für die besuchten Foren angelegt.
Auf diese Weise können auch Gäste vom Gelesensystem profitieren und das ganze geht nicht auf die Datenbank, ist dabei aber extrem genau.

Der größte Nachteil, den ich dabei sehe ist folgender: Bei einem sehr großen Board könnte es passieren, dass der Cookie zu groß wird. Was mache ich dann?
User, die keine Cookies zulassen können meine Software momentan gar nicht nutzen (nicht das es da viel zu nutzen gäbe...), von daher ist die Auslagerung dieser Funktion in Cookies kein Beinbruch für solche User. "

Was ich mir noch vorstellen könnte, wäre eine Begrenzung der Topics, die überhaupt als neu gelten drüfen. Also z.B. Topics, die älter als 2 Tage sind, sind immer alt.
Wäre das eine brauchbare Lösung?

(Das die Zeit des letzten Besuchs mit der Zeit des neusten Postings verglichen wird sollte klar sein, oder? ")

Soviel ich mich erinnern kann, dürfen Cookies nur eine bestimmte Größe haben (2 kb?). Da müsstest du haargenau aufpassen, was du in den Cookie schreibst und was nicht.
Das schwebt mir auch vor --> brauchbare Idee

Meines Wissens darf ein Cookie maximal 4kb haben. Das sollte aber auch reichen um für die Dauer einer Session die IDs der besuchten Themen festzuhalten.
Wobei ich das eher auf die Datenbank des Forums auslagern würde, da das ganze dann unabhängig vom Client ist. Du könntest beispielsweise in der Session-Tabelle eine Textspalte machen in der für jede Session die serialisierten Arrays abgelegt werden.
Die Anzahl der Topics, welche als neu gelten, zu begrenzen bringt dir auch nicht viel. Bei einem grossen Board gibt es auch innerhalb von 2 Tagen eine Menge neuer Themen die die Markierungen recht umfangreich werden lassen können. Mal davon abgesehen wäre das eine ziemlich unschöne Lösung.

Ausgehen von deinem (@exe) Text käme mir da noch folgende Idee, die aber wohl noch ausgebaut werden müsste...
Man könnte statt der Session-Tabelle (die ich in diesem frühen Stadium noch gar nicht habe..., bzw. nicht mit diesem Aufgabenbereich) auch ein solches Feld vom Typ text in der Topic-Tabelle einbinden.
Dort würden dann die Userid`s gespeichert, die das Thema bereits gelesen haben. Wird nun ein Eintrag zum Thema hinzugefügt wird dieses Feld geleert.
Das ist simpel umzusetzen, sollte die Performance kaum belasten, und dürfte für die Datenbank auch nicht belastender sein, als ein Posting.
Nachteil, den ich dabei sehe ist, dass die Gäste nicht mehr das Gelesensystem benutzen können...
Oder man schreibt das Array in die Usertabelle, und nicht in ein Cookie... aber dabei würde der Speicher nicht geleert werden...

Dagegen habe ich eigentlich nur folgendes einzuwenden. Wenn ich nun nur die Einträge der aktuellen Session speichere wären automatisch alle Beiträge, die in der vorigen Session nicht gelesen wurden alt, was aber nicht der Fall ist.
Deswegen kommt dieses System für mich nicht in Frage. Jedenfalls sehe ich in dem Bereich keine Möglichkeit, wie ich ein genaues System erreichen könnte.

Danke schonmal für eure Meinungen / Vorschläge.

Bau das mal in ein Forum mit zigtausend Benutzern ein - das gibt eins schön große Datenbank! Und wie ließt du aus, ob DIESER user das Thema schon gelesen hat?

$text = $db->getfield('text');
explode(...)
in_array()

?

ars ... lahm.

Die Markierung in die Topic-Tabelle zu legen wäre wohl keine so gute Idee.
Wenn du ein grosses Board hast werden zwar alle Markierungen wieder entfernt sobald ein neuer Beitrag geschrieben wird. Allerdings wird irgendwann der letzte Beitrag im Thema geschrieben und ab diesem Zeitpunkt bleiben die Markierungen erhalten, verbrauchen Speicherplatz und bremsen die Thementabelle aus.
Ich kenne mich nicht so genau mit den Speichermethoden von MySQL aus, könnte mir aber vorstellen das variable Felder, die sich so oft ändern wie die Markierungen, die Tabelle ganz ordentlich fragmentieren würden was sich, gerade bei einer hochfrequentierten Tabelle wie der Thementabelle, wohl ziemlich ungünstig auf die Geschwindigkeit auswirken würde. Man könnte die Tabelle zwar regelmäßig optimieren, aber das wäre wohl auch nicht Sinn der Sache.
Wenn du die Markierungen in der Session-Tabelle ablegst wäre das weniger tragisch da sich der Inhalt dieser Tabelle sowieso mehrmals am Tag komplett ändert.
Ich würde die Markierungen auch nicht über die Session hinaus halten. Das würde nur eine Menge Speicherplatz verbrauchen. Stell dir mal vor du hast 100 aktive Mitglieder und jedes liest 10 ungelesene Themen pro Tag. Dann hast du 1000 neue Markierungen jeden Tag die dauerhauft gespeichert werden. Angenommen eine Markierung verbraucht durchschnittlich 15 Zeichen (Themenid, Timestamp der Markierung, ein paar Trennzeichen) sammeln sich da mit der Zeit eine Menge Daten an die eigentlich nutzlos sind.

Deswegen meine Idee, dass ganze in einen Cookie auszulagern...

Ich denke da gibt es eine andere Möglichkeit, als die von dir genannte.
Ungetestet und aus einem Geistesblitz heraus:
Nehmen wir an, dass das ganze in diesem Format gespeichert ist:
1,2,3,45,123,
Nehmen wir weiter an, dass der User die Userid "45" besitzt. Nun überprüfen wir wie folgt, ob der User das Thema bereits gelesen hat:
Peinlich ist mir grade nur, dass ich vergessen habe, wie der entsprechende PHP-Befehl dafür lautet... "
Obiges Beispiel ist also als Mischung zwischen Java und PHP anzusehen... "
Edit: Ich glaube der Befehl hieß in PHP strpos... oder? "
Na ja... fü`r`s Beispiel ist das wohl nicht so extrem wichtig...

Da nur alte Themen (hier könnte wieder oben genannte Beschränkung in Kraft treten, obwohl mir die missfällt) nicht andauernd gelöscht werden (neues Posting = alle bisherigen Userid`s löschen) sollte allerdings das Problem mit der Datenbankgröße nicht so extrem sein.

Edit:
Ok. Da hast du natürlich auch wieder recht...

Wie gesagt... das ist mir (leider|zum Glück) klar...
Alternativ könnte man da tatsächlich ein Zeitlimit einfügen... schlimmer als das ganze in die Session-Tabelle zu schreiben wäre das auch nicht, obwohl es mir gegen den Strich geht... zur Verdeutlichung: Wenn letztes Posting länger her als X-Tage, dann lösche Tabelle und sage immer alt.

Wenn die Posting-Tabelle dabei nicht so stark belastet werden soll könnte man das ganze in eine extra Tabelle auslagern... wobei man sich das ganze dann auch wieder einfacher machen könnte...

Werden sie ja nicht. "

Jede Markierung würde nach meinem Beispiel Länge_der_UserID+1 Zeichen (",") kosten.

int strpos ( string haystack, string needle [, int offset])

Aber die meisten Themen sind doch "alte" Themen. Diskutiert wird doch meist nur in den neusten 5 oder, in grossen Boards, auch in den neusten 10.

Die brauchst aber auch den Zeitpunkt der Markierung um, bei einem neuen Beitrag im Thema, feststellen zu können ob diese Markierung überhaupt noch gültig ist. Sonst macht jemand einen neuen Beitrag im Thema und es wird immer noch als gelesen angezeigt. Das gleiche gilt für die Gelesen-Markierung für Foren.

Nicht für einen User, der sich neu angemeldet hat. Da können durchaus nochmal interessante Aspekte in einer bis dahin tot geglaubten Diskussion auftauchen.

Nein. Ich überprüfe nur, ob der User seit dem neusten Beitrag das Topic betreten, bzw. gelesen hat. Wenn er es betreten hat, ist das Thema alt, ansonsten neu.
Wenn ein neuer Beitrag hinzugefügt wurde ist das Thema natürlich für alle User neu. Ergo hat das "neue Thema" noch kein User gelesen, also werden alle UserID`s, die bisher das Thema besucht haben gelöscht -> Datenbank leer.

Das ist dann aber eher der seltenere Fall.


Stimmt, wenn du die Markierungen in der Themen-Tabelle ablegst würde das so funktionieren. Das hat aber, wie ein paar Beiträge weiter oben schon angesprochen, einige Nachteile.
Ich persöhnlich favorisiere es die Markierungen in der Session-Tabelle abzulegen. Vorteil: der Speicherplatz für die Markierungen wird automatisch wieder freigegeben und die Datenbank kaum gebremst, das System ist nicht von Cookies, also vom Client, abhängig und kann somit von jedem Benutzer (auch von Gästen), unabhängig vom Browser, genutzt werden.
Markierungen anderweitig über die Session hinaus aufzubewahren finde ich persöhnlich nicht gut. Das erhöht nur das Speichervolumen, ist resourcenlastiger, und bringt dem Benutzer nicht unbedingt einen Mehrwert. Ich persöhnlich jedenfalls lese ein Thema, was ich bei einem Besuch nicht gelesen habe, bestimmt nicht beim nächsten

Ich schon. Ich hab z.B. morgens, bevor ich mich auf den Weg zur Schule mache, ca. 10 Minuten Zeit. In dieser Zeit "sprinte" ich durch zig Foren und gucke, was es an interessanten Themen gibt, manche lese ich dann auch, zumindest teilweise.
Insofern ist es für mich persönlich immer ärgerlich, wenn ich deswegen andere, für mich neue, Themen übersehe, nur weil ich sie nicht beim ersten Besuch gelesen habe.

In dem Fall könnte man speziell dieses Feld in eine extra Tabelle eintragen. Möglicherweise sogar in eine Datei. Die Datenbank-Tabelle wäre dann wie folgt aufgebaut:
int topic_id; text userlist

Die Datei, die mir im so im Gedankengang sogar besser gefallen würde wie folgt:
Ein Array in serialisierter Form:
$array[$topicid] = $userlist;

Anstelle der serialisierten Variante könnte das ganze direkt in PHP sein, so dass die Datei nur noch included werden muss.
Bei zuviel Daten würde mich das aber auch nicht gefallen... :-/

Wenn du für jedes Thema eine extra Datei anlegst ist diese Variante nicht zu gebrauchen. Wenn du erstmal mehrere tausend Dateien in einem Ordner liegen hast werden die Festplattenzugriffe entsprechend langsam. Wenn du dann für eine Themenauflistung 15-20 Festplattenzugriffe brauchst, 15-20 Dateien einlesen und "entserialisieren" willst geht die Ausführungszeit des Scripts in den Keller.

Na gut. Du hast mich überzeugt... also erst das Session-System ausarbeiten und dann diese Spalte darein packen...

Danke für deine Hilfe (und Gedult).

Edit: Huch... hab ich doch tatsächlich statt "überzeugt" "überredet" geschrieben... "
Sorry. "