GET POST

[Jochen]

Hallo,

ich benötige eine Funktion die es mir ermöglicht immer einen Wert beliebiger Variablen aus einem Request zu erhalten ohne zu wissen ob die Daten via POST oder GET geschickt werden oder ob die Variablenschreibweise in Groß oder Kleinbuchstaben kommt.

Ich hab das jetzt mal pragmatisch auf die Schnelle so gelöst:

  
function getpost($feldname){  
	$feldname_upper = strtoupper($feldname);  
	$feldname_lower = strtolower($feldname);  
	if(isset($_GET[$feldname_upper])){  
	  $wert = $_GET[$feldname_upper];  
	}  
	if(isset($_GET[$feldname_lower])){  
	  $wert = $_GET[$feldname_lower];  
	}  
	if(isset($_POST[$feldname_upper])){  
	  $wert = $_POST[$feldname_upper];  
	}  
	if(isset($_POST[$feldname_lower])){  
	  $wert = $_POST[$feldname_lower];  
	}  
	if(!isset($wert)){  
	  $wert = "";  
	}  
	return htmlspecialchars($wert);  
}  
  
//Beispiel  
echo getpost("meinevariable1");  
  

Ist das so o.k. oder gibts da einen Ansatz der das schlauer bzw. besser erledigt?
Danke für denen Tipp
Jochen

[hotti]

array_merge($_POST, $_GET);

Was den case betrifft, Tipp: lasse den sensitive. Weil: DU legst die Parameter fest und es ist DEIN Code, was die Action-Control betrifft.

--Horst

[misterunknown]

Moin,

http://www.php.net/manual/de/reserved.variables.request.php

Grüße Marco

[Der Martin]

Hi,

ich benötige eine Funktion die es mir ermöglicht immer einen Wert beliebiger Variablen aus einem Request zu erhalten ohne zu wissen ob die Daten via POST oder GET geschickt werden ...

dann bietet sich an, nicht $_GET oder $_POST abzufragen, sondern $_REQUEST. Allerdings halte ich das Konzept für, sagen wir mal, suboptimal. Ich möchte normalerweise schon wissen, auf welchem Weg ich meine Daten erhalte, und dann auch ganz gezielt auf diese Quelle zugreifen.

oder ob die Variablenschreibweise in Groß oder Kleinbuchstaben kommt.

Das ist schon kniffliger. Mit deinem Ansatz unterscheidest du nur die Fälle "komplett in Kleinbuchstaben" und "komplett in Großbuchstaben". Was ist mit Mischformen? CamelCase zum Beispiel?
Im Grunde reicht dann ein einfaches isset() nicht mehr aus. Du müsstest über die Keys von $_GET, $_POST oder $_REQUEST iterieren (alternativ auch mit der erweiterten foreach-Form) und jeden einzelnen case-insensitive auf Übereinstimmung mit dem gesuchten Wert prüfen.

Ist das so o.k. oder gibts da einen Ansatz der das schlauer bzw. besser erledigt?

Ich halte, wie gesagt, schon die Anforderung für fragwürdig.

Ciao,
 Martin

[Jochen]

Danke, für die Antwort,

dann bietet sich an, nicht $_GET oder $_POST abzufragen, sondern $_REQUEST. Allerdings halte ich das Konzept für, sagen wir mal, suboptimal. Ich möchte normalerweise schon wissen, auf welchem Weg ich meine Daten erhalte, und dann auch ganz gezielt auf diese Quelle zugreifen.

Die Schnittstelle soll sowohl mit POST als auch mit GET funktionieren. Mit $_REQUEST würde ich auch $_COOKIE zulassen wäre das ein Sicherheitsproblem?

Jochen

[Der Martin]

Hallo,

Ich möchte normalerweise schon wissen, auf welchem Weg ich meine Daten erhalte, und dann auch ganz gezielt auf diese Quelle zugreifen.
Die Schnittstelle soll sowohl mit POST als auch mit GET funktionieren.

hmmm ...

Mit $_REQUEST würde ich auch $_COOKIE zulassen

Ja, und $_ENV und $_SERVER. In einer Reihenfolge, die über die php.ini beeinflussbar ist und in der Defaulteinstellung "EGPCS" haben Cookie-Daten tatsächlich eine höhere Priorität als GET und POST.

wäre das ein Sicherheitsproblem?

Sehe ich nicht. Oder willst du Cookies setzen, die genauso heißen wie ein erwarteter GET- oder POST-Parameter? Das wäre dann problematisch - aber nicht sicherheitsrelevant, sondern "nur" funktionsrelevant.

Ciao,
 Martin

[dedlfix]

Tach!

Die Schnittstelle soll sowohl mit POST als auch mit GET funktionieren. Mit $_REQUEST würde ich auch $_COOKIE zulassen wäre das ein Sicherheitsproblem?

Man kann es deaktivieren, beziehungsweise genau konfigurieren, was und in welcher Reihenfolge für $_REQUEST berücksichtigt werden soll. Einen Wert als Cookie zu übergeen ist für einen Bot-Programmierer nicht viel schwerer als Daten mit GET/POST zu übergeben. Aus der Sicht deiner Anwendung kommen auch Cookies vom Client und sind damit nicht besser oder schlechter als alle anderen vom Client kommenden Daten.

dedlfix.

[molily]

Einen Wert als Cookie zu übergeen ist für einen Bot-Programmierer nicht viel schwerer als Daten mit GET/POST zu übergeben. Aus der Sicht deiner Anwendung kommen auch Cookies vom Client und sind damit nicht besser oder schlechter als alle anderen vom Client kommenden Daten.

Ja, das stimmt schon. Aber es gibt verschiedene Sicherheitsfeatures, die auf dem Unterschied zwischen GET, POST und Cookie basieren. Zum Beispiel Authenticity-Tokens zum Verhindern von Cross-Site Request Forgery im Request-Body gesendet werden. Oder Session-IDs, die in HttpOnly-Cookies gesendet werden, um Session Hijacking bzw. Session Fixation zu vermeiden.

Daher würde ich grundsätzlich von Ansätzen wie Jochens abraten. Die Herkunft von Eingabedaten unsichtbar zu machen, selbst wenn sie überprüft und escapet werden, führt früher oder später zu fehlerhaftem oder unsicherem Code.

Mathias

[hotti]

hi again,

Die Schnittstelle soll sowohl mit POST als auch mit GET funktionieren. Mit $_REQUEST würde ich auch $_COOKIE zulassen wäre das ein Sicherheitsproblem?

Die Frage der Sicherheit fängt damit an, ob Du Manipulationen an Parametern zulässt, Groß-/Kleinschreibung inbegriffen.

Schönes Wochenende.

[molily]

Hallo,

Die Schnittstelle soll sowohl mit POST als auch mit GET funktionieren. Mit $_REQUEST würde ich auch $_COOKIE zulassen wäre das ein Sicherheitsproblem?

Das lässt sich konkret nicht sagen, aber allgemein: Es ist ein potenzielles Sicherheitsproblem, wenn eine Schnittstelle freizügiger als unbedingt nötig ist, wenn verschiedene Eingabequellen zugelassen werden anstatt eine wohldefinierte, wenn in einem Programm die Herkunft von Eingabedaten verschleiert wird.

In RESTful APIs haben HTTP-Verben eine besondere Bedeutung, da käme »sowohl POST als auch GET« nicht infrage, weil ein inhaltlicher Unterschied zwischen GET und POST besteht. (Höchstens wenn man eine JSONP-API anbieten will und Clients kein Cross-Origin Resource Sharing unterstützen, kann man die anderen Verben auf GET z.B. mit einem _method-Parameter abbilden.)

Mathias

[ChrisB]

Hi,

Die Schnittstelle soll sowohl mit POST als auch mit GET funktionieren. Mit $_REQUEST würde ich auch $_COOKIE zulassen wäre das ein Sicherheitsproblem?

Wenn deine Schnittstelle nicht mal auf klar definierte Parameter-Namen Wert legt, dann kann „Sicherheit“ ja eigentlich eh kein vorrangiges Interesse sein.

MfG ChrisB

[M.]

Mahlzeit,

Ich möchte normalerweise schon wissen, auf welchem Weg ich meine Daten erhalte, und dann auch ganz gezielt auf diese Quelle zugreifen.

Ich sag dir mal, wieso ich in meinem Framework die Möglichkeit biete, per POST oder GET Daten abzugreifen.
Je nach Modul erfolgt die Übergabe entweder per Post oder per Get. Das ist dem Programmierer der Erweiterung überlassen. Meine Funktion kann zusätzlich noch mit $_FILES umgehen und Post erzwingen.

Der Vorteil, wenn ich dem Programmierer nur bestimmte Daten zur Verfügung stellen will, fülle ich eine entsprechende Variable und lösche $_GET und $_POST.
Der Programmierer hat dann sein Array und muss sich nicht drum kümmern, die die Daten übertragen wurden.

Grad das macht doch ein Framework aus, dass es Funktionen gibt, die einem Arbeit abnehmen und bestimmte Daten ohne Programmieraufwand zur Verfügung stellen.

[hotti]

hi,

dann bietet sich an, nicht $_GET oder $_POST abzufragen, sondern $_REQUEST. Allerdings halte ich das Konzept für, sagen wir mal, suboptimal. Ich möchte normalerweise schon wissen, auf welchem Weg ich meine Daten erhalte, und dann auch ganz gezielt auf diese Quelle zugreifen.

Interessanter Aspekt. Ich denke aber auch, dass ein Programmierer, der auf dem Parameter 'foo' das Dateihandle für eine hochgeladene Datei erwartet, sich darauf verlassen kann, dass dieser Upload nur mit Request-Method "POST" und dem Enctype "multipart/form-data" stattgefunden haben kann. Somit kann sich seine Kontrollstruktur darauf beschränken, zu prüfen, ob das Handle geöffnet ist.

Horst

[Tom]

Hello,

ich benötige eine Funktion die es mir ermöglicht immer einen Wert beliebiger Variablen aus einem Request zu erhalten ohne zu wissen ob die Daten via POST oder GET geschickt werden ...

dann bietet sich an, nicht $_GET oder $_POST abzufragen, sondern $_REQUEST. Allerdings halte ich das Konzept für, sagen wir mal, suboptimal. Ich möchte normalerweise schon wissen, auf welchem Weg ich meine Daten erhalte, und dann auch ganz gezielt auf diese Quelle zugreifen.

oder ob die Variablenschreibweise in Groß oder Kleinbuchstaben kommt.

Da gibt es http://de3.php.net/manual/en/function.array-change-key-case.php
Das solltest Du aber mit Vorsicht benutzen. Erstens ist es mWn nicht multibytefest und zweitens werden Keys, die schon vorhanden waren, ohne Warnung überschrieben.

Wenn das nichts ausmacht, kannst Du die Funktion benutzen.

Üblicherweise übernimmt man aber nicht blind irgendwelche Parameter, sondern hält ein Array mit den erwarteten Bezeichnern und den darzustellenden Typen bzw. Ranges bereit. Das wird dann "abgefahren" und gegen die Requestdaten abgeglichen. Da man dafür sowieso jedes Element einzeln anfassen muss, kann man an dieser Stelle auch die CaseSenseless berücksichtigen und auch ein Flag setzen, dass der Parameter vorhanden ist. Wenn er dann ein zweites Mal auftaucht kann man eine Fehlerprozedur auslösen, oder auch nicht ...

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg