User wiedererkennen

[Condor93]

Moinsen,
ich bastel gerade an einen Login System und wollte mal fragen, wie "Eingeloggt bleiben" nun genau funktioniert.

Ich weiß nicht, was ich in einen Cookie schreiben soll. Soll ich dort die Hash-ID des Users reinschreiben oder was kommt darein? Doch die Login Daten?

[Condor93]

Session basiertes login - der User wird nach Einstellung oder automatische Zeitvorgabe automatisch ausgeloggt/gekickt, sobald er die Session life überschritten hat. Damit dies nicht passiert, wird die session life des User nach jeder Aktion wieder erhöht.

Meine Frage ist: soll ich die Session in der DB erhöhen oder via $_SESSION erhöhen? Bei der Performance wäre da die $_SESSION besser. Da aber die SESSION_ID in der dB aindeutig ist, sollte die dB es auch locker hinbekommen oder?

[VPh]

Ich versteh sowieso nicht warum Leute kein ORM nehmen .. dann hat sich doch das Problem mit der mysql_ Schnittstelle erledigt.. Doctrine z.B. ..

Erzähl das mal den Kandidaten, denen der Umstieg von mysql_* auf mysqli_* schon zu viel ist.

[ChristianK]

Hast du schon einmal "why not use orm" gegoogelt? Es gibt - meiner Meinung nach - genug Argumente, möglichst oft darauf zu verzichten.

[Sakron]

Ich versteh sowieso nicht warum Leute kein ORM nehmen .. dann hat sich doch das Problem mit der mysql_ Schnittstelle erledigt.. Doctrine z.B. ..

Ansonsten vllt noch interessant: Tracking

[Condor93]

Musstest du mir das jetzt den Link so zeigen... hausl?
Jetzt muss ich mein bisheriges Zeug in PDO machen... auch wenn ich es jede SQL Abfrage (von jeweiligen Modul) in einer eigenen Klasse drin habe (und meine standard Datenbankklasse)...

Das mit den Login hätte ich auch so gemacht, das er da schnell einmal die Daten reinigt. Danke für das Beispiel ChristianK.

[ChristianK]

Brauchst du nichtmal. Einfach bei jedem Seitenaufruf als erstes

DELETE FROM sessions WHERE lastSeen < xyz

Bei jedem Login reicht längstens. Denn bei jedem Seiten-Refresh musst du eh prüfen, ob die aktuelle Session noch gültig ist. Da macht es nichts, wenn eine abgelaufen Session noch einige Minuten/Stunden in der DB bestehen bleibt.

[...]Was wäre Effektiver bzw schneller: 1 Unique oder 2 Unique?

Effektiv ist das falsche Wort. Effektiv ist es, wenn du die richtigen Ziele erreichts. Effizient ist, wenn du etwas mit optimalen Aufwand erreichts. Beispiel: Baum fällen. Mit etwas Sprengstoff bist du durchaus effektiv (der Baum ist weg). Eine Motorsäge ist jedoch durchaus effizienter als eine Axt.

Effektiv kann ein Unique-Index sein. Aber auch zwei, drei, fünf. Ob das dann effizient ist, ist eine andere Frage.

[hausl]

Effektiver bzw schneller

Wobei? SELECT, UPDATE, INSERT, DROP^^
Du weißt schon was der Sinn von UNIQUE ist?

http://phpperformance.de/indizes-richtig-einsetzen/

[Condor93]

Okay, dankeschön
Hab noch nie mit solchen Mengen gearbeitet, ich möchte aber für mein Projekt schonmal auf sowas vorbereitet sein, bevor ich später probleme bekommen.

Was wäre Effektiver bzw schneller: 1 Unique oder 2 Unique?

[hausl]

Würde das die DB nicht belasten

Dann mach es halt im Zuge eines Login-Vorganges. Und "viel" Daten ist immer relativ, DBs können ganz schön was vertragen, das ist deren Job

[tkausl]

Mit den richtigen Keys auf den richtigen Spalten lacht eine Datenbank über 100 Millionen Zeilen.

[Condor93]

Die User als "CronJob" zu benutzen ist auch ne gute Idee.
Würde das die DB nicht belasten wenn jedes mal eine Delete Anfrage kommt, wo er noch vergleichen muss?
Beim Beispiel mit 100 Millionen Datensätzen (<-- ein BEISPIEL, bitte auch als solches betrachten)

[tkausl]

Also per CronJobs dann

Brauchst du nichtmal. Einfach bei jedem Seitenaufruf als erstes

DELETE FROM sessions WHERE lastSeen < xyz

[Condor93]

Also per CronJobs dann, der jede Stunde bzw pro Tag die Tabelle reinigt, wenn SessionID's abgelaufen sind. Wenn der User sich selber ausloggt, wird diese Session in der Tabelle dann selbst gelöscht.

Wenn der User kein Häckchen bei "Eingeloggt bleiben" hat, wird bei jeder Aktion/Seiten abruf eine neuer Ablauftermin für die Session gebildet. Wenn er 2 Stunden zb nichts gemacht hat, wird dieser als Inaktiv makiert, Session wird in der Tabelle gelöscht und wird dann weitergeleitet zum Login Bereich.

Gibt es da jetzt noch i.welche Probleme, die auftreten könnten? Zum Beispiel, wenn CronJobs die Tabelle reinigt, das die DB dadurch langsamer wird.

[hausl]

Manuell, wenn diese zB schon mehr als x Stunden/Tage/Wochen alt ist. Auf Basis eines separatem Lauf oder im Zuge des LoginProcedere. Es gibt jedenfalls keine verlässliche "jetzt ist er weg" Methode, die du verwenden kannst, falls du sowas meinst.