[Corvin]

Wenn ich ein Formular habe, mit welchem ich einen Eintrag aus einer Datenbank bearbeite gibt es zwei Möglichkeiten, die ID des Eintrags an das Skript, das den Eintrag wieder speichert, zu übergeben. Zum einen über das action-Attribut:

<form name="edit_entry" method="post" action="save.php?id=$id">
...
</form> 

Zum anderen mit einem versteckten Feld:

<input type="hidden" name="id" value="$id" /> 

Mir ist gerade aufgefallen, dass ich bei meinen Formularen mal die erste, mal die zweite Möglichkeit nutze. Das will ich natürlich vereinheitlichen.
Daher meine Frage: Welcher Möglichkeit sollte ich den Vorzug geben?
Wenn ich die ID in das action-Attribut mit reinschreibe, erspart mir das natürlich etwas Tipparbeit, aber spricht evt. etwas dagegen?

[MrNiceGuy]

Ich denke, dass es Geschmackssache ist. Ich für meinen Teil habe jedenfalls die zweite Variante gewählt, obwohl ich dabei auch etwas anders verfahre: Alle relevanten, vom Benutzer nicht zu ändernden Daten, speichere ich in der Session in einem Array, der als Key einen MD5-Hash eines microtime() nutzt. Diesen Key schreibe ich dann in das Hidden-Feld und somit bin ich etwas sicherer vor Manipulationen von Außen und der User weiß nicht, welche Informationen ich alles in der Session zurückhalte, die für die Anfrage notwendig sind.

Vielleicht ist das ja auch ein Lösungsansatz für dich!?

[Jann Hendrik]

Auch wenn durch deinen Ansatz nicht mehr Sicherheit gewonnen sein sollte, so ist es zumindest nicht auf Anhieb erkennbar und leicht den Wert zu manipulieren.

[ads]

Der an das Actipn angehängte Wert wird doch als GET ausgewertet, oder? Wenn dein Formular nun per POST übermittelt wird, hast du ein Gemisch beider Methoden. Nimst du ein Hidden Feld, wird dein Wert jeweils passend in den Request eingebaut.

[Corvin]

Zitat von MrNiceGuy

Vielleicht ist das ja auch ein Lösungsansatz für dich!?

In meinem Fall eher nicht. Denn die ID wird, wie alle anderen Felder auch, überprüft bevor sie für eine Datenbankabfrage verwendet wird. Wenn ich irgendwann noch ein Benutzer-System mit unterschiedlichen Rechten implementiere, werde ich natürlich auch überprüfen, ob der Benutzer zu der Aktion, die durchgeführt werden soll, berechtigt ist.
Es ist mir egal, ob der Benutzer dann sehen kann, welche Daten ich vor ihm "verstecke", denn ich will ja garnichts verstecken, sondern nur bestimmte Daten, die für den Benutzer nicht relevant sind, im Browser nicht anzeigen.

Zitat von ads

Der an das Actipn angehängte Wert wird doch als GET ausgewertet, oder? Wenn dein Formular nun per POST übermittelt wird, hast du ein Gemisch beider Methoden. Nimst du ein Hidden Feld, wird dein Wert jeweils passend in den Request eingebaut.

Ja, stimmt.
Mir ist soeben noch eingefallen, dass es auch mal sein kann, dass ich mehr Werte als nur eine ID versteckt übergeben will und dann wäre es ja nicht sinnvoll, das alles ins action-Attribut mit einzubauen, da dann die Übersichtlichkeit des Quellcodes leiden würde.
Ich habe mich daher dazu entschieden, die ID immer über ein verstecktes Input-Feld zu übergeben.

Danke für die Antworten.

[Jann Hendrik]

Aber gerade, wenn da noch mehr Daten übergeben werden sollen finde ich den Lösungsansatz von MrNiceGuy gut. Da hast du nur ein einziges verstecktes Feld - aber die übergebenen Daten sind somit referenzierbar.

Außerdem hat es den Vorteil, dass weniger Daten hin- und her geschoben werden müssen.

[Corvin]

Nunja.. also im Moment greife ich so auf der Werte zu:

PHP-Code:

$id = filter_kram( $_POST['id'] ); 


Das von MrNiceGuy müsste ich erstmal einbauen und ich glaube nicht, dass das von der Performance-Last her einen großen Unterschied macht.

Aber wie gesagt, im Moment ist es sowieso überall nur die ID, die übergeben wird. Wenn es dann mal mehr sein wird, werde ich mir nochmal genauer Gedanken dazu machen. Bis dahin verwende ich ein versteckes Input-Feld.

[ads]

Zitat von Jann Hendrik

Außerdem hat es den Vorteil, dass weniger Daten hin- und her geschoben werden müssen.

Ausserdem muss man diese Daten nur einmal prüfen/validieren.

Wenn man die Daten jeweils durch alle Formulare mit hindurchreicht, muss man alle (wichtigen) Daten bei jedem Zugriff erneut überprüfen.

Nur viele Leute vergessen das gern ... ist halt Aufwand.

[Corvin]

Zitat von ads

Wenn man die Daten jeweils durch alle Formulare mit hindurchreicht

Das ist bei mir ja nicht der Fall. Ich habe zwar mehrere Formulare, aber die haben miteinander nichts zu tun. Daher denke ich, dass ein verstecktes Input-Feld zur Zeit ausreicht.

[MrNiceGuy]

Es war ja auch nur ein Vorschlag

[Sekundentakt]

MrNiceGuy mich als PHP-Neuling würde ein kleines schriftliches Beispiel deiner Variante schon sehr interessieren!

[MrNiceGuy]

OK, ich versuche das "mal eben" etwas näher zu erläutern:

Einem PHP-Script wird zum Beispiel die ID eines Beitrags übermittelt, der editiert werden soll. Was das für ein Beitrag ist spielt erstmal keine Rolle. Damit es nicht zu kompliziert wird nehme ich jetzt einfach an, dass die ID im GET-Parameter "integerUid" steckt (z.B. http://www.domain.tld/script.php?integerUid=123).
Das Script "versteckt" diese ID nun in der Session mittels eines zufallsgenerierten Schlüssels:

PHP-Code:

<?php
// Eine simple Prüfung der übergebenen Variable. Nagelt mich nicht hierdrauf fest, es ist nur ein Beispiel!
if (is_numeric ($_GET['integerUid']) === FALSE)
{
  die ('Manipulationsversuch!');
}
else
{
  $_GET['integerUid'] = intval ($_GET['integerUid']);
}

// Solange einen neuen Key generieren, bis ein nicht bereits vorhandener erstellt wurde (die Chance ist zwar gering, aber der Teufel ist ja ein Eichhörnchen)
do
{
  $stringKey = md5 (microtime ());
}
while (array_key_exists ($stringKey,
                         $_SESSION['arrayFormularData']
                         ) === TRUE
       );

// Setzen der Variablen
$_SESSION['arrayFormularData'][$stringKey] = array ('integerUid' => $_GET['integerUid']);
?>

Somit ist die "integerUid" nun in der Session gespeichert. Der Key, um darauf zuzugreifen befindet sich noch in $stringKey und dieser wird nun in das Formular eingefügt:

<form method="post" action="script.php">
<input type="hidden" name="stringValidationKey" value="<?php echo $stringKey;?>"/>
<!-- Hier die weiteren Formular-Felder, die editiert werden sollen (in einem Forum z.B. "Thema" und "Text") -->
<input type="submit" name="buttonSend" value="Speichern"/>
</form>

Die Ausgabe erfolgt in dem Beispiel jetzt innerhalb des PHP-Scripts selbst. Das muss halt an die eigenen Gegebenheiten angepasst werden.

Nun ist es so, dass nur die Daten, die geändert werden dürfen auch übergeben werden und halt der Key, der auf das Array zeigt, welches die nicht zu ändernden Variablen enthält (im Beispiel nur die Uid).
Das Script, das jetzt aufgerufen wird greift dann wie folgt darauf zurück:

PHP-Code:

<?php
// Prüfen, ob ein Schlüssel, wie der übergebene in der Session vorhanden ist
if (array_key_exists ($_POST['stringValidationKey'],
                      $_SESSION['arrayFormularData']
                      ) === FALSE
    )
{
  die ('Validierung fehlgeschlagen!');
}

// Eine Referenz in $arrayFormularData speichern, um sich später eventuell ein bisschen Tipp-Arbeit zu ersparen
$arrayFormularData = &$_SESSION['arrayFormularData'][$_POST['stringValidationKey']];

// Achtung: Die übergebenen Werte müssen vorher natürlich entsprechend geprüft werden!
mysql_query ('UPDATE `table` SET `column`=\''.$_POST['stringValue'].'\' WHERE `uid`=\''.$arrayFormularData['integerUid'].'\' LIMIT 1');
?>

Ich hoffe, dsas dadurch etwas klargeworden ist, wie das funktionieren kann. Es ist natürlich nicht gesagt, dass es immer so gemacht werden MUSS. Wenn du andere Ideen hast, kannst du die da natürlich mit einbringen. Ansonsten hast du auf diese - wie ich finde recht einfache - Weise jedenfalls eine gute Möglichkeit, um Variablen sicher vor den Benutzern zu "verstecken" bzw. unveränderbar zwischen zu speichern.

Falls du noch fragen hast: Frag

[Sekundentakt]

Hallo,

danke für deine ausführliche Antwort!
Doch ein paar Fragen habe ich dennoch.
IntergerUID - ist das eine Funktion oder hast du das jetzt einfach so genannt? Normalerweise nenne ich meine IDs nur "ID", darum frage ich.

Deine While-Schleife im ersten Codeschnipsel ergibt für mich keinen Sinn, was soll denn da so lange getan werden? Mir ist schon klar: So lange diese Daten existieren, ist diese Schleife wahr, ... ja und? Was passiert als nächstes?

Zu der Zeile wo steht //Setzen der Variablen:
mit => weißt du einem bestimmten Arraykästchen einen bestimmten Wert zu? (Anfängerfrage! )

DAnke!

[MrNiceGuy]

Ich nenne meine Variablen immer erst mit der Art des Inhaltes, den die Variable haben soll ("string", "integer", "boolean", etc.). Es ist also einfach nur ein Integer, der in "integerUid" enthalten sein soll

Die While-Schleife wird im Idealfall nur ein Mal durchlaufen, aber sollte es - aus welchen Gründen auch immer - den Key bereits geben, wird die Schleife noch ein zweites, drittes, x-tes Mal durchlaufen, bis ein Key generiert wurde, den es noch nicht gibt. Die Wahrscheinlichkeit, dass es mehr als ein Mal durchlaufen werden muss ist sehr gering, aber für diesen 1 zu 10 Milliarden-Fall ist es denke ich nicht verkehrt ihn einzubauen. Kostet ja nun nicht so wirklich viel Rechenleistung

Falls dir einfach das do { ... } while (); nur kein Begriff ist, dann solltest du dir das mal im PHP-Manual anschauen! Ich bin zwar nicht mehr 100%ig sicher, ob die Bezeichnung "Fußgesteuerte Schleife" richtig ist, aber dieses Konstrukt ist in manchen Fällen ganz sinnvoll, wie in dem Beispiel oben halt

Mit der Funktion array() erstellst du eine Variable mit einem Array als Inhalt. Du hast die Möglichkeit einfach Werte mit Komma getrennt zu übergeben, dann hast du hinterher ein Array mit numerischen Schlüsseln von 0 bis x (x = Anzahl der Elemente im Array - 1). Du kannst aber auch assoziative Arrays erstellen, bei denen du mit einem String-Schlüssel auf einen Wert zugreifst, was in den meisten Fällen deutlich einfacher ist. In diesem Fall erfolgt dann die Übergabe in array() mittels " 'key' => 'wert' ", statt einfach nur " 'wert' ". Zugreifen kannst du darauf dann über $arrayDiesIstDeinArray['key'].

[Chrunchy]

@MrNiceGuy,

kannst du mir erklären, warum du das ganze nicht einfach in eine Session-Variable speicherst?
Dann kann man sich doch die ganze Übergabe per Formular sparen, oder habe ich da jetzt einen Denkfehler?

Gruß Chrunchy

[Basti]

Zitat von Chrunchy

kannst du mir erklären, warum du das ganze nicht einfach in eine Session-Variable speicherst?
Dann kann man sich doch die ganze Übergabe per Formular sparen, oder habe ich da jetzt einen Denkfehler?

Das geht natürlich, wenn du deine komplette Anwendung im Blick hast. Andernfalls, also wenn du z.B. auf diese Art und Weise Module für dein System programmierst, kannst du ja nicht sicherstellen, dass hier nicht Variablen überschrieben bzw. aus einem anderen Formular stammen, falls der Benutzer mehrere Tabs offen hat.

Beispiel:
Du setzt sowas um, um einen Suchagenten einzurichten. Der benutzer ist gerade dabei und hat damit implizit das Feld $_SESSION['search'] gesetzt. Jetzt will er nochmal was nachschauen und offnet deine Site nochmal im neuen Tab und dort wird das Standard-Suchfeld angezeigt, dass dir $_SESSION['search'] vielleicht wieder durch einen leeren String überschreibt.

Geschickter ist es, für sowas z.B. ein Wizard-Objekt zu erzeugen, das die entsprechenden Daten, sowie einen Status sammelt und dann eben unter einer bestimmten ID in die Session gelegt wird.

So wird auch deutlicher, dass es sich um eine Einheit unterschiedlicher Daten (Benutzereingaben) handelt.

Wichtig ist hier (wie natürlich auch generell), zu gewährleisten, mögliche CSRF-Angriffe zu verhindern. so könnte z.B. ein Benutzer ohne die entsprechenden Rechte eine solche Session mit den entsprechenden Daten fällen und dem Admin einen Link unterjubeln, auf diese Session aufzuspringen und dann, ohne es zu merken den Mist auszuführen, der ihm da untergejubelt wurde.

Also immer gucken, wie die daten in die Session kommen und natürlich beim ersten Request keine vorgefertigten SIDs übernehmen, sowie beim Statuswechsel (z.B. Log-In) eine neue Session mit neuer SID starten und nur (wenn überhaupt) die relevanten Daten rüberkopieren.

Bastian

[MrNiceGuy]

Tcha, da hat Basti doch glatt vorgemuckt... Du Schlingel

[Basti]

Schlingel? Sollte mir mal passieren, dass ich morgens ins Büro komme und der ganze Mist schon runtergeschrieben wäre! (Äh nein, ich steh grad auf meine Arbeit – gibt ja auch Zeiten, in denen es mal nicht so Spaß macht…-)

Bastian

[Sekundentakt]

@ Mr.Niceguy, ich glaube ich hab das Script soweit erst mal verstanden.
Bastis Posting hat mein Verständnis dann aber schon wieder völlig über den Haufen geschmissen .

Geschickter ist es, für sowas z.B. ein Wizard-Objekt zu erzeugen, das die entsprechenden Daten, sowie einen Status sammelt und dann eben unter einer bestimmten ID in die Session gelegt wird.

So wird auch deutlicher, dass es sich um eine Einheit unterschiedlicher Daten (Benutzereingaben) handelt.

Mit letzterem meinst du z.B. auch Passwörter?
Was sind Wizardobjekte? Extrascriptsprachen oder eine bestimmte PHP Technik?

Danke euch beiden!

[Basti]

Diese Technik setzt man ja dann ein, wenn man mehrere Formulare hintereinander an den Benutzer schickt. Das kann ein Wizard sein oder z.B. ein Quiz, eine Befragung etc.

In dem Fall macht es ja Sinn, dieses „Etwas“ als Obekt abzubilden, das man dann eben in die Session legt.

Bastian