Vorteile von $_GET

[freakXHTML]

Moin, moin!

Ich höre immer, dass ich nicht $_GET nutzen soll, da es unsicher ist. Doch ich frage mich, wann ich denn mal $_GET nutzen soll? Was sind die Vorteile und wann nutzt ihr es? Sicherlich nicht, um die Session ID zu übergeben.

Wie man an den meisten Websiten erkennt (auch diese), arbeiten viele mit $_GET.

Vielen Dank
lg, freakXHTML

 

[crash]

$_GET, $_POST, $_REQUEST, $_COOKIE und jede andere Form von User-Input ist potenziell gefährlich.

Das heißt nicht, dass man $_GET nicht benutzen soll. Wann man was benutzt kommt auf den Anwendungsfall an. Üblicherweise überträgt man nur kleine Mengen von Daten mittels GET und wenn diese über die URL verfügbar sein sollen. Über POST überträgt man die meisten Formulare die evtl. große Mengen Daten enthalten können (z.B. auch Dateien).

Ohne $_GET und $_POST usw. geht es also nicht, denn für EVA braucht man nun mal Eingabe.

 

[kruschimappel]

Wie schon gesagt, POST wird meistens für Formulare verwendet.
GET bietet sich zum Beispiel an, wenn du (automatisch) generierte URLs hast. Da macht es nicht viel Sinn, ein Formular zu schreiben, welches die Daten dann per POST überträgt. Es ist viel einfacher, die Variablen per GET zu übergeben. Bei entsprechend vernünftiger Absicherung und Kontrolle der übergebenen Daten ist das auch relativ sicher.

 

[Gilles]

Formulare mit GET wirst du nicht all zu häufig antreffen (Aber es gibt sie auch ;)).
Wie meine Vorgänger schon erwähnt haben, kann man dynamische Links erstellen, die dann per GET ausgelesen werden. Dabei könnte man sich so etwas vorstellen wie:
viewuser.php?userId=$userId
Wobei die Userid beim auslesen aus der Datenbank gesetzt wird.
jedoch sollte man beachten, wann man GET und wann man POST benutzt. Denn sensible Daten wie zum Beispiel ein Passwort über die Adresszeile mit zu transportieren wäre grob fahrlässig. Somit immer abwägen was in deinem Fall gefordert ist :)

 

[mermshaus]

Hier wurde es schon mehrfach so halb gesagt, aber noch mal genau zum Teilaspekt GET und Formulare:

- Das Ergebnis des Absendes eines Formulars per GET (die resultierende Seite) ist verlinkbar, weil alle verschickten Daten in der URL vorliegen.

Wenn du zum Beispiel das Ergebnis einer Websuche verlinken willst, muss in der URL eine Information über den Suchbegriff enthalten sein. Deshalb verschicken alle Suchmaschinen ihre Such-Eingabeformulare per GET und deshalb können wir die Resultatseiten anderen Leuten zuschicken.

Es gibt übrigens eine Richtlinie, die besagt, dass Formulare, die einen Datenbestand verändern (zum Beispiel einen neuen User anlegen oder einen Blogpost löschen) nur per POST versendet werden sollen. Formulare, die lediglich vorhandene Daten abrufen (zum Beispiel alle Einträge vom 7. August 2010) dagegen per GET. Die wichtige Regel hierbei ist allerdings die POST betreffende. (Browser fragen sogar nach, ob eine Seite, die durch das Absenden eines Formulars per POST "erzeugt" wurde, beim Drücken von F5 wirklich neu geladen werden soll. Das hat genau den gerade beschriebenen Hintergrund.)

Das führt teilweise zu lustigen Formularen, auf denen drei Operationen durch einen Link ausgelöst werden können ("edit", "view", ...) und eine (häufig "delete") durch einen Button. Die meisten Webseiten sind da beeindruckend konsequent.

PS: Ach ja, crash hat's gesagt, aber: POST ist nicht sicherer als GET!

POST-Requests mögen geringfügig umständlicher zu modifizieren sein, aber das ist nichts, was ein Angreifer nicht hinbekommen würde. Jede Nutzereingabe (siehe crashs Post) ist als unsicher zu betrachten. Immer.

 

[Asterixus]

Die meisten $_SERVER-Variablen sind ebenfalls gefährlich.

 

[Alshain]

Frage: Wie machst du denn eine dynamische Page ohne $_GET?

Ich für meinen Teil hätte da so meine Schwierigkeiten einen dynamischen Seitenaufruf hinzubekommen, ohne sehr sehr unkonventionelle Techniken zu verwenden...

:)

Du brauchst ja eine Möglichkeit, um einfach auf spezielle "Wünsche" des Clients einzugehen, also z.B. welche Seite er anzeigen möchte. Dafür ist $_GET ja auch ein ideales Mittel. Natürlich muss ich hier auch meinen Vorgängern zustimmen, dass du den Daten nicht trauen darfst. Im Grunde darfst du keinen Daten trauen, ausser denen die in deinem Script stehen, sonst wird's zuweilen etwas schierig... ;)

D.h. Auch Daten aus einer Datenbank sollte man nicht ohne weiteres grenzenloses Vertrauen entgegen bringen auch wenn "nur dein Script da Dinge hineinschreibt".

Wofür du $_GET und auch alle anderen Superglobalen jedoch nicht verwenden solltest, ist als Möglichkeit sie als Zwischenlager für applikationsinterne Daten zu verwenden. Das ist sehr schlechter Stil und extrem schwierig zu debuggen.

 

[mermshaus]

Du brauchst ja eine Möglichkeit, um einfach auf spezielle "Wünsche" des Clients einzugehen, also z.B. welche Seite er anzeigen möchte.

Das wird gerne als Seiten-/Include-basiertes Design (about.php, contact.php, home.php, ... mit je include 'header.php'; usw.) umgesetzt statt als "FrontController"-Design (index.php?page=home, ...). Auch, weil vielen Leuten nicht bewusst ist, dass mit Rewriting trotzdem "schöne" URLs verwendet werden können.

D.h. Auch Daten aus einer Datenbank sollte man nicht ohne weiteres grenzenloses Vertrauen entgegen bringen auch wenn "nur dein Script da Dinge hineinschreibt".

Ja, am einfachsten ist es, alle Ausgaben von variablen Werten generell durch eine Escape-Funktion zu schicken (wahrscheinlich htmlspecialchars).

 

[Alshain]

Zum Ersten: Ja das stimmt. So sah's auch bei mir mal aus Aber dann reden wir ja auch nicht mehr wirklich von einer dynamischen Seite (tun wir das überhaupt?)
Zu mod_rewrite: Und da kommt ja auch wieder $_GET in's Spiel. PHP bekommt von dem ja nichts mit, für den Besucher sieht es nur so aus als ob kein GET Parameter verschickt wird.