[PHP5] Anfängerfragen zu session's

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

  • [PHP5] Anfängerfragen zu session's

    Moin Leute

    Ich habe eine Frage, aber zuerst möchte ich rasch erklären was ich überhaupt machen mächte

    Ich habe vor, eine kleine Seite zu machen, auf welcher man sich einloggen kann um erweiterte Funktionen zu nutzen. Ich hab vor ner weile angefangen an dem Script zu basteln und es funzt soweit auch.
    Bisher erfolgt die Authentifizierung nur durch 2 Cookies. das eine ethält die Userid und das andere den Passwort-Hash. Somit mir am beginn des Scriptes jeweis eine SQL-Abfrage gemacht, welche Rechte der User hat und ob er aktiviert oder gebannt ist. Funzt eigentlich recht gut.
    Nun zu der Frage:
    Wäre die verwendung der Session-Funktion einfacher zu handhaben?
    Wäre die verwendung der Session-Funktion schneller?
    Kann ich bei der Session-Funktion frei wählen was übergeben wird?
    Kann ich änderungen der berechtigung machen während der User online ist? (er würde es dann beim nächsten aktualisieren der seite sehen)
    Greift der Bann per sofort wenn ich den User über den SQL-Eintrag banne und seine session-ID lösche?

    Viele Fragen ich weiss, aber für einen Pro sicher sehr schnell beantwortet.
    Ich muss gestehen, das ich mich mit der Session-Funktion noch überhaupt nicht auseinandergesetzt habe. Eigentlich sollte das script von nur einem oder zwei usern verwendet werden um eine gallerie zu verwalten.
    Nun möchte ich das ganze aber auch in einem grösseren Projekt verwenden das deutlich mehr User hat.

    Bei Fragen Fragen. Achja: eingesetzt wird apache, php5 und sql5 (jeweils aktuelle versionen )

    lg aXu

  • #2
    Hey,
    also..zu deiner Frage, ob Sessions besser zu handhaben sind... die Antwort lautet eher ... jain... einfacher zu handlen find ich sie persönlich schon, allerdings musst du iwie sicher stellen, dass die Session nicht geklaut wurde, leider verändern einige ISP's wie etwa AOL, die IP-Adresse und auch den User-Agent während der Sitzung, also dürfte es nahezu unmöglich sein, die Session an eine IP oder an den Browser zu binden, insofern sind Cookies schon besser...
    Also ich speichere das Passwort überhaupt nicht im Cookie, bei mir gibts nur die verschlüsselte User-ID...den Rest erledige ich immer über das Datenbank-Backend.. So musst du halt nur eine User-Variable überprüfen...die restlichen Informationen rufst du dann über die User-ID aus der Datenbank ab.

    Wenn der Bann sofort greifen soll, fällt mir spontan ein, dass du eine Datenbank-Spalte mit 'user_logged', benennst, da speicherst du einen bool'schen Wert, also entweder 'true' wenn der User online ist oder 'false' wenn er nicht angemeldet ist, wenn du einen User dann schmeissen möchtest, setzt du z.b. per Formular den Wert auf false, lässt dann beim ziehen der User-Informationen aus der Datenbank das ganze über
    PHP-Code:
    SELECT FROM user WHERE user_id '$user_id' AND logged 'true' 
    bestimmen...
    Dann setzt du halt die Cookie-Verfallszeit auf, als Beispiel, eine Stunde in der Vergangenheit und Ende...
    Dürfte eigentlich kein sooo schlechter Ansatz sein...
    Hoffe, du kannst damit was anfangen..
    OffTopic:
    Gute Nacht

    Grüße, Dennis
    Musik beflügelt unseren Geist

    Kommentar


    • #3
      das würde dann heissen, ich soll so weitermachen wie bisher?

      wenn du nur das pw speicherst, ist das nicht etwas "heiss"?
      okay, da wäre die möglichkeit einen Algorithmus zu entwerfen.. Aber das würde dann heissen, das wirklich bei jedem seitenaufruf das ganze geprüft wird. dachte das könnte ich per session verhindern...

      Kommentar


      • #4
        Ich persönlich nutze lieber sessions - ma so nebenbei bemerkt - okay cookies sind toll, allerdings speichere ich bsp die Userdaten in ner session mit nem individuellen string ;-)
        Signatur-Text ...

        Kommentar


        • #5
          Daten, denen du vertrauen willst, gehören Serverseitig gespeichert, also in die Session damit!
          Da immer noch ein paar Leutchens ohne Cookies durch die Welt wandern, brauchst du bei deiner Lösung auch einen Workaround, um die Userid und den PW-Hash per GET oder sonstwie weiterzugeben. Das ist in der Session schon komplett implementiert (wenn du das Rewriting aktiv hast, sonst SID an die Links ankleben).
          Auf solche Cookielösungen würde ich generell verzichten und die Session nutzen! Spätestens, wenn du auch mal mehr, als nur eine ID irgendwo speichern willst, musst du dir wieder ein neues Cookie anlegen, die Datenbank nutzen oder whatever!

          Grundlagen lernen, Session einsetzen!

          Kommentar


          • #6
            und was ist mit dem einwand:
            einfacher zu handlen find ich sie persönlich schon, allerdings musst du iwie sicher stellen, dass die Session nicht geklaut wurde, leider verändern einige ISP's wie etwa AOL, die IP-Adresse und auch den User-Agent während der Sitzung, also dürfte es nahezu unmöglich sein, die Session an eine IP oder an den Browser zu binden, insofern sind Cookies schon besser...

            Kommentar


            • #7
              Wenn du jetzt eine Session verwendest und der User keine Cookies akzeptiert, wird die SID in der URL übergeben. Wenn du jetzt jemandem diese URL schickst und der sie verwendet, solange du zum Beispiel noch angemeldet bist, kann der andere User deinen Login verwenden, da er deine SID kennt.
              Das gleiche geht aber auch, wenn dein "böser" Freund dir deine Cookies ansieht, beispielsweise mit der Webdeveloper Toolbar. Dann kann er dir auch deine User-ID mopsen. (Szenario: Internetcafé)
              Als Pseudoschutz vor diesem Diebstahl merken sich viele die IP des Users in der Session. Ändert sich diese, wird die Session geleert, keiner kann deinen Login klauen. Da manche Anbieter, zum Beispiel AOL, aber mal "einfach so" deine IP ändern, während du am Surfen bist, ist dies natürlich eher hinderlich, da das System denkt, du klaust die Session!
              Aber bei deinem Session-Mini-Nachbau (nichts anderes ist deine Cookielösung) existiert genau das selbe Problem!
              Nutz die Session und überleg dir lieber andere Schutzmechanismen. Ich persönlich habe aber noch nie die Erfahrung gemacht, das jemand eine Session übernimmt. Viel wichtiger ist das vernünftige Behandeln von SQL-Injections und anderen, viel größeren Sicherheitslücken!

              Kommentar


              • #8
                hm.. okey, werde dann mal in der literatur zum thema session nachschlagen.

                wegen den eingaben: ich verwende standardmässig stripslashes(htmlentities()) auf jegliche eingaben. dazu werden keine undefinierten variablen verwendet und ich versuchte möglichst alles safe_mod kompatibel zu coden. denke ich bin da auf einem guten weg oder?

                //edit

                wenn die unterlagen stimmen, dann kann der User die Daten in der Session in keinem fall verändern?
                Zuletzt geändert von aXu; 07.11.2007, 10:41.

                Kommentar


                • #9
                  wegen den eingaben: ich verwende standardmässig stripslashes(htmlentities()) auf jegliche eingaben.
                  Dazu gibt es die Escape-Funktionen, z.B. mysql_real_escape_string.
                  dazu werden keine undefinierten variablen verwendet
                  Sowieso immer Pflicht!
                  und ich versuchte möglichst alles safe_mod kompatibel zu coden.
                  Diese Orientierung kann imho zu einem besseren Programmierstil verhelfen!
                  wenn die unterlagen stimmen, dann kann der User die Daten in der Session in keinem fall verändern?
                  Richtig!

                  Kommentar


                  • #10
                    und ich versuchte möglichst alles safe_mod kompatibel zu coden.
                    Naja....
                    Eine der dümmsten Erfindungen der PHP Entwickler.. und wird zum Glück mit magic_quotes in PHP6 abgeschafft.
                    Wir werden alle sterben

                    Kommentar


                    • #11
                      Naja....
                      Eine der dümmsten Erfindungen der PHP Entwickler.. und wird zum Glück mit magic_quotes in PHP6 abgeschafft.
                      In Version 6 verliert PHP zum Glück einige Kinderkrankheiten!
                      Aber als Orientierung finde ich safe_mode ok, also vernünftige Dateizugriffe etc.

                      Kommentar


                      • #12
                        also vernünftige Dateizugriffe etc.
                        Klar!! ??? !!

                        Verzeichnisse und Dateien IMMER mit den FTP-Funktionen erzeugen, damit man sie mit den PHP-Filesystemfunktionen dann wieder lesen kann
                        sehr witzig

                        Sorry, für den Sarkasmus, aber der Safemode hat mich schon öfter Wahnsinnig gemacht. Auf meinem Server lief auch ursprünglich PHP als Modul im Safemode. Habe ich mittlerweile umgestellt. suPHP ist für mich das Mittel der Wahl.
                        • das Linux Rechtesystem greift
                        • kein Basedir notwendig
                        • z.Z. 5 verschiedene PHP Versionen installiert(auch PHP6)
                        • leider deutlich lahmer !!!!!
                        Zuletzt geändert von combie; 07.11.2007, 13:03.
                        Wir werden alle sterben

                        Kommentar


                        • #13
                          Hmm, ich habe mir safemode grad nochmal angesehen und ich muss mich korrigieren. Ist natürlich Unsinn! Darum: Was heißt denn "und ich versuchte möglichst alles safe_mod kompatibel zu coden"??

                          Kommentar


                          • #14
                            okay, ist relativ einfach. ich teste und entwickle mein tool im safe_mod. egal ob danach auf dem zielsystem der safe_mod aktiv ist oder nicht. oder mach ich da einen überlegungsfehler?

                            Kommentar


                            • #15
                              Hmmm...
                              Ich schreibe grundsätzlich nicht für den Safemode!! Wenn es dann wirklich unbedingt gewünscht wird, gibts Spezialanpassungen. Aber es ist längst nicht alles machbar!!
                              Wir werden alle sterben

                              Kommentar

                              Lädt...
                              X