validieren $_SERVER['PHP_SELF'] :shock:

Alles, was PHP betrifft, kann hier besprochen werden.

validieren $_SERVER['PHP_SELF'] :shock:

Postby WilliL » 10. August 2010 21:07

Durch Interesse an Sicherheit in Scripts bin ich durch Zufall auf eine Seite gestoßen, in der auf die "Sicherheitslücke" $_SERVER['PHP_SELF'] hingewiesen wurde.
Hier stolperte ich über den Scriptteil: <form action="<?php echo  htmlentities($_SERVER['PHP_SELF']); ?>" method="post">
Bisher war ich davon ausgegangen, dass die $_SERVER[x] valide Daten seinen, ausgenommen die vom Client übermittelten (wie Agent, Referer etc]
Nach weiterer Recherche kam ich auf XSS und testete dies aus - Injektion hatte bei mir (ohne htmlentities()) natürlich funktioniert.
Der Nachteil durch Konstanten oder direkter Texteingabe sind "undefinierte Zustände" (z.B. Datei nicht gefunden, Zugriff verboten ..), das Script jedoch sicher.
Besser war die jetzt funktionierende Variante (Abwurf auf die loginseite):
Code: Select all
//  Absicherung gegen XSS bei $_SERVER["PHP_SELF"] - im Script als Konstante SELBSTAUFRUF
if ($_SERVER["SCRIPT_FILENAME"] != $_SERVER["DOCUMENT_ROOT"].$_SERVER["PHP_SELF"]) {
     // XSS detected, error handling
     // mail an admin
   session_destroy();
   header( "location: http://localhost/".$outpage); // Login Seite
   exit;
} else
   define("SELBSTAUFRUF", $_SERVER["SCRIPT_NAME"]);

Für mich stellt sich jetzt die Frage, in wie weit die Variablen $_SERVER["SCRIPT_FILENAME"], $_SERVER["DOCUMENT_ROOT"] und $_SERVER["SCRIPT_NAME"] vetrauenswürdig sind.
Kann mir hier jemand eine Info / einen Tipp geben, wo ich dazu mehr erfahre? Welche sind generell valide?
$_SERVER["DOCUMENT_ROOT"] müsste valide sein, da es vermutlich aus der "httpd.conf" des Apache ausgelesen wird. Aber wie werden die anderen Variablen gebildet?
Willi
WilliL
 
Posts: 660
Joined: 08. January 2010 10:54
Operating System: Win7Home Prem 64 SP1

Re: validieren $_SERVER['PHP_SELF'] :shock:

Postby Altrea » 11. August 2010 00:53

Hi WilliL,

XSS und Formulare ist ein sehr kompliziertes Thema wo ich bisher keine befriedigende Lösung gefunden habe.
Die Unsicherheit des PHP_SELF Index spricht sich mitlerweile ja auch im deutschsprachigen Raum rum (erkannt wurde dies schon vor Jahren).

Die meisten Seiten verweisen hier als Workaround auf die PHP-Funktionen htmlspecialchars() und htmlentities(). Suchst du bei Google allerdings nach "XSS trotz htmlspecialchars" oder "XSS trotz htmlentities", wirst du auch hierzu Quellen finden. Diese beziehen sich in der Regel auf zwei gegebenheiten: Man setzt die Option zum maskieren von Double UND Single-Quotes nicht (siehe Funktionsbeschreibungen der beiden Funktionen), und man prüft nicht ausreichend auf den korrekten Zeichensatz. Gerade beim Zeichensatz wird es dann sehr kompliziert.
Folgender Thread bei php.net ist zu dem Thema sehr interessant, ebenso wie dieser Thread.

Welche Möglichkeiten hat man noch:
- $_SERVER['SCRIPT_NAME'] halte ich für sicherer. Manche Workarounds verweisen darauf und bisher konnte ich keine Quellen finden die dieses Index als XSS anfällig beschrieben.
- Bei form tags kann man das action Attribut einfach leer lassen. Dies funktioniert in der Regel auch ganz gut. Dort ist man dann aber auf das goodwill der Browserhersteller angewiesen, denn da es nirgenswo festgeschrieben steht wie ein Browser mit einem leeren action Attribut reagieren soll, ist man hier darauf angewiesen, dass sich alle Browser gleich verhalten.
- PHP-Security Bibliotheken und Web Application Firewalls (nicht ausreichend mit beschäftigt. Wenn du was interessantes dazu findest, sag bescheid).

Nahezu alle Workarounds beziehen sich auf sogenannte Blacklist-Methoden (also das maskieren oder verhindern von schädlichen Zeichen). Der bessere Ansatz wäre eine Whitelist die alle gegebenheiten (Zeichensätze, etc.) abdeckt. Wenn du eine befriedigende Lösung dazu findest, sag mir bescheid :D .

P.S.: Generell wäre ich bei dem $_SERVER Array eher kritisch. Lieber einmal zuviel prüfen/filtern als einmal zuwenig. $_SERVER['DOCUMENT_ROOT'] halte ich auch für unbedenklich. Aber allen Indizes die per HTTP Header vom Browser gesendet werden sollte man prinzipiell misstrauen. Auch $_SERVER['SCRIPT_FILENAME'] würde ich nicht blind trauen.

P.P.S.: Da ich mich auf diesem Gebiet auchnicht sehr sicher fühle, würde ich nichts was ich sage blind für bare Münze nehmen ^^. Manchmal habe ich auch das Gefühl, dass es eher nochmehr verunsichert je mehr man das Thema googlet. So wird wie beschrieben htmlentities() von manchen als nicht sicher angesehen, der PHP Security Guide den man als Richtlinie schonmal hernehmen kann aber genau diese Verwendung beschreibt (auch wenn es die Verwendung nur als "much safer" betitelt).
We don't provide any support via personal channels like PM, email, Skype, TeamViewer!

It's like porn for programmers 8)
User avatar
Altrea
AF Moderator
 
Posts: 11926
Joined: 17. August 2009 13:05
XAMPP version: several
Operating System: Windows 11 Pro x64

Re: validieren $_SERVER['PHP_SELF'] :shock:

Postby Nobbie » 11. August 2010 10:11

Altrea wrote: Auch $_SERVER['SCRIPT_FILENAME'] würde ich nicht blind trauen.


Ich schon. Dort steht nämlich der absolute Pfadname des Scripts drin, welches gerade ausgeführt wird (also beispielsweise /var/www/html/myscript.php). Und wenn der nicht stimmt, kann das Script auch nicht ausgeführt werden (Huhn und Ei Problem), denn das ist die Datei, die Apache an PHP übergibt.

Nur ist diese Variable für die Konstruktion einer URL, um ein PHP Script aufzurufen (im action-TAG) wenig hilfreich, weil dort eben URLs benötigt werden und keine absoluten Pfadnamen (die sich ihrerseits aus der URL und der Konfiguration von DOCUMENT_ROOT bzw. eine ALIAS ergeben).

Übrigens ist auch das vorgetragene Script zur Umgehung von XSS nicht besondes einfallsreich, es berücksichtigt nämlich nicht Möglichkeit von ALIAS und führt nur Scipts unter dem DocumentRoot aus.

Im Prinzip sind alle Inhalte vertrauenswürdig, die sich entweder aus der Apache Konfiguration ableiten (wie DOCUMENT_ROOT) und/oder aus dem Dateisystem des Servers (SCRIPT_FILENAME). Alles, was aus dem Request kommt und nicht mit der Konfiguration abgeglichen wird, kann manipuliert werden.

Variablen wie PHP_SELF o.ä. habe ich ohnehin nie benutzt, weil ich es schon als Designfehler ansehe, dass ein Formular sich selbst aufruft. Ich rufe in Formularen grundsätzlich andere Scripts auf (und das mit fest verdrahteten Namen).
Nobbie
 
Posts: 13170
Joined: 09. March 2008 13:04

Re: validieren $_SERVER['PHP_SELF']

Postby WilliL » 11. August 2010 10:43

Hallo Altrea,
.. wenn ich vorab gewusst hätte was passieren würde, als ich xampp herunter lud .. :shock:
Altrea wrote:XSS und Formulare ist ein sehr kompliziertes Thema wo ich bisher keine befriedigende Lösung gefunden habe.
Die Unsicherheit des PHP_SELF Index spricht sich mitlerweile ja auch im deutschsprachigen Raum rum (erkannt wurde dies schon vor Jahren).


Danke für das Feedback. Wenn erfahrene User nicht eine adhoc-Lösung haben, komme ich mir nicht ganz .. vor ;)

Den Zeichensatz habe ich im form tag schon mit accept charset eingeschränkt. Die Sicherheitsbibliothek SSEQ_LIB wollte ich mir erst einmal ersparen, da ich mich erst einmal mit PHP und mySQL beschäftigen wollte. Den Artikel von Erich Kachel hatte ich schon einmal gelesen (aber wieder vergessen - Danke)

"htmlspecialchars() und htmlentities()" daher mein Ansatz über die Servervariablen, die bis dato noch nicht validiert wurden
"Bei form tags kann man das action Attribut einfach leer lassen" erscheint mir unsauber, möchte ich nicht ohne Not anfangen
"PHP-Security Bibliotheken" mit SSEQ_LIB werde ich mich wohl früher als beabsichtigt beschäftigen müssen
"Web Application Firewalls" entfällt, da es für eine kleine privet HP oversized ist, besonders, da sie gehostet wird und ich mit den Einschränkungen des Hosters (AllInkl) leben werde - das wäre natürlich die ideale Lösung

Bisher habe ich per Whitelist die Validierungsroutinen (welche Zeichen erwarte und akzeptiere ich) realisiert. In den MySQL-Tabellen stehen bisher reine Daten. Ich habe nach einem Ausflug in das komplexe Thema Charaktersatz alles auf einen Zeichensatz (UTF-8) umgestellt. Das handling und die Berücksichtigung der Besonderheiten war mir zu komplex für ein Hobby.

Wenn du eine befriedigende Lösung dazu findest, sag mir bescheid :D .

gerne :D
Willi
WilliL
 
Posts: 660
Joined: 08. January 2010 10:54
Operating System: Win7Home Prem 64 SP1

Re: validieren $_SERVER['PHP_SELF'] :shock:

Postby WilliL » 11. August 2010 10:50

Hallo Nobbie,
Nobbie wrote:Nur ist diese Variable für die Konstruktion einer URL, um ein PHP Script aufzurufen (im action-TAG) wenig hilfreich, weil dort eben URLs benötigt werden und keine absoluten Pfadnamen (die sich ihrerseits aus der URL und der Konfiguration von DOCUMENT_ROOT bzw. eine ALIAS ergeben).

Übrigens ist auch das vorgetragene Script zur Umgehung von XSS nicht besondes einfallsreich, es berücksichtigt nämlich nicht Möglichkeit von ALIAS und führt nur Scipts unter dem DocumentRoot aus.

Im Prinzip sind alle Inhalte vertrauenswürdig, die sich entweder aus der Apache Konfiguration ableiten (wie DOCUMENT_ROOT) und/oder aus dem Dateisystem des Servers (SCRIPT_FILENAME). Alles, was aus dem Request kommt und nicht mit der Konfiguration abgeglichen wird, kann manipuliert werden.

Variablen wie PHP_SELF o.ä. habe ich ohnehin nie benutzt, weil ich es schon als Designfehler ansehe, dass ein Formular sich selbst aufruft. Ich rufe in Formularen grundsätzlich andere Scripts auf (und das mit fest verdrahteten Namen).

Danke für die Info, die ich noch durcharbeiten werde, hier gab es eine zeitl. Übeschneidung der Postings
Willi
WilliL
 
Posts: 660
Joined: 08. January 2010 10:54
Operating System: Win7Home Prem 64 SP1

Re: validieren $_SERVER['PHP_SELF'] :shock:

Postby Altrea » 11. August 2010 11:37

Nobbie wrote:
Altrea wrote: Auch $_SERVER['SCRIPT_FILENAME'] würde ich nicht blind trauen.


Ich schon. Dort steht nämlich der absolute Pfadname des Scripts drin, welches gerade ausgeführt wird (also beispielsweise /var/www/html/myscript.php). Und wenn der nicht stimmt, kann das Script auch nicht ausgeführt werden (Huhn und Ei Problem), denn das ist die Datei, die Apache an PHP übergibt.

Da hast du natürlich recht. Ich habe lediglich bei php.net folgendes gelesen:
Note: If a script is executed with the CLI, as a relative path, such as file.php or ../file.php, $_SERVER['SCRIPT_FILENAME'] will contain the relative path specified by the user.

Es ist natürlich vollkommener nonsense ein Formular per CLI aufzurufen, und in diesem Fall hat der User in der Regel auchschon beschränkte rechte auf die Ordnerstruktur des Servers, was auch für normale PHP-Scripte nicht zutrifft. Aber dieses "specified by the user" ist mir nicht geheuer, dass ich mir da nicht ganz so sicher bin.

Nobbie wrote:Übrigens ist auch das vorgetragene Script zur Umgehung von XSS nicht besondes einfallsreich, es berücksichtigt nämlich nicht Möglichkeit von ALIAS und führt nur Scipts unter dem DocumentRoot aus.

Auf welches Script beziehst du dich hier genau? Hast du vielleicht einen anderen/besseren Ansatz?

Nobbie wrote:Variablen wie PHP_SELF o.ä. habe ich ohnehin nie benutzt, weil ich es schon als Designfehler ansehe, dass ein Formular sich selbst aufruft. Ich rufe in Formularen grundsätzlich andere Scripts auf (und das mit fest verdrahteten Namen).

Das ist natürlich eine sehr saubere Lösung.
We don't provide any support via personal channels like PM, email, Skype, TeamViewer!

It's like porn for programmers 8)
User avatar
Altrea
AF Moderator
 
Posts: 11926
Joined: 17. August 2009 13:05
XAMPP version: several
Operating System: Windows 11 Pro x64

Re: validieren $_SERVER['PHP_SELF'] :shock:

Postby Nobbie » 11. August 2010 11:56

Altrea wrote:Auf welches Script beziehst du dich hier genau?


Oben das, von WilliL. Die folgende Zeile baut ja darauf, dass man im DocumentRoot arbeitet und nicht unter einem ALIAS:

Code: Select all
if ($_SERVER["SCRIPT_FILENAME"] != $_SERVER["DOCUMENT_ROOT"].$_SERVER["PHP_SELF"]) {


Altrea wrote:Hast du vielleicht einen anderen/besseren Ansatz?


s.o. - fest verdrahtete Namen.
Nobbie
 
Posts: 13170
Joined: 09. March 2008 13:04

Re: validieren $_SERVER['PHP_SELF'] :shock:

Postby WilliL » 11. August 2010 13:41

Nobbie wrote:Übrigens ist auch das vorgetragene Script zur Umgehung von XSS nicht besondes einfallsreich, es berücksichtigt nämlich nicht Möglichkeit von ALIAS und führt nur Scipts unter dem DocumentRoot aus.

Da ein eigener Server noch weit außerhalb meines Kenntnisstandes ist, hatte ich den ALIAS nicht präsent. Danke für den Hinweis.
Dies läßt sich dann unter dem Aspekt, dass $_SERVER["SCRIPT_NAME"] valide ist, relativ leicht korrigieren:
Code: Select all
} else {
         $scriptpath_array = explode("/",$_SERVER["SCRIPT_NAME"]);
         $idx = count($scriptpath_array);
         define("SELBSTAUFRUF", $scriptpath_array ($idx-1));
}

Variablen wie PHP_SELF o.ä. habe ich ohnehin nie benutzt, weil ich es schon als Designfehler ansehe, dass ein Formular sich selbst aufruft. Ich rufe in Formularen grundsätzlich andere Scripts auf (und das mit fest verdrahteten Namen).

Andererseits sind "Endlosschleifen" (Repeat ... Until (TRUE)) ein normales Instrument in der Programmierung um valide Daten zu erzwingen. Die Akzeptanz bei einem User ist gering, wenn er immer von vorne anfangen muss, weil ersich einmal vertippt hat
Vermutlich ist die Betrachtungsweise davon abhängig, über welchem Bereich man an den "Serverbetrieb" gekommen ist.

Das Ziel hier ist ja "fest verdrahteten Namen" zu nutzen, nur dass diese bei mir in der Datei "konstanten.inc.php" ausgelagert sind, bzw dort generiert werden. (Ich halte XSS für gefährlicher als häufig dargestellt wird.)

Hier geht es um ein Formular (Selfservice-Adressen), bei dem ich beim Aufruf die Daten aus einer DB hole und sie per Voreinstellung in das Fomular eintrage. Der User kann sie dann anpassen/korrigieren. Bei Fehlern (z.B. nicht akzeptierte Zeichen) wird der Datensatz dann mit optischem Hinweis mit den eingegebenen Zeichen angezeigt - es ist halt von der Funktionalität immer der gleiche Aufruf bis die Daten akzeptiert werden oder der User abbricht.

Hier fällt mir keine alternative Lösung mit 2 Scripts ein. Spätestens beim 2. Script hätte ich die ursprüngliche Herausforderung.
Gibt es hier einen alternativen Lösungsangang?
Willi
WilliL
 
Posts: 660
Joined: 08. January 2010 10:54
Operating System: Win7Home Prem 64 SP1

Re: validieren $_SERVER['PHP_SELF'] :shock:

Postby Nobbie » 11. August 2010 14:25

WilliL wrote:Andererseits sind "Endlosschleifen" (Repeat ... Until (TRUE)) ein normales Instrument in der Programmierung um valide Daten zu erzwingen.


Dieser Äpfel mit Birnen Vergleich ist nicht sehr gelungen. Das eine ist ein Kontrollfluß (welches auch durch Dateinamen erkennbar sein sollte), bei dem man auch erkennt, in welchem Bearbeitungsstadium eine Applikation ist, das andere ist ein ganz normales Instrumentarium der strukturierten Programmierung.

WilliL wrote:Die Akzeptanz bei einem User ist gering, wenn er immer von vorne anfangen muss, weil ersich einmal vertippt hat


Verstehe ich leider nicht?!

WilliL wrote:Vermutlich ist die Betrachtungsweise davon abhängig, über welchem Bereich man an den "Serverbetrieb" gekommen ist.


Verstehe ich ebenso leider nicht.

WilliL wrote:Das Ziel hier ist ja "fest verdrahteten Namen" zu nutzen, nur dass diese bei mir in der Datei "konstanten.inc.php" ausgelagert sind, bzw dort generiert werden. (Ich halte XSS für gefährlicher als häufig dargestellt wird.)


Was sicherlich nicht schlecht ist.

WilliL wrote:Hier geht es um ein Formular (Selfservice-Adressen), bei dem ich beim Aufruf die Daten aus einer DB hole und sie per Voreinstellung in das Fomular eintrage. Der User kann sie dann anpassen/korrigieren. Bei Fehlern (z.B. nicht akzeptierte Zeichen) wird der Datensatz dann mit optischem Hinweis mit den eingegebenen Zeichen angezeigt - es ist halt von der Funktionalität immer der gleiche Aufruf bis die Daten akzeptiert werden oder der User abbricht.

Hier fällt mir keine alternative Lösung mit 2 Scripts ein. Spätestens beim 2. Script hätte ich die ursprüngliche Herausforderung.
Gibt es hier einen alternativen Lösungsangang?


Allerdings. Damit schlägst Du gleich die nächste Fliege mit der gleichen Klappe, denn anscheinend hast Du eine "monolithische" Programmstruktur (sprich: es gibt nur ein Riesenscript mit allem drin).

Trenne es auf nach Funktion (beispielsweise "get.php", "put.php", "update.php", "error.php" usw.), wie es Dir im Kontrollfluss sinnvoll erscheint. Und dann trennst Du außerdem HTML und PHP weitestgehend und modularisierst (falls möglich) auch noch die HTML Komponenenten. Dann wird es ggf. ein Modul "formular.html.php" o.ä. geben, da steht beispielsweise nur das Formular drin, die Werte sind globale Variablen und diese werden vom Steuerscript bestückt (kommen je nach dem entweder direkt aus einer Datenbank, oder eben aus einem User-Post und anschließender Validierung) entsprechend wird auch das action-Tag variabel gesetzt und dieses Formular (resp. möglicherweise noch das HTML Rahmentemplate) wird via include() ganz am Ende der PHP Verarbeitung inkludiert. So ist es dann auch sehr einfach möglich, dem Anwender nur eine Meldung zu senden "Datensatz wurde erfolgreich geändert", ohne erneut Formular anzuzeigen. Das Formular (oder ggf. eben eine komplette HTML Seite inkl. Formular - das mußt Du selbst herausfinden, wie die Struktur am besten aufzuteilen ist) wird eben nur inkludiert, wenn die Daten vom Anwender bearbeitet werden sollen.

In diesem Formular kannst Du dann beispielsweise auch den Eingabefeldern dynamisch verschiedene class-Werte (CSS) zuordnen. Wenn beispielsweise ein Datum falsch formatiert ist, bekommt das Datumseingabefeld die class "error", und diese Klasse umrandet das Eingabefeld rot und stellt den Inhalt fett dar (nur als Beispiel). Und Felder, deren Inhalt korrekt ist, bekommen als class den Wert "standard" (oder ggf. sogar vom Inhaltstyp anhängig, also "datum" oder so, falls Du solche Felder anders darstellen willst).

P.S.: Insgesamt kommt mir die Datenverarbeitung sehr unkomplett vor. Normal ist doch eigentlich diese Funktionalität:

1) Neuanlage
2) Anzeige ("browse") vorhandenere Datensätze (mit Suchfunktion resp. "Filterfunktion", beispielsweise nach bestimmten Orten suchen)
2a) Auswahl eines vorhandenen Datensatzes
3) Ändern eines vorhandenen Datensatzes
3a) (sowie 1a) folgt Validierung der eingegeben Daten
4) Zurückschreiben des neuen/geänderten und validierten Datensatzes
5) Auswahl und Löschen eines vorhandenen Datensatzes
5a) ggf. mit Bestätigung ("confirm") des Löschvorgangs

Das sind (grob) die einzelnen Transaktionsschritte, die für die Pflege einer Datenbank notwendig sind. Davon sehe ich oben nur 3 und 3a und 4.
Nobbie
 
Posts: 13170
Joined: 09. March 2008 13:04

Re: validieren $_SERVER['PHP_SELF'] :shock:

Postby WilliL » 11. August 2010 16:03

hier ist der Unteschied Profi / Amateur.. Deine Betrachung ist erheblich komplexer
Das eine ist ein Kontrollfluß (welches auch durch Dateinamen erkennbar sein sollte), bei dem man auch erkennt, in welchem Bearbeitungsstadium eine Applikation ist, das andere ist ein ganz normales Instrumentarium der strukturierten Programmierung.

Diese Betrachtungsweise kenne ich nicht - klingt interessent.
anscheinend hast Du eine "monolithische" Programmstruktur (sprich: es gibt nur ein Riesenscript mit allem drin

ja, das stimmt. Es bestehen zwar einzelne Scriptteile, die per include eingebunden werden und eine Vorlage, in der ich einen "fertigen Rahmen" habe, der dann ja nach Aufgabe erweitert wird. Bei Formularen mach ich zZ die Auswertung im gleichen Script.

Trenne es auf nach Funktion (beispielsweise "get.php", "put.php", "update.php", "error.php" usw.), wie es Dir im Kontrollfluss sinnvoll erscheint. ..., wie die Struktur am besten aufzuteilen ist) wird eben nur inkludiert, wenn die Daten vom Anwender bearbeitet werden sollen.


Das werde ich mir noch genauer zu Gemüte führen. Erscheint mir auf den 1. Augenblick schwierig umzusetzen - werde ich mir in jedem Falle durch den Kopf gehen lassen.
Willi
WilliL
 
Posts: 660
Joined: 08. January 2010 10:54
Operating System: Win7Home Prem 64 SP1

Re: validieren $_SERVER['PHP_SELF'] :shock:

Postby WilliL » 11. August 2010 16:10

P.S.: Insgesamt kommt mir die Datenverarbeitung sehr unkomplett vor. Normal ist doch eigentlich diese Funktionalität: ...
Das sind (grob) die einzelnen Transaktionsschritte, die für die Pflege einer Datenbank notwendig sind. Davon sehe ich oben nur 3 und 3a und 4.

Ist an dieser Stelle so beabsichtigt: hier darf User nur eigene Daten ändern/korrigieren (Adresse, Telekontakt) und die sind durch das Login vorgegeben :)
Willi
WilliL
 
Posts: 660
Joined: 08. January 2010 10:54
Operating System: Win7Home Prem 64 SP1

erledigt: validieren $_SERVER['PHP_SELF']

Postby WilliL » 13. August 2010 22:03

Nobbie wrote: ... anscheinend hast Du eine "monolithische" Programmstruktur (sprich: es gibt nur ein Riesenscript mit allem drin).

Trenne es auf nach Funktion (beispielsweise "get.php", "put.php", "update.php", "error.php" usw.), wie es Dir im Kontrollfluss sinnvoll erscheint. Und dann trennst Du außerdem HTML und PHP weitestgehend und modularisierst (falls möglich) auch noch die HTML Komponenenten. Dann wird es ggf. ein Modul "formular.html.php" o.ä. geben, ...

Hallo Nobbi,
danke für den Denkanstoß / die Betrachtungsweise :D der Monolith ist gesprengt, jetzt müssen nur noch die Include"x.inc.php" optimiert werden. War für mich etwas aufwendiger, da es ein ganz anderer Denkansatz war - riesen Vorteil $_SERVER['PHP_SELF'] wird nicht mehr benötigt und es steckt noch ein großes Optimierungspotenzial drin.. einziger Nachtei (?) wirkt zuerst unübersichtlich, verlangt mehr Diziplin und <b>ich <b>benötige mehr Steuervariablen.

Da ich keine persönlichen Daten im Browser sehen und auch nicht beim Client haben wollte, ist bei mir die Datenweitergabe via header oder cookie nicht in Frage gekommen. Da ich keine Lösung gefunden habe, die einer Postfunktion gleicht, habe ich auf die $_Session zurückgegriffen ($_Post hätte ich bevorzugt, da dann das explizite unset() nicht notwendig gewesen wäre. )
Oder gibt es hier eine Alternative?
Bei meinen Recherchen bin ich immer auf Formulare gestoßen. Aber in dem verteilten Konzept müssen manchmal (bei mir via header & Session gelöst) auch an andere Scripte Daten übermittelt werden, ohne dass ein Formular mit Submit genutzt werden kann.
Ich werde wohl auf die $_SERVER [PATH_INFO & QUERY_STRING] zugreifen um Manipulationen in der URI zu identifizieren.
thx :D
Willi
WilliL
 
Posts: 660
Joined: 08. January 2010 10:54
Operating System: Win7Home Prem 64 SP1


Return to PHP

Who is online

Users browsing this forum: No registered users and 23 guests