[gelöst][PHP] Problem mit der Verschaltung

[Cyperfriend]

Ich habe mir eine tolle Prüf-Struktur aufgebaut und stolper nun über die Verschaltung.
Der Code ist folgender
[src=php]# Eintrag bearbeiten
if(isset($_POST['b_speichern'])) {

# Variablen in einen reinen String umwandeln.
$_POST['benutzername'] = (string)$_POST['benutzername'];
$_POST['email'] = (string)$_POST['email'];
$_POST['rang'] = (string)$_POST['rang'];

# Prüfen, ob Benutzername und Rang ausgefüllt wurden
if($_POST['benutzername'] && $_POST['rang']) {
# Datenbankverbindung herstellen
$db_connect = db_connect();
# Prüfen, ob der Benutzername im Eingabeformular geändet wurde
if($_POST['benutzername'] != $_POST['org_benutzername']) {
# Falls ein Eintrag gefunden wurde, Vorgang abbrechen
$db_read = "select * from db_benutzer where benutzername='".$_POST['benutzername']."'";
$db_result = mysql_query($db_read, $db_connect) or die (mysql_error());
if(mysql_num_rows($db_result) >= 1){
# Code 21 = "Diesen Benutzer gibt es bereits"
$_SESSION['code'] = 21;
header("Location: http://".$_SERVER['HTTP_HOST']."/neu/inventory/benutzer.html");
}
}
else {
[Änderungen in die Datenbank schreiben]
[/src] Das Problem besteht darin, dass ich bei dieser Konstellation alles ändern kann, aber den Benutzernamen nicht. Es wird einfach verworfen.

Baue ich das alles um und mache es so:
[src=php]# Eintrag bearbeiten
if(isset($_POST['b_speichern'])) {

# Variablen in einen reinen String umwandeln.
$_POST['benutzername'] = (string)$_POST['benutzername'];
$_POST['email'] = (string)$_POST['email'];
$_POST['rang'] = (string)$_POST['rang'];

# Prüfen, ob Benutzername und Rang ausgefüllt wurden
if($_POST['benutzername'] && $_POST['rang']) {
# Datenbankverbindung herstellen
$db_connect = db_connect();
# Prüfen, ob der Benutzername im Eingabeformular geändet wurde
if($_POST['benutzername'] != $_POST['org_benutzername']) {
# Falls ein Eintrag gefunden wurde, Vorgang abbrechen
$db_read = "select * from db_benutzer where benutzername='".$_POST['benutzername']."'";
$db_result = mysql_query($db_read, $db_connect) or die (mysql_error());
if(mysql_num_rows($db_result) >= 1){
# Code 21 = "Diesen Benutzer gibt es bereits"
$_SESSION['code'] = 21;
header("Location: http://".$_SERVER['HTTP_HOST']."/neu/inventory/benutzer.html");
}
else {
[Änderungen in die Datenbank schreiben]
[/src] kann ich den Benutzername ändern und er wird auch geprüft, aber alle anderen Änderungen werden nur gespeichert, wenn gleichzeitig auch der Benutzername geändert wird. Bleibt der Benutzername gleich werden alle Änderungen verworfen.

Irgendwie eine ziemlich doofe Situation und ich weis nicht weiter. Hilft jemand weiter?

 

[evillive]

Re: [PHP] Problem mit der Verschaltung

denn Unterschied sieht man nicht auf anhieb.. ist ja nicht viel geändert worden^^

23,24c23
< }
< else {
---
> else {
26d24
<


-----------

Frage 1

was ist das für ein Schwachsinn?
if($_POST['benutzername'] && $_POST['rang']) {

Frage 2
und hier hast du eine Zuweisung
$_POST['benutzername'] = (string)$_POST['benutzername'];

wann erhälst du jemals hier ein true? wenn du vorher die Zuweisung hattest?
if($_POST['benutzername'] != $_POST['org_benutzername']) { ...}

 

[Shodan]

Re: [PHP] Problem mit der Verschaltung

@Cyperfriend: Nimm Variante 1 und lass das "else" am Ende weg Gibt der User an, dass der Benutzername geändert werden soll und der neue Name ist schon belegt, wird abgebrochen, ansonsten geht es eben weiter. Dass es nicht weiter geht, wenn der Benutzername nicht geändert wird, hast du mit dem else explizit eingebaut.

Und setz hinter den header("Location ...") noch ein exit.


@evillive:
Zu 1: der leere String ist false.
Zu 2: da werden Apfel und Birne verglichen, nicht Apfel und (string) Apfel.

 

[Cyperfriend]

Re: [PHP] Problem mit der Verschaltung

Frage 1

was ist das für ein Schwachsinn?
if($_POST['benutzername'] && $_POST['rang']) {

Gut, dann die saubere Lösung. Hast ja irgendwie recht.
[src=php] if(!empty($_POST['benutzername']) && !empty($_POST['rang'])) {[/src]

Frage 2
und hier hast du eine Zuweisung
$_POST['benutzername'] = (string)$_POST['benutzername'];

Hat man mir hier beigebracht.

wann erhälst du jemals hier ein true? wenn du vorher die Zuweisung hattest?
if($_POST['benutzername'] != $_POST['org_benutzername']) { ...}

Im "Benutzer bearbeiten"-Formular gibt es ein verstecktes Feld, dass nochmal den Namen aus der Datenbank enthält. Die Abfrage prüft, ob der Name geändert wurde und falls ja wird überprüft, ober der neue Name bereits verwendet wird.

Nimm Variante 1 und lass das "else" am Ende weg Gibt der User an, dass der Benutzername geändert werden soll und der neue Name ist schon belegt, wird abgebrochen, ansonsten geht es eben weiter. Dass es nicht weiter geht, wenn der Benutzername nicht geändert wird, hast du mit dem else explizit eingebaut.

Und setz hinter den header("Location ...") noch ein exit.

Perfekt

 

[evillive]

Re: [PHP] Problem mit der Verschaltung

im anderen Thread steht:
$_SESSION['benutzername'] = (string)$_POST['benutzername'];
und du hast:
$_POST['benutzername'] = (string)$_POST['benutzername'];

 

[Cyperfriend]

Re: [PHP] Problem mit der Verschaltung

Ich dachte man soll das grundsätzlich machen ...

 

[evillive]

was meinst du mit deinem letzten posting?

bezüglich

if(!empty($_POST['benutzername']) && !empty($_POST['rang'])) {

sollte isset() verwendet werden, weil bei der Verwendung von empty() eine Warnung kommt, falls die Variable vorher noch nicht da war

bzw. muss da natürlich $_SESSION['benutzername'] stehen und nicht $_POST...

 

[Cyperfriend]

Doch $_POST, weil der Benutzer in der Benutzerverwaltung bearbeitet wird und dort gibt es ja mehrere Benutzer. Kann ja sein, dass ich einen anderen Account bearbeite als meinen eigenen.
Mit meinem letzten Posting meinte ich die Zuweisung von $_POST['bla'] = string($_POST['bla']); Dachte, dass man das grundsätzlich machen soll.
Wenn man empty in diesem Fall nicht nutzt, wann dann oder ist empty ein Relikt aus alten Zeiten und wurde durch isset ersetzt? Wo genau liegt der Unterschied? So wie ich das verstanden habe prüft isset, ob die Variable gesetzt ist, ohne auf den Inhalt zu achten (Hauptsache die Variable ist da) und empty guckt nach, ob in der Variablen auch was drin steht oder eben leer ist.

 

[evillive]

wenn du empty() verwendest und die Variable ist nicht da, dann kommt eine Warnung in der steht, dass der Inhalt einer nicht vorhandenen Variable ausgelesen werden soll.
Damit es keine Warnung gibt musst du mit isset prüfen, ob eine Variable da ist, wenn die Variable nicht da ist dann initialisierst du diese bevor du diese liest.


sry ... mein Fehler irgendwie habe ich das gelesen:
$_POST['benutzername'] = (string)$_POST['org_benutzername'];


edit
natürlich kannst du empty() verwenden. Aber sobald in deinem Formular der Benutzername nicht mehr auftaucht, dann kommt auf jeden Fall die Warnung.

 

[Shodan]

nein, da muss kein $_SESSION stehen, warum sollten hier den Daten in eine Session geschrieben werden? - erledigt

Mir ist da etwas vorhin nicht aufgefallen, sondern erst hier:
>Im "Benutzer bearbeiten"-Formular gibt es ein verstecktes Feld, dass nochmal den Namen aus der Datenbank enthält.<

Auch versteckte Felder kann ein cleverer User verändern und der könnte dann, sofern der [Änderungen in die Datenbank schreiben] Teil genauso funktioniert, einen beliebigen Benutzer editieren. Ich gehe mal davon aus, dass sich dieses Formular hinter deinem Login befindet, und der trägt den Benutzernamen, mit dem man eingeloggt ist, in die Session ein. Nimm hier anstatt $_POST['org_benutzername']) also lieber $_SESSION['benutzername'].
Wird der Benutzername geändert, musst du den dann (also nach dem die DB bestätigt hat) natürlich auch in der Session anpassen.


empty prüft isset.. man, das ist mir jetzt aber peinlich xD Ich editier das hier besser raus, bevor es jemand sieht.

 

[Kugelfisch]

Wenn man ohnehin empty() verwendet, muss man die Existenz der Variablen nicht separat überprüfen, wie in der Dokumentation unter

You do not have permission to view link please Anmelden or Registrieren

erwähnt:

Determine whether a variable is considered to be empty. A variable is considered empty if it does not exist or if its value equals FALSE. empty() does not generate a warning if the variable does not exist.

Allerdings führt

$db_read = "select * from db_benutzer where benutzername='".$_POST['benutzername']."'";

zu einer SQL-Injection-Schwachstelle. Verwende MySQLi und Prepared Statements oder maskiere die Daten zumindest mittels mysql_real_escape_string():

$db_read = "select * from db_benutzer where benutzername='".mysql_real_escape_string($_POST['benutzername'])."'";

 

[Cyperfriend]

You do not have permission to view link please Anmelden or Registrieren

Naja, aber wenn ich als Benutzer "ABC" angemeldet bin steht in der Session logischerweise auch Benutzer = "ABC". Wenn ich nun aber Benutzer "XYZ" bearbeiten will und in der Session steht aber Benutzer = "ABC" dann passt das doch hinten und vorne nicht. Irgendwie verstehe ich die Logik nicht.

 

[Shodan]

Was ich meine ist:
if($_POST['benutzername'] != $_POST['org_benutzername'])
vergleicht zwei Daten, die vom User gesendet wurden. Für ABC steht im versteckten Formularfeld 'org_benutzername' eben 'ABC'. Will er seinen Namen auf 'XYZ' ändern wird der then Block ausgeführt und wenn dieser Name schon belegt ist, dann wird abgebrochen.

Was aber, wenn der Benutzer ABC böse[SUP]TM[/SUP] ist und das versteckte Feld editiert?
Er sendet jetzt sowohl für $_POST['benutzername'] als auch für $_POST['org_benutzername'] ein 'XYZ'. Der then Block wird dann nicht ausgeführt (sind ja identisch) und es wird gar nicht erst geprüft ob der neue Name schon belegt ist.

Da du hier die vom Login gesetzte Session nicht verwendest bin ich einfach mal davon ausgegangen, dass du du auch unten im [Änderungen in die Datenbank schreiben] Teil das $_POST['org_benutzername'] Feld benutzt. Und da dieses vom User gesetzt wurde (und die Prüfung ob der Name existiert übersprungen wurde) editiert er den User 'XYZ'.

Das ist natürlich eine Unterstellung, war spät gestern ;-) Hätte mich sicher klarer ausdrücken können.

Der Punkt ist: du brauchst das 'org_benutzername' Feld gar nicht, sofern dieses Formular hinter dem Login aus dem anderen Thread steht, da der aktuelle (orginal) Benutzername ja in der Session steht. Insbesondere aber musst du dir bewusst machen, dass $_POST vom User mit beliebigen Daten gefüllt werden kann, versteckt hin oder her, und du nur annehmen kannst, was du auch geprüft hast. Die Annahme "in diesem Feld steht der Benutzername des eingeloggten Users" ist ohne eine entsprechende Validierung riskant und wenn eine entsprechende Prüfung möglich ist, dann ist das Feld überflüssig.


Nachtrag:

Kann ja sein, dass ich einen anderen Account bearbeite als meinen eigenen.

Das habe ich übersehen. Wenn der Formularbenutzer beliebige User editieren darf, anstatt nur sich selbst, ist das natürlich gut und richtig den Namen des zu editierenden Users vom Formularbenutzer zu bekommen ;-)
Ich bin davon ausgegangen es gehe darum den eigenen, und nur den eigenen, Account zu editieren.

 

[drfuture]

You do not have permission to view link please Anmelden or Registrieren

schau dir mal das Tutorial hier an

You do not have permission to view link please Anmelden or Registrieren

Das könnte eine kleine inspiration für deine Entwicklung sein - auch wenn es mit diesem Thread nun nicht direkt etwas zu tun hat - so gibt es ja zumindest eine gedankliche Verbindung
Das ganze lässt sich auch für ein Rechtesystem nutzen - um zu steuern welche userklasse was darf