Ankündigung

Einklappen
Keine Ankündigung bisher.

Objekte und Sessions

Einklappen

Neue Werbung 2019

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

  • Objekte und Sessions

    Hallo zusammen,

    ich hab nen Problem mit der Serialisierung von Objekten in eine Session. Aber nun erstmal grundlegendes zum Verständnis.

    Ich habe eine Startseite (index.php) diese instantiiert meinen Dispatcher (Dispatcher.class.php). Im Dispatcher werden die Requests (POST/GET) zusammengeführt und gleichermaßen behandelt. Wenn jetzt z.B. die Variable "page" den Wert "login" enthält (egal ob POST/GET) dann wird ein SecurityManager instantiiert (SecurityManager.class.php) der eine Methode (login($username, $password)) beinhaltet. Der SecurityManager beinhaltet zusätzlich Benutzername, BenutzerID, Rechte usw. daher muss ich den SecurityManager via Sessions immer im Zugriff haben.

    Jetzt kommt genau das Problem.

    Nach der Instantiierung wird der SecurityManager in ne Session geschoben.

    Code:
    $_SESSION['securityManager'] = new SecurityManager();
    Ab diesem Zeitpunkt arbeite ich nur noch mit der Session. Also auch der Login, welcher das Objekt wieder manipuliert (Benutzername usw.)

    Der erste Zugriff auf das Objekt via Session klappt problemlos. Das heißt wenn ich nach Instantiierung direkt auf das Objek zugreife bekomme ich ne Ausgabe. Lade ich z.B. die Seite neu, bekomme ich keine Ausgabe - Hier ist das Problem.

    Ich bekomme einfach keine Ausgabe nachdem irgendwas passiert (Request o.Ä.) ist.

    Selbstverständlich habe ich im Dispatcher und auch in der index File jeweils den include des SecurityManagers vor dem session_start() gemacht.

    Hoffe ich könnt mir helfen - es ist echt wichtig ...

    Danke im Vorraus.

    Gruß Sven

  • #2
    Von was für einer Ausgabe redest du? Wird garnichts mehr ausgegeben (Fatal Error) oder erwartest du eine bestimmte Ausgabe die nicht kommt? Wenn ja welche und wie sieht der entsprechende Code aus?

    Hast du irgendwelche nicht serialisierbaren Dinge in der Klasse (DB-Verbindungen, Handler, ...) um die du dich nicht kümmerst?
    [URL="https://www.quizshow.io/"]Create your own quiz show.[/URL]

    Kommentar


    • #3
      Hallo,

      erstmal Danke für die Antwort.

      Zitat von agrajag Beitrag anzeigen
      Von was für einer Ausgabe redest du? Wird garnichts mehr ausgegeben (Fatal Error) oder erwartest du eine bestimmte Ausgabe die nicht kommt? Wenn ja welche und wie sieht der entsprechende Code aus?
      Ich habe mal den Sourcecode der relevanten Teile dabei gepackt.

      Code:
      <?php
      
      <?php
      // index.php
      
      @include ("SecurityManager.class.php");
      @include ("Dispatcher.class.php");
      @session_start();
      
      if(isset($_SESSION['securityManager']))
      {
      	print_r($_SESSION['securityManager']);
      }
      
      $request = array();
      $request = @array_merge($_POST, $_GET);
      
      $dispatcher = null;
      $dispatcher = new Dispatcher();
      $dispatcher->init();
      $dispatcher->setRequest($request);
      $dispatcher->handleRequest();
      
      echo $dispatcher->getResponse();
      
      ?>
      
      <?php
      
      // Dispatcher.class.php
      
      @include ("SecurityManager.class.php");
      @session_start();
      
      class Dispatcher
      {
      
      	private $request = null;
      	private $response = null;
      
      	public function init()
      	{
      		if(!isset($_SESSION['securityManager']))
      		{
      			$_SESSION['securityManager'] = new SecurityManager();
      		}
      	}
      	
      	public function handleRequest()
      	{
      		$this->response = $_SESSION['securityManager']->getUsername();
      	}
      	
      	public function setRequest($request)
      	{
      		$this->request = $request;
      	}
      	
      	public function getResponse()
      	{
      		return $this->response;
      	}
      }
      
      ?>
      
      <?php
      
      // SecurityManager.class.php
      
      class SecurityManager
      {
      	
      	private $username = null;	
      	
      	public function login($username, $password)
      	{
      		$isLoggedIn = false;
      		
      		$this->username = $username;
      				
      		return $isLoggedIn;
      	}
      	
      	public function getUsername()
      	{
      		return $this->username;
      	}	
      }
      ?>
      
      ?>
      Nach dem ersten Aufruf ist alles i.O. er gibt mir den übergebenen Username aus. Wenn ich dann allerdings die Seite neu lade existiert die Ausgabe des Benutzernames nicht mehr und auch die Sessionausgabe des SecurityManagers ändert sich nicht.

      Zitat von agrajag Beitrag anzeigen
      Hast du irgendwelche nicht serialisierbaren Dinge in der Klasse (DB-Verbindungen, Handler, ...) um die du dich nicht kümmerst?
      Nein, so wie es oben gezeigt ist wird es aktzuell verwendet.

      Gruß Sven

      Kommentar


      • #4
        Versuch mal anstatt:
        PHP-Code:
        print_r($_SESSION['securityManager']); 
        das hier:
        PHP-Code:
        var_dump($_SESSION['securityManager']); 
        Ob dein Securitymanager überhaupt ein passendes Objekt ist oder nur ein "datenobjekt"
        [URL="http://www.robo47.net"]robo47.net[/URL] - Blog, Codeschnipsel und mehr
        | :arrow: [URL="http://www.robo47.net/blog/192-Caching-Libraries-and-Opcode-Caches-in-php-An-Overview"]Caching-Klassen und Opcode Caches in php[/URL] | :arrow: [URL="http://www.robo47.net/components"]Robo47 Components - PHP Library extending Zend Framework[/URL]

        Kommentar


        • #5
          Hallo,

          als Ausgabe bekomme ich folgendes.

          Code:
          array(1) { ["securityManager"]=>  object(SecurityManager)#1 (1) { ["username:private"]=>  string(7) "default"} }
          Damit wäre es doch ein eindeutiges Objekt und kein Datenobjekt oder?

          Gruß Sven

          Kommentar


          • #6
            Mag zwar nicht die Lösung sein, aber warum doppelst Du die Aufrufe von session_start () und bindest aus Dispatcher.class.php erneut securityManager ein? Das gibt doch Streß. Und (oder gerade deshalb?) warum blockst Du alle Fehler mit @?
            [COLOR="#F5F5FF"]--[/COLOR]
            [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
            „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
            [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
            [COLOR="#F5F5FF"]
            --[/COLOR]

            Kommentar


            • #7
              kein gutes konzept

              SecurityManager... wow - klingt super.

              Zitat von boehseronkel Beitrag anzeigen
              Im Dispatcher werden die Requests (POST/GET) zusammengeführt und gleichermaßen behandelt.
              das solltest du dringendst überdenken. $_GET und $_POST sind nunmal nicht dasselbe. wer die beiden zusammenschmeisst - das trifft auf die verwendung des unseeligen $_REQUEST ebenso zu - handelt sich potenzielle gefahren für die sicherheit der anwendung ein. bspw. das hier:

              Suspekt… � Blog Archive � PHP 5.3 and Delayed Cross Site Request Forgeries/Hijacking

              darüber hinaus deutet es auf einen unsauberen / schlampigen programmierstil hin.

              weiter im text: was versprichst du dir von der exzessiven verwendung des @-operators? wäre gar nicht verkehrt, sich für die php-fehlermeldungen zu interessieren. wenn du meinst, dass der code ohne die dinger nicht auskommt, musst du ihn umstricken. wenn du behauptest, dass es anders nicht machbar ist:

              PHP Einsteiger - php.de

              cx

              Kommentar


              • #8
                Hi Cortex,
                kannst du mal bitte näher erklären, warum ein Zusammenlegen von GET und POST ein Sicherheitsrisiko ist? In dem Artikel, den du verlinkst wird das auch nicht behauptet oder belegt - lediglich wenn auch noch $_COOKIE (wie bei $_REQUEST) hinzukommt gibt es eine potentielle Gefahr.
                Prüfen ob es ein GET oder POST Request ist kann er auch mit $request->isPost() oder ähnlichem. Und CSRF ist so oder so möglich wenn man nichts weiteres dagegen unternimmt.
                Überseh ich was?
                [URL="https://www.quizshow.io/"]Create your own quiz show.[/URL]

                Kommentar


                • #9
                  Hallo zusammen,

                  danke für die Hinweise - es lag wirklich an den Fehlerausgaben diese haben mich darauf hingewiesen das ein include fehlgeschlagen ist.

                  Cortex - danke für Deine, in meinen Augen sehr "angreifende" Kritik - ich werde mir den Artikel durchlesen und ggf. mein Konzept überdenken aber nur ein Tip - vllt. solltest Du etwas Deine Schreibart überdenken - diese kommt sehr "arrogant" rüber.

                  Sofar - Problem gelöst - danke an alle.

                  Gruß Sven

                  Kommentar


                  • #10
                    Zitat von agrajag Beitrag anzeigen
                    kannst du mal bitte näher erklären, warum ein Zusammenlegen von GET und POST ein Sicherheitsrisiko ist?
                    es ist ein potentielles risiko - es muss keins sein. es geht in erster linie um schlampige entwicklung und den kontrollverlust, was über "irgendeinen" kanal in eine anwendung gelangt. der author des verlinkten artikels hat sich schon mehrfach zu dem thema geäussert aber ok... dabei gings überwiegend um das "böse" $_REQUEST. ein zusammenschmeissen von$_GET und $_POST fällt allerdings in dieselbe rubrik.

                    Zitat von boehseronkel Beitrag anzeigen
                    nur ein Tip - vllt. solltest Du etwas Deine Schreibart überdenken - diese kommt sehr "arrogant" rüber.
                    danke dafür... wenn ich den mund aufmache komme ich direkt zur sache das ist meine art - mit einem vergleichbaren echo kann ich umgehen. mir gefallen ebenfalls viele dinge nicht; ändern kann ich's trotzdem nicht.

                    dass du bspw. fehlermeldungen ausblendest und dich über nicht funktionierende skripte wunderst, qualifiziert dich in meinen augen nicht gerade als entwickler mit erfahrung (bin übrigens selbst autodidakt) - ergo solltes du nicht im unterforum "PHP-Fortgeschrittene" posten, sondern dich zuallererst mit den basics der programmierung beschäftigen.

                    sorry, wenn das wieder zu arrogant war...
                    cx

                    Kommentar


                    • #11
                      Letztgesagtes stimmt allerdings

                      [MOD: verschoben]
                      [COLOR="#F5F5FF"]--[/COLOR]
                      [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
                      „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                      [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
                      [COLOR="#F5F5FF"]
                      --[/COLOR]

                      Kommentar


                      • #12
                        Zitat von cortex Beitrag anzeigen
                        es ist ein potentielles risiko - es muss keins sein. es geht in erster linie um schlampige entwicklung und den kontrollverlust, was über "irgendeinen" kanal in eine anwendung gelangt. der author des verlinkten artikels hat sich schon mehrfach zu dem thema geäussert aber ok... dabei gings überwiegend um das "böse" $_REQUEST. ein zusammenschmeissen von$_GET und $_POST fällt allerdings in dieselbe rubrik.
                        Dass es mit $_REQUEST in Verbindung mit Cookies Probleme geben kann seh ich ein - da habe ich bisher ehrlich gesagt nie darüber nachgedacht. (Ich verwende $_REQUEST ja auch nicht.)
                        Und ich finde es jetzt auch nicht unbedingt schön $_GET und $_POST zusammzulegen. Aber wo da das (potentielle) Risiko liegen soll kann ich irgendwie nicht nachvollziehen. Und nur weil einem eine Lösung nicht gefällt, ist sie noch lange nicht "schlampig".
                        Einen Kontrollverlust seh ich auch nicht und von "irgendeinem" Kanal kann auch nicht die Rede sein. Es sind genau zwei Kanäle GET und POST. Und der Kontrollverlust beschränkt sich darauf, dass ich nicht wissen kann ob eine bestimmte Variable per GET oder per POST übertragen wurde - eine Information auf die man verzichten kann.

                        (Danke übrigens für den Blog-Link. Ist gerade in meinem Feed-Reader gelandet )
                        [URL="https://www.quizshow.io/"]Create your own quiz show.[/URL]

                        Kommentar


                        • #13
                          1. unsauber - darum:

                          The HTML specifications technically define the difference between "GET" and "POST" so that former means that form data is to be encoded (by a browser) into a URL while the latter means that the form data is to appear within a message body. But the specifications also give the usage recommendation that the "GET" method should be used when the form processing is "idempotent", and in those cases only. As a simplification, we might say that "GET" is basically for just getting (retrieving) data whereas "POST" may involve anything, like storing or updating data, or ordering a product, or sending E-mail.
                          http://www.cs.tut.fi/~jkorpela/forms/methods.html

                          2. wenn ein durcheinanderschmeissen der superglobalen ärger bereiten kann, gehe ich dem ganzen durch eine saubere trennung aus dem weg. das problem mit $_COOKIES war dir ja bis heut vormittag ebenfalls weitestgehend unbekannt. so... what comes next?

                          PHP macht uns die programmierung an vielen stellen sehr leicht; man sollte sich nicht auf dieser einfachheit ausruhen. das KISS-prinzip sollte an dieser stelle nicht misinterpretiert werden ;- denk mal an sicherheitslöcher wie register globals, über die sich vor jahren kein mensch gedanken gemacht hat. mit register globals zu coden war schon immer schlechter stil und eben dieser schlechte stil wurde irgendwann in zahlreichen exploits ausgenutzt.

                          grüsse,
                          cx

                          Kommentar


                          • #14
                            Nein, das hat damit nichts zu tun. Auch wenn ich $_GET und $_POST in ein $params zusammenwürfele kann ich unterscheiden ob es ein GET oder POST-Request ist.

                            Bei Rails wird das zum Beispiel so gemacht. Du findet GET und POST Paramter in einem gemeinsamen Hash (params) und kannst über request.post? (wäre in PHP sowas wie $request->isPost()) ermitteln ob es ein POST (GET/PUT/DELETE) ist und nur dann bestimmte Aktionen ausführen (oder das ganze gleich über Routing regeln).

                            2. wenn ein durcheinanderschmeissen der superglobalen ärger bereiten kann, gehe ich dem ganzen durch eine saubere trennung aus dem weg. das problem mit $_COOKIES war dir ja bis heut vormittag ebenfalls weitestgehend unbekannt. so... what comes next?
                            Ja, was kommt als nächstes? Das Problem mit $_COOKIE wird im verlinkten Artikel ja beschrieben. Und genau das besteht bei GET/POST nicht.
                            Und dieses Problem bzw. diese spezielle Attacke aus dem Artikel war mir unbekannt, weil ich $_REQUEST nicht verwende und mich nie damit beschäftigt habe.


                            PHP macht uns die programmierung an vielen stellen sehr leicht; man sollte sich nicht auf dieser einfachheit ausruhen. das KISS-prinzip sollte an dieser stelle nicht misinterpretiert werden ;- denk mal an sicherheitslöcher wie register globals, über die sich vor jahren kein mensch gedanken gemacht hat. mit register globals zu coden war schon immer schlechter stil und eben dieser schlechte stil wurde irgendwann in zahlreichen exploits ausgenutzt.
                            Über register_globals hat man sich auch schon vor Jahren Gedanken gemacht. Und es ist auch einleuchtend warum das eine ganz schlechte Idee ist und wie leicht das zu fehlern führen kann.
                            Anders als bei dem, was wir gerade besprechen

                            Deiner Applikation kann es letztlich egal sein ob es GET oder POST-Paramter sind. Du musst höchstens wissen ob die Seite per GET oder POST aufgerufen wurde. Ich sehe einfach keinen wirklichen Punkt, an dem es wichtig ist zu wissen ob ein bestimmer Parameter nun aus $_GET oder aus $_POST kommt. Überprüfen musst du die Daten egal woher sie kommen. CSRF ist bei beiden möglich. Du musst eben nur aufpassen, dass du nicht $_GET['sonswas'] und $_POST['sonswas'] gleichzeitig verwendest. Ein Sicherheitsproblem ist das nicht. Höchstens ein Punkt an dem man sich wundern wird wenn man nicht drauf achtet.
                            [URL="https://www.quizshow.io/"]Create your own quiz show.[/URL]

                            Kommentar


                            • #15
                              Bei Rails wird das zum Beispiel so gemacht. Du findet GET und POST Paramter in einem gemeinsamen Hash (params) und kannst über request.post? (wäre in PHP sowas wie $request->isPost()) ermitteln ob es ein POST (GET/PUT/DELETE) ist und nur dann bestimmte Aktionen ausführen (oder das ganze gleich über Routing regeln).
                              Warum sollte man das machen?
                              Du musst höchstens wissen ob die Seite per GET oder POST aufgerufen wurde.
                              Nicht ganz richtig. Auch ein POST Form kann GET Daten mitsenden.
                              [COLOR="#F5F5FF"]--[/COLOR]
                              [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
                              „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                              [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
                              [COLOR="#F5F5FF"]
                              --[/COLOR]

                              Kommentar

                              Lädt...
                              X