Artikel editieren - Problem mit Session-Array

[C4rter]

Folgendes, ich arbeite an einem System wo man Artikel eintragen und editieren kann.
Das Anlegen klappt auch soweit, aber nun grübel ich an der editieren Funktion, und zwar im Bezug auf Sicherheit.

Ich rufe den Artikel so auf: createeditarticle.php?articleid=562&action=edit
Nach dem Aufruf lädt ein Formular wo die Daten des Artikels zum editieren bereitstehen. Kurz zuvor, im PHP-Code, speicher ich die ArticleID im $_SESSION-Array unter $_SESSION['ArticleID']
um beim anschließenden editieren den Artikel in der Datenbank anhand der ArticleID zu finden.

Das Problem dabei:
Wenn jemand 2 Artikel gleichzeitig zum editieren öffnet, z.B. Artikel 123 und danach direkt auch 124, ohne das Editieren von 123 beendet zu haben, ist $_SESSION['ArticleID'] ja zuerst 123 und dann 124.
Wenn er dann aber zuerst 123 editiert und das Formular abschickt, verändert er ja ungewollt statt 123 die danach aufgerufene 124.

Ich könnte nun die ArticleID in einem hidden-Feld des Formulars speichern, doch habe ich gelesen das dies nicht so gut ist in dem Hidden-Feld solche Daten abzulegen, weil der User/Hacker diese ja ändern kann und dann ggf. auch Artikelnummern eingeben kann, zu denen er gar keinen Zugang hat.

Wie kann ich die ArticleID also im Session-Array speichern, ohne das die von einem gleichzeitig aufgerufenen anderen Artikel überschrieben wird. Geht das überhaupt? Oder was gibt es da für eine Lösung?

Wahrscheinlich muss ich einfach beim editieren prüfen, ob er diesen Artikel editieren darf. So würde es völlig egal sein, ob jemand böswillig den HIDDEN-Value editiert, denn er könnte den Artikel ja sowieso nicht editieren.

 

[joobie]

Die einfachste Lösung, die mir einfallen würde, wäre denen nur zu erlauben, einen Artikel auf einmal zu editieren. Also bevor Du einen Artikel zum Editieren aufrufst, checkst Du zuerst ob $_SESSION['ArticleID'] existiert.

Wenn ja, speicherst Du den neu aufgerufenen Artikel z.B. in $_SESSION['articleQueue'], damit Du weißt, wo er hinwollte - dann kannst Du entweder eine Meldung zeigen "bitte zuerst den aktiven Artikel speichern" - oder Du kannst den noch nicht gespeicherten Artikel (ArticleID) dann automatisch speichern, und im selben Zuge jene Session-Variable löschen. Dann die Seite neu laden.

Da (ArticleID) nun nicht mehr in der Session existiert, geht's in die nächste Abfrage in Deinem Code, die schaut, ob (articleQueue) existiert. Wenn ja, öffnest Du diesen Artikel zum Editieren.

Damit wäre der User am Geringsten in seinem Arbeitsfluss gestört und Du hättest das Problem behoben. Wäre das eine Lösung?

 

[C4rter]

Die einfachste Lösung, die mir einfallen würde, wäre denen nur zu erlauben, einen Artikel auf einmal zu editieren. Also bevor Du einen Artikel zum Editieren aufrufst, checkst Du zuerst ob $_SESSION['ArticleID'] existiert.

Wenn ja, speicherst Du den neu aufgerufenen Artikel z.B. in $_SESSION['articleQueue'], damit Du weißt, wo er hinwollte - dann kannst Du entweder eine Meldung zeigen "bitte zuerst den aktiven Artikel speichern" - oder Du kannst den noch nicht gespeicherten Artikel (ArticleID) dann automatisch speichern, und im selben Zuge jene Session-Variable löschen. Dann die Seite neu laden.

Da (ArticleID) nun nicht mehr in der Session existiert, geht's in die nächste Abfrage in Deinem Code, die schaut, ob (articleQueue) existiert. Wenn ja, öffnest Du diesen Artikel zum Editieren.

Damit wäre der User am Geringsten in seinem Arbeitsfluss gestört und Du hättest das Problem behoben. Wäre das eine Lösung?

Die Meldung mit "bitte zuerst den aktiven Artikel speichern" finde ich ganz gut, auch wenn der Kunde dadurch ja schon darin beschränkt wird mehrere Artikel zum editieren zu öffnen.
Den Artikel erst speichern und dann den neuen öffnen, verstehe ich aber nicht so ganz. Der Kunde wird ja in der Regel 2 Tabs auf machen, mit den 2 Artikeln. Er kann also beim ersten Artikel ja immer noch auf "Speichern" klicken in der Form, dieses kann ich ja nicht schließen lassen.

Mal das Forum hier rangezogen als Beispiel, sind die Parameter ja ganz ähnlich wie bei mir: "?do=editpost&p=1841761" und es wird hier beim Beitrag-Editieren auch die PostID hidden gespeichert beim editieren:

<input type="hidden" name="p" value="1841761" />

also könnte ich das, mit entsprechender Prüfung ob der Post/Artikel zu dem User gehört, auch so machen eigentlich.

 

[joobie]

Ok - das wäre natürlich viel besser, aber dann verstehe ich leider Deine ursprüngliche Frage nicht. Wolltest Du das nicht mit Sessions machen?

OK ich hab's mir gerade nochmal durchgelesen, mir ist das total entgangen das erste Mal:

Wahrscheinlich muss ich einfach beim editieren prüfen, ob er diesen Artikel editieren darf. So würde es völlig egal sein, ob jemand böswillig den HIDDEN-Value editiert, denn er könnte den Artikel ja sowieso nicht editieren.

Das würde ich auf jeden Fall machen. Dann kannst Du mit GET arbeiten oder mit hidden-Formfeldern, und musst das nicht in der Session speichern.

 

[C4rter]

Ok - das wäre natürlich viel besser, aber dann verstehe ich leider Deine ursprüngliche Frage nicht. Wolltest Du das nicht mit Sessions machen?

Das würde ich auf jeden Fall machen. Dann kannst Du mit GET arbeiten oder mit hidden-Formfeldern, und musst das nicht in der Session speichern.

Ich wollte es mit hidden-Feldern machen, weil es für mich logisch erschien. Dann las ich aber verstärkt von Schadcode der durch Hidden-Felder eingeschleust werden kann und das diese gern von Hackern verwendet werden und dachte, dass ich vielleicht eine Funktion der Session-Arrays noch gar nicht kenne, die man dafür benutzen könnte. Aber dem scheint ja nicht so zu sein. Hidden-Felder verwenden und dann den Inhalt sorgfältig prüfen um so Schaden zu vermeiden, scheint die beste Lösung zu sein.
Lasse im selben Zug nun auch alle Feldeingaben mit der "htmlentities" Funktion auf HTML-Code checken, da dieser mir ja sonst meine Eingabefelder schrotten könnte. Man man, im Internet muss man sich wirklich 5x absichern, echt super nervig das so viel beim User stattfindet statt auf dem Server.
Auch javascript, man kann so viele schöne prüfungen in Javascript entwickeln, und der User deaktiviert das einfach und gar nix mehr wird geprüft. Also muss man alle Prüfungen im PHP nochmal machen.