Onkel Hans: Datensatzlöschung kontrollieren

Hi!

Bei der Ausgabe von Datensätzen aus einer MYSQL-Datenbank ist bei jedem Datensatz dessen Löschung möglich. Die entsprechende ID wird mit der URL an jene php-Ressource, die für die Löschung des Datensatzes zuständig ist, übergeben.

Nachdem ich geprüft habe, ob es einen Datensatz mit der entsprechenden ID überhaupt gibt, wird dieser gelöscht. Das habe ich so realisiert:

// Die Verbindung zur DB wird hergestellt:  
include('db_connect.php');  
  
// Der Datensatz mit der übergebenen und überprüften ID wird gelöscht:  
$loeschung=$db->query("DELETE FROM `11_dbtest` WHERE `id`=$id");  
  
// Die Verbindung zur DB wird geschlossen:  
include('db_disconnect.php');

Soweit funktioniert das auch. Nun dachte ich, es sei gut, codeseitig zu kontrollieren, ob es zu einer Löschung gekommen ist. Dazu habe ich nach dem $loeschung=$db->query... Folgendes hinzugefügt:

// Überprufung, ob der Datensatz gelöscht worden ist:  
if($loeschung->affected_rows==1)  
  {  
    echo"<p>Löschung erfolgreich.</p>\n";  
  }  
else  
  {  
    echo"<p>Löschung nicht erfolgreich.</p>\n";  
  }

Leider bekomme ich da immer den Warnhinweis "Notice: Trying to get property of non-object in ... on line ..." (die entsprechende Zeile ist jene mit der if-Klausel) sowie die Ausgabe "Löschung nicht erfolgreich". Und das, obwohl der Datensatz _sehr wohl_ wie gewünscht gelöscht wird.

Kann mir bitte wer sagen, was an meinem Code da nicht stimmt, dass es zu dieser Warnung kommt? Beim objektorientierten Beispiel unter mysqli->affected_rows im php-Handbuch wird es doch auch so gemacht, wie ich es getan habe. =/

Danke!

Onkel Hans

  1. Hi,

    $loeschung=$db->query("DELETE FROM 11\_dbtest WHERE id=$id");
    if($loeschung->affected_rows==1)

    Kann mir bitte wer sagen, was an meinem Code da nicht stimmt, dass es zu dieser Warnung kommt? Beim objektorientierten Beispiel unter mysqli->affected_rows im php-Handbuch wird es doch auch so gemacht, wie ich es getan habe. =/

    $mysqli->query("DELETE FROM Language WHERE Percentage < 50");
    printf("Affected rows (DELETE): %d\n", $mysqli->affected_rows);

    Ich sehe da einen deutlichen Unterschied.
    Du versuchst, ->affected_rows auf das anzuwenden, was $db->query(...) zurückgibt.
    Dort im Beispiel wird ->affected_rows auf das Objekt angewendet, auf das auch ->query angewendet wird (dort ist das $mysqli, bei Dir wäre das $db)

    cu,
    Andreas

    --
    Warum nennt sich Andreas hier MudGuard?
    O o ostern ...
    Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.
    1. Hi Andreas,

      Danke für Deine Hilfe!

      Ich sehe da einen deutlichen Unterschied.
      Du versuchst, ->affected_rows auf das anzuwenden, was $db->query(...) zurückgibt.
      Dort im Beispiel wird ->affected_rows auf das Objekt angewendet, auf das auch ->query angewendet wird (dort ist das $mysqli, bei Dir wäre das $db)

      Du hast Recht, wenn ich meinen ursprünglichen Code auf if($db->affected_rows==1) ändere, dann erscheint der Warnhinweis nicht mehr. Und ich sehe auch auf der Handbuchseite jetzt, dass ich das affected_rows auf die Datenbankverbindung bezieht.

      Nur _verstehen_ tue ich das nicht so ganz. Wenn ich  mir folgende Zeile ansehe:

      $loeschung=$db->query("DELETE FROM 11_dbtestWHEREid=$id");

      Dann interpretiere ich das so: Das Query, das zur Löschung aller Datensätze mit einer erfüllten Bedingung führt, wird über die vorher eröffnete Datenbankverbindung "$db" an die Datenbank gesendet. Und dieser Vorgang, also das Senden des Querys, heißt "$loeschung". Und ich möchte ja wissen, wie viele Datensätze waren von diesem gesendeten Query betroffen, also wäre da nicht if($loeschung->affected_rows==1) logischer?

      Liebe Grüße

      Onkel Hans

      1. Hi,

        $loeschung=$db->query("DELETE FROM 11_dbtestWHEREid=$id");

        Dann interpretiere ich das so: Das Query, das zur Löschung aller Datensätze mit einer erfüllten Bedingung führt, wird über die vorher eröffnete Datenbankverbindung "$db" an die Datenbank gesendet. Und dieser Vorgang, also das Senden des Querys, heißt "$loeschung".

        Du legst den Rückgabewert der Query in einer Variable namens $loeschung ab.

        query gibt zurück:

        Returns FALSE on failure. For successful SELECT, SHOW, DESCRIBE or EXPLAIN queries mysqli_query() will return a result object. For other successful queries mysqli_query() will return TRUE.

        Da DELETE nicht in (SELECT, SHOW, DESCRIPTE, EXPLAIN) ist, enthält $loeschung also TRUE oder FALSE, je nachdem ob die Löschung geklappt hat oder nicht.

        Weder TRUE->affected_rows noch FALSE->affected_rows ergibt irgendeinen Sinn.

        Statt irgendwelche Dinge da reinzuinterpretieren, solltest Du schlicht und einfach das Handbuch für die von Dir verwendeten Funktionen angucken. Das hilft mehr als wildes Rumraten.

        cu,
        Andreas

        --
        Warum nennt sich Andreas hier MudGuard?
        O o ostern ...
        Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.
        1. Hi!

          Statt irgendwelche Dinge da reinzuinterpretieren, solltest Du schlicht und einfach das Handbuch für die von Dir verwendeten Funktionen angucken. Das hilft mehr als wildes Rumraten.

          Und mit var_dump() nachschauen, was wirklich da ist. var_dump($loeschung) zeigte in dem Fall ein FALSE. Aber auch wenn ein Objekt zurückkäme, könnte man sehen, welcher Klasse es angehört und dann im Handbuch nachschlagen, welche Methoden und Eigenschaften zur Verfügung stehen.

          $loeschung=$db->query("DELETE FROM 11_dbtestWHEREid=$id");

          @Hans: Probier das mal mit

          $id = "0 OR 1";

          dann ist der Datensatz garantiert gelöscht. Allerding auch noch der eine oder andere mehr. Lösung: Kontextwechsel beachten.

          Ist es wirklich notwendig den Erfolg der Löschung anhand der Anzahl der betroffenen Datensätze festzumachen? Aus dem Problem entnehme ich, dass keine Fehlerbehandlung stattfindet, der Rückgabewert von mysli::query() nicht auf Fehler (false) oder Erfolg (true) ausgewertet wird. Wenn es nicht wichtig ist, ob tatsächlich _ein_ Datensatz gelöscht wurde, sondern nur festgestellt werden soll, ob die Operation fehlerhaft war (warum auch immer) oder erfolgreich verlief (auch wenn nichts gelöscht werden konnte), dann reicht auch die normale Fehlerbehandlung (die immer wieder gern unter den Tisch fällt).

          Lo!

          1. Hi,

            @Hans: Probier das mal mit
              $id = "0 OR 1";
            dann ist der Datensatz garantiert gelöscht. Allerding auch noch der eine oder andere mehr. Lösung: Kontextwechsel beachten.

            Um Gottes Willen! Genau wegen hunderter _Deiner_ Postings hier würd ich mich _nie_ trauen, eine per URL übergebene Variable einfach ungeprüft zu verarbeiten! Nein nein, da hast Du mich schon indoktriniert!!!!

            In diesem speziellen Fall handelt es sich bei der ID um eine ganze Zahl. Zumindest wird eine solche bei der Übergabe erwartet. Etwas weiter oben in meinem Code steht:

            if((!ISSET($_GET['id']))OR(intval($_GET['id'])==0))  
              {  
                echo"<p>Sie haben entweder keinen oder einen falschen Wert für eine zu löschende ID übergeben.<br />Kein Löschvorgang möglich!</p>\n";  
              }  
            else  
              {  
                $id=intval($_GET['id']);  
                // ... weitere Verarbeitung ...  
              {
            

            Ich hab das nur nicht erwähnt bzw. mit hingeschrieben, weil ich mein Posting as small as possible halten wollte und das nicht mein Problem betroffen hat.

            Liebe Grüße

            Inkel Hans

            1. Hi!

              Um Gottes Willen! Genau wegen hunderter _Deiner_ Postings hier würd ich mich _nie_ trauen, eine per URL übergebene Variable einfach ungeprüft zu verarbeiten! Nein nein, da hast Du mich schon indoktriniert!!!!

              Na dann ist ja gut.

              $id=intval($_GET['id']);

              Davon sieht man nur bei der eigentlichen Query nichts mehr und deswegen gehen bei mir die Alarmglocken los.

              Beachte auch noch ChrisBs Einwurf, dass GET nicht für datenändernde Requests geeignet ist.

              Lo!

              1. Hi,

                übrigens ... um Deine Frage nach

                Ist es wirklich notwendig den Erfolg der Löschung anhand der Anzahl der betroffenen Datensätze festzumachen?

                zu beantworten: Ich bilde mir ein, hier mal schon gelesen zu haben, man soll nicht blind "Datensatz gespeichert" oder "Datensatz gelöscht" schreiben, wenn man gar nicht weiß, ob das auch stimmt.

                Und _deshalb_ prüfe ich das bzw. möchte es prüfen. Erst wenn ich durch das affected_rows==1 weiß, dass es zu einer entsprechenden Aktion gekommen ist, gebe ich die Bestätigung aus. Ansonsten wird ein "Es konnte kein Datensatz gelöscht werden!" ausgegeben.

                Es kann natürlich sein, dass man dies im Code eleganter und einfacher schreiben kann, nur weiß ich dann davon noch nichts. :-)

                Liebe Grüße

                Onkel Hans

                1. Hi!

                  Ist es wirklich notwendig den Erfolg der Löschung anhand der Anzahl der betroffenen Datensätze festzumachen?
                  zu beantworten: Ich bilde mir ein, hier mal schon gelesen zu haben, man soll nicht blind "Datensatz gespeichert" oder "Datensatz gelöscht" schreiben, wenn man gar nicht weiß, ob das auch stimmt.

                  Stimmt schon, man muss ja nicht unbedingt etwas hinschreiben, von dem man nur annimmt, dass es so war. Die Frage, die man sich jedoch stellen sollte ist, interessiert es in dem Fall wirklich, wieviele Datensätze gelöscht wurden oder reicht das Wissen um eine fehlerfreie Ausführung. Vielleicht hat ja parallel schon jemand gelöscht, dann ist das Ergebnis ja auch wie erwartet: Datensatz ist weg - nur war es eben jemand anderes.

                  Wie auch immer, die Abfrage der betroffenen Datensätze kostet nicht viel, sie in die Ausgabe der Reaktion auf die Handlung einzubauen, ist auch kein Akt. Aber wichtiger als diese Information der betroffenen Datensätze ist die Prüfung auf generelle Fehlerfreiheit der Ausführung. Dafür sollte man jedoch nicht solche "Sekundärinformation" heranziehen, sondern die bereits von den verwendeten Funktionen gelieferten Informationen auswerten. Und dann könnte die Logik so aussehen:

                  if query(...)
                    echo (class=ok) Aktion fehlerfrei, betroffene Datensätze: affected_rows.
                  else
                    echo (class=error) Fehlerhaft.
                    administratorbenachrichtigung(error_text)

                  Ob der Anwender dann bei fehlerfreier Ausführung und 0 betroffenen auf die Suche geht, um nachzuschauen, ob der Datensatz trotzdem weg ist, ist seine Sache. Aber bei einem "Löschung nicht erfolgreich" wenn affected_rows als Ergebnis 0 liefert, weiß man nicht, ob es einen Fehler bei der Ausführung gab oder "nur" der Datensatz auf anderen Wegen gegangen worden ist. Man müsste dann eigentlich auf alle Fälle auf Ursachenforschung gehen, nur um dann festzustellen, dass doch schon alles in Butter ist. Beim nächsten Mal denkt man sich das auch und übergeht so einen echten Fehler.

                  Und zu guter Letzt könntest du auf die Idee kommen, das Prinzip der Abfrage nach den affected_rows statt dem Returnwert von query() auch auf UPDATE-Statements anzuwenden. Und da bekommst du wesentlich öfter 0 affected_rows, nämlich dann, wenn der Anwender keine Änderung gegenüber dem gespeicherten Datensatz macht (Anwender ruft einen Datensatz auf, ändert nichts, aktiviert trotzdem die Speichern-Funktionalität). query() liefert dann true, aber affected_rows ergibt 0, weil es nichts zu ändern gab. (Wobei es hierfür in MySQL eine Einstellmöglichkeit gibt, über die man entscheiden kann, ob man die wirklich geänderten oder alle von der WHERE-Klausel eingeschlossenen Datensätze gezählt haben will.)

                  Lo!

                  1. Hi,

                    zunächst mal vielen Dank für diese sehr interessante Ausführung und die dahinter stehenden Überlegungen! Deinen Text verstehe ich, nur der von Dir skizzierte Code bereitet mir etwas Schwierigkeiten.

                    if query(...)
                      echo (class=ok) Aktion fehlerfrei, betroffene Datensätze: affected_rows.
                    else
                      echo (class=error) Fehlerhaft.
                      administratorbenachrichtigung(error_text)

                    Da verstehe ich mehreres nicht. Ich habe gelernt, dass die if-Klausel _immer_ in Klammern stehen muß, wieso steht das 'query' also außerhalb von Klammern? Und wenn ich als if-Bedingung einen Query nehme, was ist da die Bedingung? Ich meine: Bei if($a==2) ist es klar: Wenn $a den Wert 2 hat, dann... - aber was bedeutet if(...query...)?

                    Wenn ich bei $sql="SELECT id, vorname, familienname, geburtsjahrFROM11_dbtestWHEREid=$id"; mit var_dump($sql); überprüfe, was hinter $sql steht, bekomme ich folgende Ausgabe:

                    string(83) "SELECT id, vorname, familienname, geburtsjahr FROM 11\_dbtest WHERE id=4" bool(true)

                    Was sagt mir denn da das 'bool(true)' zum Schluß? Und vermute ich das richtig, dass die von Dir gemeinte if-Klausel überprüft, ob dieser bool-Wert wahr oder falsch ist?

                    Außerdem überlege ich gerade, wie ich das von Dir vorgeschlagene Procedere umsetzen kann/soll, bei folgendem Code, der jetzt noch ohne Überprüfung einfach blind behauptet, dass der gewünschte Datensatz gelöscht worden ist:

                    include('db_connect.php');  
                    $sql="SELECT `id`, `vorname`, `familienname`, `geburtsjahr` FROM `11_dbtest` WHERE `id`=$id";  
                    $ausgabe=$db->prepare($sql);  
                    $ausgabe->execute();  
                    $ausgabe->bind_result($id, $name, $familie, $jahr);  
                    $ausgabe->fetch();  
                    $ausgabe->close();  
                    $loeschung=$db->query("DELETE FROM `11_dbtest` WHERE `id`=$id");  
                    echo"<p>".$name." ".$familie." (Geburtsjahr ".$jahr.") mit der ID ".$id." wurde gelöscht.</p>\n";  
                    include('db_disconnect.php');
                    

                    Liebe Grüße

                    Onkel Hans

                    1. Hi,

                      if query(...)
                        echo (class=ok) Aktion fehlerfrei, betroffene Datensätze: affected_rows.
                      else
                        echo (class=error) Fehlerhaft.
                        administratorbenachrichtigung(error_text)

                      Da verstehe ich mehreres nicht. Ich habe gelernt, dass die if-Klausel _immer_ in Klammern stehen muß, wieso steht das 'query' also außerhalb von Klammern?

                      Weil das lediglich Pseudocode ist ...

                      Und wenn ich als if-Bedingung einen Query nehme, was ist da die Bedingung? Ich meine: Bei if($a==2) ist es klar: Wenn $a den Wert 2 hat, dann... - aber was bedeutet if(...query...)?

                      Dass du an dieser Stelle den Rückgabewert der Funktion, die die Query ausführen lässt, auswertest - um zu erfahren, ob bei der Ausführung ein Fehler auftrat oder nicht.

                      MfG ChrisB

                      --
                      RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
                      1. Hi,

                        Dass du an dieser Stelle den Rückgabewert der Funktion, die die Query ausführen lässt, auswertest - um zu erfahren, ob bei der Ausführung ein Fehler auftrat oder nicht.

                        ich verstehe nicht, was Du meinst. Bei $loeschung=$db->query("DELETE FROM 11_dbtestWHEREid=$id"); soll ich jetzt if($loeschung) schreiben??? Und woher weiß ich, ob ein Fehler aufgetreten ist oder nicht?

                        Liebe Grüße

                        Onkel Hans

                        1. Hi,

                          ich verstehe nicht, was Du meinst. Bei $loeschung=$db->query("DELETE FROM 11_dbtestWHEREid=$id"); soll ich jetzt if($loeschung) schreiben??? Und woher weiß ich, ob ein Fehler aufgetreten ist oder nicht?

                          Bitte informiere dich in der Dokumentation zur der Datenbankklasse, die du da verwendest, was der Rückgabewert ihrer query-Methode aussagt.

                          MfG ChrisB

                          --
                          RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
                          1. Hi,

                            Bitte informiere dich in der Dokumentation zur der Datenbankklasse, die du da verwendest, was der Rückgabewert ihrer query-Methode aussagt.

                            wie ich schon mal sagte, bin ich, was Datenbanken betrifft, ein absoluter Trottel und jeder Blick in ein "Handbuch" verwirrt mich als Nichtinformatiker noch mehr, als dass er mir helfen würde. :-(

                            Ich verwende eine MYSQL Datenbank und arbeite mit 'mysqli' bei der Verbindung zu selbiger. Ich weiß jetzt nicht wirklich, wo ich wonach suchen soll. Und wenn ich es wüßte, würd ich es wohl auch nicht verstehen.

                            Also meine Ursprungsfrage, wie der Vorschlag von dedlfix umzusetzen ist, läßt sich nicht anhand eines praktischen Beispiels erklären?

                            Liebe Grüße

                            Onkel Hans

                            1. Hi,

                              Bitte informiere dich in der Dokumentation zur der Datenbankklasse, die du da verwendest, was der Rückgabewert ihrer query-Methode aussagt.

                              wie ich schon mal sagte, bin ich, was Datenbanken betrifft, ein absoluter Trottel und jeder Blick in ein "Handbuch" verwirrt mich als Nichtinformatiker noch mehr, als dass er mir helfen würde. :-(

                              Dann *lerne*, mit dem Handbuch umzugehen.

                              Ich verwende eine MYSQL Datenbank und arbeite mit 'mysqli' bei der Verbindung zu selbiger. Ich weiß jetzt nicht wirklich, wo ich wonach suchen soll. Und wenn ich es wüßte, würd ich es wohl auch nicht verstehen.

                              Du benutzt die query-Methode des MySQLi-Objektes - also schaust selbstverständlich bei genau deren Beschreibung nach: http://www.php.net/manual/en/mysqli.query.php
                              Da steht, was die Methode zurück gibt - und wie sich also der Fehlerfall erkennen lässt.

                              MfG ChrisB

                              --
                              RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
                              1. Hi,

                                Bitte informiere dich in der Dokumentation zur der Datenbankklasse, die du da verwendest, was der Rückgabewert ihrer query-Methode aussagt.

                                wie ich schon mal sagte, bin ich, was Datenbanken betrifft, ein absoluter Trottel und jeder Blick in ein "Handbuch" verwirrt mich als Nichtinformatiker noch mehr, als dass er mir helfen würde. :-(

                                Dann *lerne*, mit dem Handbuch umzugehen.

                                Es hilft ja nichtmal was, wenn man's ihm vorliest

                                cu,
                                Andreas

                                --
                                Warum nennt sich Andreas hier MudGuard?
                                O o ostern ...
                                Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.
                    2. Hi!

                      if query(...)
                        echo (class=ok) Aktion fehlerfrei, betroffene Datensätze: affected_rows.
                      else
                        echo (class=error) Fehlerhaft.
                        administratorbenachrichtigung(error_text)

                      Da verstehe ich mehreres nicht. Ich habe gelernt, dass die if-Klausel _immer_ in Klammern stehen muß, wieso steht das 'query' also außerhalb von Klammern?

                      Ich schrieb ja auch, dass das nur die Logik verdeutlichen soll. Es ist also kein PHP-Code, soll nur zeigen, wie ich es meine.

                      aber was bedeutet if(...query...)?

                      Der Rückgabewert ist entweder false oder evaluiert im booleschen Kontext (also bei if) zu true. Daraus kann man sehen, ob ein Fehler auftrat oder die Query abgearbeitet werden konnte (auch dann wenn keine Ergebnismenge entstand oder kein Datensatz betroffen war).

                      Wenn ich bei $sql="SELECT id, vorname, familienname, geburtsjahrFROM11_dbtestWHEREid=$id"; mit var_dump($sql); überprüfe, was hinter $sql steht, bekomme ich folgende Ausgabe:
                      string(83) "SELECT id, vorname, familienname, geburtsjahr FROM 11\_dbtest WHERE id=4" bool(true)
                      Was sagt mir denn da das 'bool(true)' zum Schluß?

                      Das bool(true) kommt von einer zweiten var_dump()-Ausgabe oder einem zweiten Argument.

                      Außerdem überlege ich gerade, wie ich das von Dir vorgeschlagene Procedere umsetzen kann/soll, bei folgendem Code, der jetzt noch ohne Überprüfung einfach blind behauptet, dass der gewünschte Datensatz gelöscht worden ist:

                      Du sollst die Rückgabewerte der verwendeten Funktionen auswerten. Wenn du das hast, kannst du weitere Informationen dazunehmen, wie beispielsweise die affected_rows-Angabe.

                      Lo!

  2. Hi,

    Bei der Ausgabe von Datensätzen aus einer MYSQL-Datenbank ist bei jedem Datensatz dessen Löschung möglich. Die entsprechende ID wird mit der URL an jene php-Ressource, die für die Löschung des Datensatzes zuständig ist, übergeben.

    Das per GET zu machen, ist gefährlich.
    Da kann dir schon ein Suchmaschinen-Bot, der die Links abgrast, alle Datensätze löschen.
    Und selbst wenn als zusätzliche Sicherungsmaßnahme der aktuelle Benutzer eingeloggt sein muss, um Löschen zu dürfen, kann immer noch ein „Prefetch“-Feature im Browser o.ä. das gleiche bewirken.

    Faustregel: Für Daten verändernde Requests immer POST nehmen.

    MfG ChrisB

    --
    RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
    1. Hi,

      Das per GET zu machen, ist gefährlich.
      Da kann dir schon ein Suchmaschinen-Bot, der die Links abgrast, alle Datensätze löschen.
      Und selbst wenn als zusätzliche Sicherungsmaßnahme der aktuelle Benutzer eingeloggt sein muss, um Löschen zu dürfen, kann immer noch ein „Prefetch“-Feature im Browser o.ä. das gleiche bewirken.
      Faustregel: Für Daten verändernde Requests immer POST nehmen.

      es handelt sich hier für mich nur um eine Übung, also um nichts Reales/Relevantes und es geht in diesem speziellen Fall darum, dass in einer Datenbank die Namen und Adressen von Vereinsmitgliedern gespeichert werden. Dabei erhält jedes Vereinsmitglied bei der Speicherung des Datensatzes eine unique ID, die gleichzeitig seine Mitgliedsnummer ist.

      Und nun habe ich eine Seite für den Admin dieses Vereins, wo alle Mitglieder ausgegeben werden und hinter dem Namen jeweils ein VERÄNDERN und ein LÖSCHEN-Link ist. Und an _diesen_ Link wird jetzt die Mitgliedsnummer, also die ID, angehängt, um dann auf der nächsten Seite, also von der nächsten PHP Ressource, die Daten entweder verändert bzw. gelöscht zu bekommen.

      Es handelt sich also um keine Log-In Sache oder ähnlich Heikles. Und wie Du an meinem Antwortposting an dedlfix sehen kannst, kümmere ich mich auch darum, dass wirklich nur, so wie erwartet, eine ganze Zahl als ID weiterverarbeitet wird.

      Danke für den Input!

      Liebe Grüße

      Onkel Hans

      1. Hi,

        Und nun habe ich eine Seite für den Admin dieses Vereins, wo alle Mitglieder ausgegeben werden und hinter dem Namen jeweils ein VERÄNDERN und ein LÖSCHEN-Link ist.

        Und eben damit hast du u.U. bereits das Problem, wenn man ein Browser benutzt wird, der ein Prefetch-Feature hat.

        Lass das in einer neuen Version mal per Default aktiviert sein - ein Aufruf der Seite, alle Datensätze futsch.

        MfG ChrisB

        --
        RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
        1. Hi,

          Und eben damit hast du u.U. bereits das Problem, wenn man ein Browser benutzt wird, der ein Prefetch-Feature hat.
          Lass das in einer neuen Version mal per Default aktiviert sein - ein Aufruf der Seite, alle Datensätze futsch.

          Den Fall hat es schon mal gegeben, irgendeine 2.x Firefox-Version hatte das per Default an (wurde allerdings, IIRC, innerhalb weniger Stunden durch ein weiteres Update umgestellt)

          cu,
          Andreas

          --
          Warum nennt sich Andreas hier MudGuard?
          O o ostern ...
          Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.
        2. Hi,

          Und eben damit hast du u.U. bereits das Problem, wenn man ein Browser benutzt wird, der ein Prefetch-Feature hat.

          der Begriff 'Prefetch-Feature' sagt mir überhaupt nichts. Verstehe ich die Ergebnisse meiner GOOGLE-Recherche richtig, dass es dabei darum geht, dass Browser URLs auf einer Seite schon vorladen, um bei evt. Verlinkung selbiger diese dann schneller anzeigen zu können?

          Lass das in einer neuen Version mal per Default aktiviert sein - ein Aufruf der Seite, alle Datensätze futsch.

          Super, jetzt habe ich 20 Minuten an einer Antwort geschrieben, in der ich Dir erklären wollte, wieso das bei meiner Lösung zu keinem Problem führen dürfte und beim Rechtschreib-Korrekturlesen ist mir dann die Unlogik meiner eigenen Argumentation aufgefallen. :-(

          OK, also sobald ein Link plus angehängter ID zu jener Ressource besteht, die einen Datensatz löscht, kann das Vorladen schon zur Löschung führen, obwohl der User bei der "Wollen Sie wirklich Löschen? Ja/Nein" Frage es sich vielleicht wieder anders überlegt hätte.

          Dann eine andere Frage: Kann ich mit einer Header-Angabe auf der Seite oder in der .htaccess dieses Vorladen unterbinden? Oder ist die einzige Möglichkeit wirklich nur die Verpackung der "Löschen ja/nein" Frage in ein Formular mit $_POST-Übergabe?

          Liebe Grüße

          Onkel Hans

          1. Hi,

            der Begriff 'Prefetch-Feature' sagt mir überhaupt nichts. Verstehe ich die Ergebnisse meiner GOOGLE-Recherche richtig, dass es dabei darum geht, dass Browser URLs auf einer Seite schon vorladen, um bei evt. Verlinkung selbiger diese dann schneller anzeigen zu können?

            Genau.

            OK, also sobald ein Link plus angehängter ID zu jener Ressource besteht, die einen Datensatz löscht, kann das Vorladen schon zur Löschung führen, obwohl der User bei der "Wollen Sie wirklich Löschen? Ja/Nein" Frage es sich vielleicht wieder anders überlegt hätte.

            Wenn diese Nachfrage nur clientseitig umgesetzt ist (JavaScript) - ja.

            Dann eine andere Frage: Kann ich mit einer Header-Angabe auf der Seite oder in der .htaccess dieses Vorladen unterbinden? Oder ist die einzige Möglichkeit wirklich nur die Verpackung der "Löschen ja/nein" Frage in ein Formular mit $_POST-Übergabe?

            Den Aufruf der eigentlichen Lösch-Aktion per POST statt GET auszulösen, reicht theoretisch schon aus - Bots nutzen kein POST, und auch Prefetching wird nur für GET-Ressourcen gemacht. Noch mal eine Sicherheitsabfrage dazwischen zu schalten, sichert das ganze gegen Fehlbedienung durch den Nutzer ab, die aber eine andere Baustelle ist.

            MfG ChrisB

            --
            RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
          2. Mahlzeit Onkel Hans,

            Dann eine andere Frage: Kann ich mit einer Header-Angabe auf der Seite oder in der .htaccess dieses Vorladen unterbinden? Oder ist die einzige Möglichkeit wirklich nur die Verpackung der "Löschen ja/nein" Frage in ein Formular mit $_POST-Übergabe?

            Ich übersetze mal kurz:

            Kann ich meine fehlerhafte Implementierung mit irgendeiner obskuren Ausnahme-Sonderlocke (die sich ggf. auf undokumentierte Features verlässt oder bei der ich auf andere Art und Weise nicht sicher sein kann, dass ich mich dauerhaft darauf verlassen kann) umgehen? Oder ist die einzige Möglichkeit wirklich nur, das Problem vernünftig zu lösen, indem ich es einfach *richtig* mache?

            GET ist für die *Abfrage* von Daten gedacht, POST ist für die *Manipulation* von Daten da. Das ist AFAIK ursprünglich so konzipiert, allgemein üblich und *darauf* kannst Du Dich verlassen.

            MfG,
            EKKi

            --
            sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|