Ankündigung

Einklappen
Keine Ankündigung bisher.

User wiedererkennen

Einklappen

Neue Werbung 2019

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

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

  • #2
    Um den Nutzer eindeutig zu identifizieren, wäre doch die User-ID oder der Username ganz praktisch?
    [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

    Kommentar


    • #3
      Theoretisch egal was im Cookie steht. Wenn das Cookie existiert, ist man eingeloggt.

      Ich würde dort jedoch mindestens die user_id und einen hash integrieren. Ggf. noch weitere Information.

      Session Cookie käme auch in Frage.

      Kommentar


      • #4
        Zitat von smilla Beitrag anzeigen
        Theoretisch egal was im Cookie steht. Wenn das Cookie existiert, ist man eingeloggt.
        Ob man "eingeloggt" ist oder nicht legt in erster Linie die Anwendung fest. Das hat auch nichts mit dem Cookie zu tun. Das Cookie übermittelt nur die notwendigen Informationen um dies festzustellen.
        [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

        Kommentar


        • #5
          user_id und einen hash
          Dazu das am ehesten, gibt mehr Varianten. Aber bitte nicht die Zugangsdaten, auch nicht gehasht.

          Session Cookie käme auch in Frage.
          Du meinst das PHP autom. für die Session erstellt? Nein, wenn du den Browser zumachst ist das weg.
          The string "()()" is not palindrom but the String "())(" is.

          Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
          PHP.de Wissenssammlung | Kein Support per PN

          Kommentar


          • #6
            Ich würde das so machen:

            Prüfe ob Cookie existiert. Wenn ja, prüfe den User Hash-ID mit der Datenbank. Wenn das wiederum existiert, sollen Werte von der DB per Session weiter gegeben werden.

            Meine Sorge ist nur, das jeder die Cookies ändern kann. Ein User kann die Datei ändern und ist dann wahrscheinlich mit einen ganz anderen Account drin. Wie umgehe ich dieses Problem?

            Kommentar


            • #7
              Wie umgehe ich dieses Problem?
              User-ID und individuellen Hash je User in der DB speichern und die Kombination muss auch im Cookie passen. Bei jedem explizitem Login (also keinem Auto-Login) einen neuen Hash für diesen User erstellen (der dann ins Cookie kommt). Und bei einem Logout ("klick") Cookie und Hash löschen.

              Hat auch den Vorteil wenn du den Hash eines Users in der DB löscht, ist der user überall abgemeldet, ich denke mal Facebook wird es mit der Option "Mich auf allen Geräten abmelden" auch irgendwie im Grunde so machen, auch wenn das jetzt einfach mal eine Mutmaßung ist
              The string "()()" is not palindrom but the String "())(" is.

              Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
              PHP.de Wissenssammlung | Kein Support per PN

              Kommentar


              • #8
                Sprich:

                Datenbanktabelle mit den Spalten (Login)
                User_hash | Login_hash

                Dann müsste ich bei jeder Seite prüfen, ob die Werte übereinstimmen, richtig?


                Dann würde ich das jetzt so machen:
                User Loggt sich ein, (ohne Häckchen bei Eingeloggt bleiben), Daten werden mit DB geprüft und ein Datensatz wird in der Tabelle (Login) erstellt. Login Werte werden dann in der Session gespeichert. Solange die Session die Zeitspanne nicht überschreitet bleibt alles so, wenn nicht wird Session gelöscht, der Datensatz (Login) wird auch gelöscht und es geht per header wieder an die Startseite.

                User Loggt sich ein (mit Eingeloggt bleiben), Daten werden mit DB geprüft und ein Datensatz wird in die Tabelle (login) erstellt. Dazu werden die Werte vom Datensatz auch in einen Cookie gespeichert. Daten werden zudem in die Session gespeichert, dabei wird die Lebensdauer der Session auf maximal 1 Woche gesetzt. Und dann das prozedere wie oben.
                Beim schließen des Browsers und wieder aufmachen, wird geguckt ob Cookie gesetzt ist. Wenn ja soll er diese Werte mit der DB-Login, wenn korrekt, holt er Daten von User und so weiter...

                Kommentar


                • #9
                  wird die Lebensdauer der Session auf maximal 1 Woche gesetzt
                  Warum die Session 1 Woche. Du meinst das Cookie (Auto-Login) soll eine Woche lang aufrecht beliben? Nicht die PHP-Sesision mit dem Cookie verwechseln.

                  Die PHP-Session brauchst du so und so, dadurch bist du ja eingeloggt.
                  Und entweder an Hand eines "normalen" Login oder an Hand eines vorhandenen gültigen Cookies (das wiederrum durch ein erfolgreichces Login mit "Remember-Me-Haken" erstellt wird) wirst du verifiziert und dadurch eben die PHP-Session erstellt.

                  Schau mal im Web dazu gibts haufenweise Lesestoff, twl. sogar mit fertigen Beispielen, gibts auch fertiges Zeugs dazu.
                  The string "()()" is not palindrom but the String "())(" is.

                  Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
                  PHP.de Wissenssammlung | Kein Support per PN

                  Kommentar


                  • #10
                    Stimmt, verwechselt mit Cookie
                    Naja danke für die Hilfe, Thema wäre hiermit nun erledigt

                    Kommentar


                    • #11
                      Hab nochmal ne Frage. Wenn der User den Browser schließt, bekommt er ja eine neue SessionID, wenn er diese wieder öffnet.
                      Wie kann ich die alte SessionID in der DB löschen?

                      Kommentar


                      • #12
                        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.
                        The string "()()" is not palindrom but the String "())(" is.

                        Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
                        PHP.de Wissenssammlung | Kein Support per PN

                        Kommentar


                        • #13
                          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.

                          Kommentar


                          • #14
                            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
                            [QUOTE=nikosch]Macht doch alle was Ihr wollt mit Eurem Billigscheiß. Von mir aus sollen alle Eure Server abrauchen.[/QUOTE]

                            Kommentar


                            • #15
                              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)

                              Kommentar

                              Lädt...
                              X