Ankündigung

Einklappen
Keine Ankündigung bisher.

User wiedererkennen

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Condor93
    hat ein Thema erstellt User wiedererkennen.

    User wiedererkennen

    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
    antwortet
    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?

    Einen Kommentar schreiben:


  • VPh
    antwortet
    Zitat von Sakron Beitrag anzeigen
    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.

    Einen Kommentar schreiben:


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

    Einen Kommentar schreiben:


  • Sakron
    antwortet
    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

    Einen Kommentar schreiben:


  • Condor93
    antwortet
    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.

    Einen Kommentar schreiben:


  • ChristianK
    antwortet
    Zitat von tkausl Beitrag anzeigen
    Brauchst du nichtmal. Einfach bei jedem Seitenaufruf als erstes
    Code:
    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.

    Zitat von Condor93 Beitrag anzeigen
    [...]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.

    Einen Kommentar schreiben:


  • hausl
    antwortet
    Effektiver bzw schneller
    Wobei? SELECT, UPDATE, INSERT, DROP^^
    Du weißt schon was der Sinn von UNIQUE ist?

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

    Einen Kommentar schreiben:


  • Condor93
    antwortet
    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?

    Einen Kommentar schreiben:


  • hausl
    antwortet
    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

    Einen Kommentar schreiben:


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

    Einen Kommentar schreiben:


  • Condor93
    antwortet
    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)

    Einen Kommentar schreiben:


  • tkausl
    antwortet
    Zitat von Condor93 Beitrag anzeigen
    Also per CronJobs dann
    Brauchst du nichtmal. Einfach bei jedem Seitenaufruf als erstes
    Code:
    DELETE FROM sessions WHERE lastSeen < xyz

    Einen Kommentar schreiben:


  • Condor93
    antwortet
    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.

    Einen Kommentar schreiben:


  • hausl
    antwortet
    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.

    Einen Kommentar schreiben:

Lädt...
X