Wie Sichtbarkeitsbereich von Superglobals einschränken?

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

  • Wie Sichtbarkeitsbereich von Superglobals einschränken?

    Superglobals wie $_POST, $_SESSION, etc. sind in allen Sichtbarkeitsbereichen eines Skripts verfügbar. Also auch in Methoden. Nun meine Frage:

    Wie kann man den Sichtbarkeitsbereich von Superglobals so einschränken, dass diese z.B. in einer Methode NICHT mehr sichtbar sind? Ein vorheriges unset() ist unakzeptabel, da die Daten außerhalb der Methode noch gebraucht werden!

    grüße sebastian

  • #2
    Wieso solltest du das wollen?
    Mein PHP Blog

    Kommentar


    • #3
      Ganz einfach um zu verhindern, dass wenn man ein Template rendert, im Template auf Variablen zugegriffen werden kann, auf die nicht zugegriffen werden soll....z.B. $_SESSION

      Kommentar


      • #4
        Ich nehme mal an, dass ein Teil deiner Scripts die Superglobals braucht, weswegen es nicht in Frage kommt, sie völlig verschwinden zu lassen.

        Die Superglobals existieren schon zu Beginn der Scriptlaufzeit.
        Da man den Scope von Variablen in PHP nur bei ihrer Definition angeben und später nicht mehr ändern kann, gibt es keine Möglichkeit, die sie irgendwo unerreichbar zu machen.

        Theoretisch könnte man mit scoped Ersatzvariablen oder durch strikte zeitliche Trennung (Code, unset(), Code) halbwegs hinbekommen, was du möchtest. Aber ich sehe eigentlich keinen Grund, warum man im Template keinen Zugriff auf Umgebungsvariablen haben darf und es wäre es mir keinesfalls wert, mich im Rest der Applikation derart einzuschränken.

        Wenn es unbedingt sein muß, greif halt nicht auf PHP als Templatesprache zurück.

        Kommentar


        • #5
          Danke erstmal für deine antwort!

          eine andere Templatesprache kommt eigentlich nicht in frage, weil ich mich immer nur sehr ungern von "fremdsoftware" abhänmgig machen will! daher eigentlich eher nicht. zudem ist php weitaus mächtiger als jede templateengine.

          der Vorschlag mit der zeitliche Trennung (Code, unset(), Code) haut aber auch nur für die vairablen hin, die nur bei dem aktuellen aufruf existieren. die $_SESSION kann ich ja nicht einfach leeren bevor ich die template rendere...denn die brauch ich ja auch noch beim nächsten seitenaufruf....

          hatte halt gehofft, dass man den scope halt irgendwie temporär ändern könnte.....

          mal sehen wie ich das problem löse....

          Kommentar


          • #6
            meine idee wäre, die render-scripte, die nicht auf session und co zugreifen sollen per ajax einzubinden. wenn diese scripte dann kein session_start() bekommen, können sie imho auch nicht auf die session zugreifen.... auf post und so natürlich auch nicht...
            **********
            arkos
            **********

            Kommentar


            • #7
              ... oder GET, POST usw. eben manuell rausfiltern.

              Kommentar


              • #8
                Es gibt auch Möglichkeiten, die $_SESSION temporär zu leeren.
                Kopiere den Inhalt in eine (aus den Templates nicht erreichbare) Variable und registriere eine shutdown function, die den Inhalt wieder zurück kopiert.

                Das ist das Prinzip Code, unset(), Code.
                Wenn du die Kopie gleich zu Anfang erzeugst und dann mit ihr statt mit dem Original zu arbeiten, hast du "scoped Ersatzvariablen".

                @arkos: Masochist!

                Kommentar


                • #9
                  Effektiv ist das aber nicht, sobald man beliebigen PHP Code ausführen kann ist es auch möglich jede andere Variable auszulesen.
                  Die Regeln | rtfm | register_globals | strings | SQL-Injections | [COLOR=silver][[/COLOR][COLOR=royalblue]–[/COLOR][COLOR=silver]][/COLOR]

                  Kommentar


                  • #10
                    Original geschrieben von shammes
                    Ganz einfach um zu verhindern, dass wenn man ein Template rendert, im Template auf Variablen zugegriffen werden kann, auf die nicht zugegriffen werden soll....z.B. $_SESSION
                    Ähm. D.h. jemand fremdes kümmert sich um deine Templates? Wieso solltest du sonst dich selber einschränken?!
                    Mein PHP Blog

                    Kommentar


                    • #11
                      Vielen DAnk erstmal für all die antworten, hab sie eben erst lesen können, war nämlich am we unterwegs.

                      @arkos: ich bin definitiv kein freund von ajax, daher fällt diese variante erstmal flach....

                      @pekka: was meinst du mit manuell rausfiltern...????

                      @onemorenerd: das mit der __destruced()-Methode find ich schonmal einen ansatz, über den man nachdenken kann.....jedoch muss ich dann einen platz für die ersatzvariablen finden, sodass ich sie nicht immer und überall durchschliefen muss, aber zu gleich die templates nicht drauf zugreifen können....! pack ich sie in eine registry-klasse......so kommt das template da auch ran....pack ich sie als private in den frontcontroller, so muss ich den kram durchschleifen....ich werd mir das morgen mal ansehen, wie praktikabel das ist...mir wär halt schon lieber, wenn man expliziet für einen codeteil sagen könnte....hier gibts keinen zugriff auf die superglobals.. ;-)

                      @ModestLife: Ja

                      wünsche noch nen schönen sonntag
                      sebastian

                      Kommentar


                      • #12
                        Dann nimm eine Template-Engine. Wenn du der Person nicht traust, die die Templates verwaltet, wieso dann PHP für die Templates einsetzen?
                        Mein PHP Blog

                        Kommentar


                        • #13
                          Dann nenn mir eine Template-Engine die schnell ist, annähernd so mächtig wie PHP-selbst ist (in Bezug auf Ausgaben) und mit der man NICHT auf superglobals von PHP zugreifen kann.

                          Kommentar


                          • #14
                            Nicht unbedingt die schnellste aber weit verbreitet: Smarty

                            Kommentar


                            • #15
                              Wenn man Caching nutzen kann bei deinem Projekt ist Smarty schon in Ordnung von der Performance her!
                              Nicht das schnellste, aber in Ordnung finde ich!

                              Kommentar

                              Lädt...
                              X