PHP Sessions in Mysql Datenbank speichern | PHP Tutorial

Поділитися
Вставка
  • Опубліковано 9 лис 2024

КОМЕНТАРІ • 31

  • @VitalijMik
    @VitalijMik  4 роки тому +3

    Kanntest du den SessionHandlerInterface?

  • @tillha9538
    @tillha9538 2 роки тому +1

    Sehr interessantes Thema. Danke Dir. Und btw auch noch amüsant @ „packe meine Paint Skills aus“ 😂

  • @WaldemarDellgg
    @WaldemarDellgg 4 роки тому +1

    Nettes Video. Ja ich nutze es mit ebenfalls Redis, weil ich das transparenter finde und letztendlich schon einmal für loadbalancing gerüstet zu sein

  • @sven2529
    @sven2529 3 роки тому +1

    Sehr gutes Video. Vielen Dank dafür. Ich fand die Erklärung in Kombination mit Paint seht gut. Das hat mir sehr geholfen es mir besser vorstellen zu können.

    • @VitalijMik
      @VitalijMik  3 роки тому +1

      Ja bei Datenbanken kann man ja ein einfaches ERD Diagramm verwenden ;) es ist ja nicht so dass ich es nicht versuche. Nur klappt das dann nicht bei jedem Thema

  • @Chaos3ngel
    @Chaos3ngel 3 роки тому +2

    Vitalij als erstes möchte ich dir sagen, dass ich dich mega sympathisch finde. Deine professionelle Wortwahl zusammen mit deinem Dialekt ist einfach episch. Zum Thema der sessions: global aktive session vs temporär aktive Session, also session_start() am seitenbeginn oder start/close nur wenn man auf die Session zugreifen will?

    • @VitalijMik
      @VitalijMik  3 роки тому +2

      Hey vielen dank.
      Also ich nutze ja meistens ein Framework, zum Beispiel Symfony und da wird es in der Tat so umgesetzt dass der session_start nur dann ausgeführt wird, sobald ich auf die Session zugreife. Allerdings wäre es auch sehr aufwendig umzusetzen und würde dir ohne einen Framework nicht wirklich viel bringen.
      Was ich also mache wenn ich ein Projekt habe ohne Framework, dann ist es eh meistens klein und dann starte die Session direkt.
      Wenn du ein Framework verwendest, dann brauchst du es nicht zu tun weil es ja automatisch passiert sobald du auf die Session zugreifst.
      session_write_close() rufe ich zb nie auf weil es eh für den Prozess nach der Verarbeitung geschlossen wird

    • @Chaos3ngel
      @Chaos3ngel 3 роки тому +1

      @@VitalijMik von Herzen dank für deine Antwort. Ich selber habe bisher noch garnicht mit frameworks gearbeitet, finde mich quasi noch in den neueren php7 Stil ein, und trotz all der Vorzüge, mag ich diese composer und cmd Geschichten nicht dabei. Ich schreibe also eher vieles selbst, einfach weil ich quasi nen fertiges Paket ins htdocs Verzeichnis des Server laden möchte (zumeist per sftp) und das direkt nutzen können, ohne zuvor composer zu installieren und alles mögliche zu konfigurieren etc. Naja gut vllt verstehe ich da an dem Prinzip mit composer auch einfach was falsch, denn diese utilities sehen schon cool aus. Ich hatte tatsächlich mal ein lokales Projekt geschrieben, das wiederholende Aufgaben ausführte und mittels progressbar anzeigte. Und dort war die offene globale Session tatsächlich ein Problem, da der Ajax request für die Aktualisierungsschleife nicht lief. Eigentlich sinds ja nur nen paar Zeilen Code für ne Handvoll wrapper Funktionen ums session handling. Vermutlich ist meine Methode dahingehend eh veraltet und man könnte es eleganter lösen, bin auf Inspiration gespannt ^^ apropos, was mir immer problematisch war, chron Jobs rein php seitig lösen und auch ohne seitenaufruf relativ pünktlich ausführen.

    • @VitalijMik
      @VitalijMik  3 роки тому

      Ja composer Dateien via SFTP hochladen ist tatsächlich schwierig. Es ist eher dazu ausgelegt dass du dich via SSH auf dem Server einloggst und dann automatisiert über die Kommandozeile dein Quellcode ausrollst und composer installierst. Vielleicht mach ich dazu noch Video. Man macht das um seine Zugangsdaten nicht weiter zu geben und um zu skalieren falls man weitere Server dazuschaltet. Wegen Ajax usw kann ich dazu nichts sagen, eventuell müsste man das debuggen, mir kommt es auf jeden Fall komisch vor :D und wegen cron? was meinst du mit Pünktlich? ein Cron wird jede Minute gestartet, wenn es öfters passieren soll brauchst du ein deamon

    • @Chaos3ngel
      @Chaos3ngel 3 роки тому +1

      @@VitalijMik aus deiner Antwort folgere ich, dass es eine automatisierte Möglichkeit gibt. Und ich hatte mir schon ausgemalt mittels geplante task ne batch file auszuführen, die widerum einen php script lokal durch den Parser schickt, um die Jobs abzuarbeiten xD ich bin wohl schon viel zu lange raus was das coden angeht ^_^

    • @VitalijMik
      @VitalijMik  3 роки тому

      korrekt es gibt ein script das kannst du lokal ausführen und es verteilt dein code, ihc mach dazu noch ein tutorial ;)

  • @heinrichschiller4673
    @heinrichschiller4673 4 роки тому +2

    Top!

  • @JoPhiGURU
    @JoPhiGURU 3 роки тому +1

    Könnte man hier bei den SQL-Statements nicht noch (außer beim GC) ein LIMIT 1 anführen? Jede Session ist ja nur einmal da, und bei Projekten, die das tatsächlich brauchen könnte man dadurch bestimmt noch einiges an Laufzeit einsparen.

    • @VitalijMik
      @VitalijMik  3 роки тому

      Kann sein, aber es macht ja sowieso nicht viel Sinn eine Session in der Datenbank zu speichern, eine NoSQL Datenbank wie Redis wäre dafür besser geeignet

    • @AuftragschilIer
      @AuftragschilIer Рік тому

      LIMIT verringert überhaupt nichts an der Laufzeit des Querys. Es limitiert nur die Ausgabe, nicht die Rows die der Query durchläuft. Bei Unique Values macht es noch weniger Sinn, außer halt als Sicherheit dass halt wirklich nur eine Zeile zurück kommt. LIMIT, GROUP BY usw. ist "nur" eine nachträgliche Aufbereitung der Rohdaten, also sogar tendenziell langsamer (vor allem GROUP BY). Man kann LIMIT auch einsetzen um Daten zu überspringen, auch das deutet daraufhin. Das kannst du gut herausfinden wenn du mal EXPLAIN vor einen Query setzt, der Row-Count ist der gleiche. Dein Anwendung wird vielleicht langsamer mit zu vielen Daten, aber das ist eine andere Geschichte.
      Es ist nicht immer die Datenbank schuld... hört man als Entwickler halt nicht gern ;)

  • @AdrianKnauff
    @AdrianKnauff 2 роки тому +1

    Wann genau sollte session_regenerate_id aufgerufen werden?

    • @VitalijMik
      @VitalijMik  2 роки тому +1

      Beim logout wäre es am besten. Da wo man die Session Daten leeren will

  • @darkempire5762
    @darkempire5762 4 роки тому +1

    Muss man was beim erstellen einer login Session beachten ?
    Ich meine sich z:b gegen Sessionhijacking schützen.

    • @VitalijMik
      @VitalijMik  4 роки тому +1

      naja die session_id nicht mit der Zeit allein generieren so wie ich es im video gemacht habe. Session Hijacking ist ja einfach nur erraten nach welchen Muster die ID erzeugt wurde und dann eine bereits vergebene ID herausfinden. Wenn man nur nach Zeit geht, ist es dann relativ einfach, besonders wenn man viele aktive User hat. Benutze einfach einen komplexere Methoden. Session Hijacking wird auch meiner Meinung nach nicht mehr oft in PHP ausgenutzt, das war eher früher so als Register Globals aktiviert waren und wo es noch üblich war die session ID über die URL zu übergeben, das macht heut zu Tage niemand mehr

    • @darkempire5762
      @darkempire5762 4 роки тому

      @@VitalijMik danke

    • @badpussycat
      @badpussycat 3 роки тому

      die offizielle Empfehlung ist direkt nach dem Login session_regenerate_id() aufzurufen damit ein eventueller Angreifer der es irgendwie geschafft hat eine session zu übernehmen (vielleicht über ein ungesichertes WLAN auf nicht SSL-Verbindung unterwegs gewesen?) nicht auch noch eine authentisierte Session hat. aber heutzutage ist ja SSL eh überall vorgeschrieben und dein session cookie sollte ssl only sein

  • @ytBlar2
    @ytBlar2 4 роки тому +2

    Verwende nicht nicht microtime(), da damit einfach die Session-Ids durchgetestet werden können (noch einfach wenn das letzte Login des Benutzers auf der Seite angezeigt wird), sondern z.B. uniqid($_SERVER['HTTP_X_FORWARDED_FOR'] ?? $_SERVER['REMOTE_ADDR'], true) oder lass den eigenen Generator lieber gleich weg.

    • @VitalijMik
      @VitalijMik  4 роки тому +1

      Hast Recht. Es ging doch nur darum auf die schnelle die Session ID zu generieren. Ich glaube allein nur dafür könnte man ein eigenständiges Video machen

    • @olis936
      @olis936 4 роки тому

      Na dann los... 😊😊😊

    • @sarahsaenz7867
      @sarahsaenz7867 4 роки тому

      Das wollte ich auch schon anmerken. Aber man könnte m. E. auch eine UUID generieren, das wäre unabhängig von REMOTE_ADDR (auch erratbar im worstcase) und microtime. Eine Session-ID könnte m. E. auch länger als 30 Zeichen sein, warum nicht 255?

    • @VitalijMik
      @VitalijMik  4 роки тому

      @@sarahsaenz7867 weil es bei dem video darum ging wie man das session interface impementiert und der Tatsache dass überhaupt so etwas exestiert, ob die session ID jetzt 30 zeichen lang ist oder nicht, kann doch jedem überlassen werden. Die länge war auf 32 eingestellt weil ich ja md5 genutz habe und der wird nicht länger als 32 Zeichen

  • @ThomasWackerOlpe
    @ThomasWackerOlpe 4 роки тому +2

    Besser und schneller wäre redis...

    • @VitalijMik
      @VitalijMik  4 роки тому

      Habe ich im Video auch so gesagt ;) ich wollte jetzt nicht extra noch ein Redis Server aufsetzen, die jenigen die Redis kennen, für den ist es eh ein altes Hut