Query über Link ausführen

[Luckie]

Hatte ich auch vorher so. Habe dann aber genmerkt, dass das überflüssig ist.

[euromark]

für die korrektheit sicht NICHT überflüssig
stelle man sich mal vor, es wird vorher eine andere operation auf dem model gemacht
dann wird ein anderer datensatz geändert!

es ist wichtig, immer vorher zu "resetten" (create() oder eben ->id = ... bzw [id]= ...)

problemfälle:
- im beforeFilter() nochma ne abfrage
- über relationen innerhalb von anderen models
etc etc

also warum "quasi falsch" bzw für die zukunft potenziell fehleranfällig, wenn man es vermeiden kann?

PS: in deinem fall sehe ich übrigens nicht, wie es ohne gehen soll (wird da vorher das model abgefragt?),
oder woher weiß "es" die korrekte id?
scheint ja nirgendwo übergeben zu werden - Standardfall: neuer Datensatz wird angelegt, was ja glaub nich ganz in deinem sinne ist

[Luckie]

Gut du hast recht. Ich habe es jetzt so:

Code: Alles auswählen

function admin_updatestatus($id = null, $statusid_new = null, $statusid_old = null)
    {
        $this->autoRender = false;
        $this->data['id'] = $id;
        $this->data['vertragsangebot_status_id'] = $statusid_new;
        $this->Vertragsangebot->save($this->data);
        $this->logstatus($statusid_old, $statusid_new);
        $this->Session->setFlash(__('The status has been set.', true), 'default', array(), 'info');
        $this->redirect(array('action' => 'view', $id));
    }

Ich muss aus dem gleichen Controller noch etwas in eine andere Tabelle schreiben:

Code: Alles auswählen

    function logstatus($statusid_old = null, $statusid_new = null)
    {
        $this->autoRender = false;
        $this->VertragsangebotStatuslog->create();
        $this->VertragsangebotStatuslog->user_id = 0;
        $this->VertragsangebotStatuslog->zeitstempel = 0;
        $this->VertragsangebotStatuslog->status_vorher = $statusid_old;
        $this->VertragsangebotStatuslog->status_nacher = $statusid_new;
        $this->VertragsangebotStatuslog->save($this->data);
    }

Allerdings bekomme ich zwei Fehlermeldungen:

Undefined property: VertragsangeboteController::$VertragsangebotStatuslog [APP/controllers/vertragsangebote_controller.php, line 51]

und

Call to a member function create() on a non-object in /var/www/... on line 51

Die Tabelle heißt: "vertragsangebot_statuslogs"

[Luckie]

So geht's:

Code: Alles auswählen

function logstatus($vertragsangebots_id = null, $statusid_old = null, $statusid_new = null)
    {
        $this->autoRender = false;     
        $this->data = null;
        $this->Vertragsangebot->VertragsangebotStatuslog->create();
        $this->data['vertragsangebot_id'] = $vertragsangebots_id;
        $this->data['user_id'] = 0;
        $this->data['zeitstempel'] = date('Y-m-d H:i:s');
        $this->data['status_vorher'] = $statusid_old;
        $this->data['status_nacher'] = $statusid_new;
        $this->Vertragsangebot->VertragsangebotStatuslog->save($this->data);
    }

[burzum]

mal davon abgesehen dass cake das natürlich auch falsch macht (delete actions!)

Uhm, nein, schau dir den Code des Frameworks an. Falls Du erfolgreich eine SQL Injection mittels Model::delete() hinbekommst bitte ein Ticket mit Test Case im Anhang erstellen - danke! Wie kommnst Du eigentlich darauf?

[euromark]

DOCH - es muss doch nich immer gleich code injection sein - gibt noch andere wege, "scheiße zu bauen"

es gehört sich einfach nicht, mittels GET etwas an der DB zu ändern
es muss sonst mittels POST gemacht werden
dadurch wird verhindert dass angriffe über z.b. Signaturen möglich sind!

für dich also ein kurzes Beispiel:

Stellen wir uns die Standard-Cake-Methode "users/delete" vor, die einfach so den account von sich selbst löscht (ohne POST!)
Nun ist jemand so nett, und hat in seinem Profil/Signatur oder Kommentar/Post (was auch immer er auf der Seite so machen darf) ein Bildchen - aber kein normales bild sondern als URL dein "users/delete"
PHP ist das ja egal, es denkt es holt ein Bild, in Wirklichkeit wird halt nunmal diese URL aufgerufen.
Wenn Besucher diese Seite öffnen, wird das Bild keine Aktion auslösen, da sie ja nich eingeloggt sind.
Jeder eingeloggte User kann nun allerdings um seinen Account fürchten, sobald der die "gefährliche Seite" von diesem netten User besucht^^

dies nur als kleiner exkurs

[burzum]

DOCH - es muss doch nich immer gleich code injection sein - gibt noch andere wege, "scheiße zu bauen"

es gehört sich einfach nicht, mittels GET etwas an der DB zu ändern
es muss sonst mittels POST gemacht werden

Das ist richtig. Allerdings kam das so rüber als würdest Du meinen die Model Delete-Methode selbst sei unsicher.

Stellen wir uns die Standard-Cake-Methode "users/delete" vor, die einfach so den account von sich selbst löscht (ohne POST!)

Die gebackenen Controller sind ein Schnellstart und nicht dazu gedacht 1:1 so genutzt zu werden, sondern um darauf aufzubauen. Du kannst nicht verhindern das Leute unwissentlich etwas falsch machen oder dumme Leute Dummes tun. Das ist auch nicht die Aufgabe des Frameworks die Leute vor sich selbst zu beschützen.

[euromark]

was? nein, nein..
das Model hat ja nichts mit dem Seitenaufruf und "ob get oder post" zu tun

man könnte es recht einfach "fixen", indem man statt dem "Löschen" text ein verstecktes Formular verwendet, das beim Klick dann ein POST auf die delete methode auslöst
schon wär die Sache abgesichert gegen obige Gefahren.

[burzum]

man könnte es recht einfach "fixen", indem man statt dem "Löschen" text ein verstecktes Formular verwendet, das beim Klick dann ein POST auf die delete methode auslöst
schon wär die Sache abgesichert gegen obige Gefahren.

Wie ich bereits schrieb, die gebackenen Views und Controller sind als ein Schnellstart gedacht und nicht dafür 1:1 genutzt zu werden oder in den Produktivbetrieb ausgeliefert zu werden. Wenn Dich das stört, kannst Du für Deine Projekte eigene Templates anlegen.

Letzten Endes wäre es unverhältnismäßig viel Arbeit das in den Core zu stecken für etwas das in 99% der Fälle eh verworfen wird. Falls Du es unbedingt willst schreib einen Patch und häng ihn an ein Enhencement-Ticket an.

[euromark]

du brauchst mich darüber nicht belehren
ich verwende meine eigenen templates schon lange

nur wäre es ist KEIN großer act - und es weiß fast KEIN unversierter PHP-Neuling über diese gefahr bescheid
insofern ist es durchaus fragwürdig, ob man den prozess des backens dahingehend nicht anpasst - bevor man mit solche mit cake bake gebackenen apps auf die userwelt loslässt.
in der richtung gibt es noch einige schwachstellen in den back-templates, von denen die meistens nichts wissen - und nichts-ahnend solche webseiten online setzen.

aber darum gehts hier nicht
ich habe nur darüber aufgeklärt wo die gefahr liegt - wer das dann ignoriert ist selbst schuld.