Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] URL-abhängige sessions

Einklappen

Neue Werbung 2019

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

  • [Erledigt] URL-abhängige sessions

    Guten Abend zusammen,

    momentan stehe ich so ziemlich mit meinen sessions auf dem Schlauch. Folgendes Problem:
    Ein User postet im Forum einen Link zu einer internen Seite (z.B. http://www.xy.net). Der Link wird wunderbar erkannt, funktioniert auch, also alles einwandfrei. Postet der User den selben Link ohne das "www" (http://xy.net) wird die session auf einmal nicht mehr erkannt, also jeder ausgesperrt, der die URL aufruft.

    In der Server-Konfiguration habe ich schon herum gespielt deswegen und session.cookie-path anzupassen versucht. Laut session.set_cookie_params bedeutet ein Schrägstrich in der Konfi aber, dass alle Pfade der Domain gültig sind. So ist es auch in der Konfiguration notiert:

    Code:
    session.cookie_path = /
    Folglich muss ich irgendwo bei den sessions ziemlich geschlampt haben. Entsprechende Scripts habe ich eben zusammengefasst, falls jemand Zeit hat, mit den Augen da drüber zu fliegen.

    session anlegen beim Login:
    PHP-Code:
    //Check if user exists and account is valid
    $Username $_POST['Username'];
    $Password $_POST['Password'];
    $Password hash('sha512'$Password); //Encrypt password
    $Get_UserData mysql_query("SELECT `UID`, `Valid`, `Active`, `Group` FROM `users` WHERE `Username` = '$Username' AND `Password` = '$Password'");
    $UID_Fetch mysql_fetch_assoc($Get_UserData);
    $UID $UID_Fetch['UID'];

    ... 
    //Validate inserts, user data & agents, blocks, etc.

    //IF valid user, create session and load data
    mysql_query("INSERT INTO `sessions` (`SessionID`, `UID`, `IP`, `Status`, `Start_Timestamp`, `End_Timestamp`, `Last_Activity`, `Last_Activity_Timestamp`, `UAID`) VALUES (NULL, '$UID', '$IP', '0', '$Timestamp', '0', '0', '$Timestamp', '$Client_ID')");
    $Get_CMC_Count mysql_query("SELECT `Access_Count` FROM `user_agents` WHERE `UAID` = '$Client_ID' LIMIT 1");
    $CMC_Count mysql_fetch_assoc($Get_CMC_Count);
    $CMC_Count $CMC_Count['Access_Count'] + 1;
    mysql_query("UPDATE `user_agents` SET `Access_Count` = '$CMC_Count', `Screen` = '$New_Screen_Size' WHERE `UAID` = '$Client_ID' LIMIT 1");
    $Last_Activity 'ABORT';
    $CountSessionsNew $CountSessions 1;
    $_SESSION['Name'] = $Username;
    $_SESSION['ID'] = $CountSessionsNew;
    $User_Group $UID_Fetch['Group'];
    //Get user rights
    include('system/get_user_rights.inc.php');
    //Get additional login data
    $Get_Login_Requests mysql_query("SELECT * FROM `user_settings` WHERE `UID` = '$UID'");
    $Login_Requests mysql_fetch_assoc($Get_Login_Requests);
    $Area $Login_Requests['Login_Homepage'];
    if(empty(
    $Area)) {
        
    $Area 'Main_Title';
        }
    //Run through header queries again after login to fetch important user relevant data
    require('system/header.php'); 
    Aufruf der Sitzung / des Logins in der header.php:

    PHP-Code:
    //Check for active session
    $Username $_SESSION['Name'];
    $Get_UData mysql_query("SELECT `UID`, `Group` FROM `users` WHERE `Username` = '$Username' LIMIT 1");
    $Get_UData mysql_fetch_assoc($Get_UData);
    $UID $Get_UData['UID'];

    ...

    if(empty(
    $UID)) {//IF no data could be loaded from database
        
    $UID 0;
        
    $Username 'Besucher';
        }
    if(
    $UID != 0) {
        
    $Login TRUE;
        } 
    Irgendwo muss ich ja gepfuscht haben, wenn der Server auch nach apache2 restart die Cookies nur mit vorgestelltem "www" in der URL akzeptiert. Mir will aber partout nicht einfallen, wo das sein sollte. Über einen winzigen Hinweis wäre ich also dankbar. Sollte einer aus der Haut fahren aufgrund einer bösen Sicherheitslücke, darf er die auch gerne anprangern dass ich die weg machen kann.

    Liebe Grüße,
    Don

  • #2
    Ich vermute, dass die Session gelöscht wird, weil in dem Post vielleicht nicht die Session gestartet wird?
    Verbessere mich, falls ich falsch liege.

    Tipp:
    Standardtext für die Datenbankverbindung:
    Die mysql_* Erweiterung ist veraltet und wird in der nächsten PHP-Version entfernt. Zudem ist deine Query anfällig für SQL-Injections.
    Durch einen Wechsel auf mysqli_* oder PDO greifst du auf die modernere API zu und hast die Möglichkeiten Prepared Statements zu benutzen die gegen Injections wirken.
    Ich persönlich bevorzuge PDO, schönes Tutorial: http://www.peterkropff.de/site/php/pdo.htm

    MfG.
    Dir gefällt mein Beitrag, ich habe Dir geholfen?
    Bewerte mich doch einfach!

    Kommentar


    • #3
      Auf MySQLi wollte ich schon paar mal umsteigen. Aber jedes Mal war das Problem, dass entweder keine DB-Verbindung möglich war oder die hunderten Queries auf einmal alle fehlerhaft waren. Hatte noch keinen Nerv, mich mit dem Thema auseinander zu setzen. Wobei ich das wohl demnächst mal machen sollte, wenn das ansonsten tatsächlich Injection-anfällig wäre. Dann wäre ja Hopfen und Malz verloren, wenn da jemand alles verwüsten könnte, oder was noch viel schlimmer wäre, Nutzerdaten auslesen. Es sind zwar keine sensiblen Daten (Adressen, Finanzen, etc.) hinterlegt, aber täte man nichts dagegen, wäre das verantwortungslos ... Ich hab das halt nie studiert oder so und arbeite auch nicht beruflich damit, dass mein Chef mich regelmäßig auf entsprechende Schulungen schicken würde etc. Naja

      Zur Session:
      Bei jedem Seitenaufruf wird zuerst die header.php durchlaufen. Darin wird auch jedes Mal über session_start() die Sitzung aufgerufen. Ansonsten könnte man sich ja nichtmal durch den Login-Bereich durch klicken. Möglicherweise liegt hier aber trotzdem der Fehler begraben. Hab mir den Abschnitt nämlich grad eben nochmal angeschaut und festgestellt, dass ich so ziemlich Mist gebaut habe, was das angeht. So wird z.B. immer eine Sitzung gestartet (auch wenn kein Login vorhanden ist), außer beim Login-/Logoutvorgang. Das muss ich mir unbedingt nochmal anschauen.

      Kommentar


      • #4
        Auf MySQLi wollte ich schon paar mal umsteigen. Aber jedes Mal war das Problem, dass entweder keine DB-Verbindung möglich war oder die hunderten Queries auf einmal alle fehlerhaft waren. Hatte noch keinen Nerv, mich mit dem Thema auseinander zu setzen. Wobei ich das wohl demnächst mal machen sollte, wenn das ansonsten tatsächlich Injection-anfällig wäre. Dann wäre ja Hopfen und Malz verloren, wenn da jemand alles verwüsten könnte, oder was noch viel schlimmer wäre, Nutzerdaten auslesen. Es sind zwar keine sensiblen Daten (Adressen, Finanzen, etc.) hinterlegt, aber täte man nichts dagegen, wäre das verantwortungslos ... Ich hab das halt nie studiert oder so und arbeite auch nicht beruflich damit, dass mein Chef mich regelmäßig auf entsprechende Schulungen schicken würde etc. Naja
        PHP-Kenntnisse:
        Fortgeschritten
        ?? passt ja dann super. mysqli und kompliziert? prozedural ist es fast gleich.
        Current Projects: http://www.welten-buch.de, http://neu.zooadoo.de

        Kommentar


        • #5
          Cookies sind Domain abhängig. Wenn das Cookie in einer Subdomain gesetzt wird dann ist es auch nur in dieser (und deren Subdomains) gültig. Wenn du also das Cookie unter www.example.com setzt ist es nicht unter example.com gültig, wohingegen ein Cookie für example.com auch für www.example.com gültig ist. Also entweder gibst du die Domain für das Cookie entsprechend an oder besser noch, du entscheidest dich für eine Domain und leitest anfragen ggf. um.

          Umleiten mit der RewriteEngine von Apache (z.B. mittels .htaccess). Alles was nicht mit www. anfängt wird ein www. vorran gestellt.
          PHP-Code:
          RewriteEngine on

          RewriteCond 
          %{HTTP_HOST} !^www.example.com$
          RewriteRule ^(.*) http://www.example.com/$1 [L,R=301] 

          Kommentar


          • #6
            Zitat von Geromel Beitrag anzeigen
            ?? passt ja dann super. mysqli und kompliziert? prozedural ist es fast gleich.


            Schön. Ich hab mich nicht weiter damit beschäftigt und bin in den ersten Versuchen gescheitert. Ich hab PHP nie beigebracht bekommen, das kann man mir vorhalten. Angefangen zu programmieren habe ich jedenfalls vor 9 Jahren. Such dir also ein anderes Argument mich als Anfänger hinzustellen ...

            @erc: Es hat auch ohne RewriteEngine funktioniert. Hab mir vorhin noch die Finger wund gegooglet und eine Lösung gefunden.

            Der Code in der header.php sieht nun wie folgt aus:

            PHP-Code:
            if(isset($_COOKIE['PHPSESSID'])) {
                
            session_set_cookie_params(0'/''.url.net'FALSEFALSE);
                
            session_start();
                }
            ...
            //Irrelevant code
            if(isset($_SESSION['Username'])) {
                
            $Username $_SESSION['Username'];
                
            $Get_UData mysql_query("SELECT `UID`, `Group` FROM `users` WHERE `Username` = '$Username' LIMIT 1");
                
            $Get_UData mysql_fetch_assoc($Get_UData);
                
            $UID $Get_UData['UID'];
                ...
            //Load user settings
                
            $Login TRUE;
                }
            //IF session username is set End
            else {
                
            $Login FALSE;
                
            $UID 0;
                
            $Username 'Besucher';
                } 
            Was hat sich geändert?
            Zunächst mal wird die Sitzung nur noch aufgerufen, wenn entsprechendes Cookie existiert. Letzteres wird beim Erstaufruf der Sitzung während des Logins über das sekundäre Include-Script erstellt.

            Außerdem habe ich
            PHP-Code:
            session_set_cookie_params(0'/''.url.net'FALSEFALSE); 
            hinzugefügt. Das hat frustrierender Weise erst ewig nicht funktioniert, bis ich mal den kompletten Cache von Chromium gelöscht habe. Seither läuft alles einwandfrei. Man kann also von www.url.net zu url.net wechseln und anders herum.
            Insofern interessant, als ich auch eine Sprachauswahl über Subdomains geplant habe. Spätestens bei deren Umsetzung wäre es problematisch geworden. Theoretisch sollte aber auch ein Wechsel auf z.B. en.url.net jetzt problemlos möglich sein. Möglicherweise lässt sich das auch per php.ini umsetzen. Das schaue ich mir aber nochmal an.

            Trotzdem dankeschön an alle für die Hilfe.

            Kommentar


            • #7
              Trotzdem ist die umleitung ratsam, da google sonst wegen duplicate content rummotzt. So rein aus SEO-Perspektive.
              Current Projects: http://www.welten-buch.de, http://neu.zooadoo.de

              Kommentar


              • #8
                9 Jahre Programmiererfahrung und:

                - keine OO
                - kein Gedanke an Sicherheit
                - ignorieren von Deprecated-Angaben

                zusätzlich:
                - reininterpretieren von Sachen die nicht gesagt wurden

                Aber ich sage es jetzt, ob du es hören willst oder nicht:
                Du bist ein Anfänger. Nichts für ungut.

                Grüße
                Zitat von derwunner
                "Ein FISI ist auf gut-deutsch der Netzwerker. Das heißt Du gehst rauß zum Kunden oder auf die Straße und verlegst Leitungen" - derwunner 2015

                Kommentar

                Lädt...
                X