Wie macht ihr $_GET sicher und wie überträgt Ihr die u_id?

Hey,

Naja. Wenn sich ein User bei deiner Seite registriert, dann bekommt er ja eine ID zugewiesen. Nun ziehst du diese ID bei dem Login des Users aus der Datenbank. Nun hast du die IDs der User die Online sind. Und wenn jemand einen Beitrag postet, benutzt du seine ID um auf sein Profil zu verlinken.

Zitat

Wie kann ich jetzt $_GET sicher übergeben?

Wie meinst du das?

Bei GET wird an die URL ein Parameter gehongen. Das heißt bei klick auf den Link wird die Profilseite des Users ausgegeben. Und die ID welche dann als Url-Parameter an der URL angebunden ist benutzt du um die passenden Daten des Users aus der Datenbank zu ziehen. Das heißt es gibt nur 1ne Seite für alle Userprofile. Nur wird dann nach der ID der entsprechende Content aus der DB gefecht und ausgegeben.

Nein das stimmt so nicht. Wenn sich ein User anmeldet wird doch seine eigene ID aus der DB gezogen. Das heißt jeder User muss eine andere ID haben.

Moin,

beim generieren der Liste der Beiträge (Post's) loopst du doch duch deine Beiträge durch -

bei jedem einzelenen Beitrag hast du bestimmt auch in irgendeiner Spalte (z.B. fk_user_id) den Benutzer gespeichert, der diesen Beitrag verfasst hat.
Wenn du jetzt den Beitrag augibst nutzt du einfach die fk_user_id um sie als GET Parameter an den Link anzuhängen z.B.: <a href="user/?id=<?=$row->fk_user_id?>">

Achso dies meinst du. Dann habe ich dich falsch verstanden.

Bei einer Beitragfunktion sollte man zusätzlich neben der Registriertabelle auch eine beitragTabelle haben, welches den beitrag, die ID des Users welcher den Beitrag erstellt hat. Nun kannst du dann mittels den mysql_joins die IDS mit dem Namen welcher die selbe ID hat verbinden und somit hast du ja die ganzen Daten von dem User.

Stef dies ist nicht ganz richtig, verknüpfungstabellen werden nur bei n:n (mehrere Benutzer pro Beitrag) beziehungen benötigt, nicht bei 1:n (ein Benutzer pro Beitrag).
Der join funktioniert auch ohne die verknüpfungstabelle, da wir ja die User ID schon beim beitrag gespeichert haben (fk_user_id)

Ok. Man kann aber davon ausgehen, bzw. erwarten, dass mindestens 1 Person den Beitrag kommentiert. Ich dachte dies nennt man Normalisierung.

Nochmals zum Verständnis:

Jeder eingeloggte User erhält seine eigene Session. In der Session ist deren id. Nun bei einem Beitrag wird diese Id in die Beitragtabelle abgespeichert. Nun hat man in dieser Tabelle nur die ID des Posters und seinen Beitrag. Nun muss ich ja irgendwie an den Namen kommen. Ohne Join habe ich dann den Namen durch ein Select-Statement aus der anderen Tabelle, welche die ganzen Registrationsdaten speichert, herausbekommen. Diesen Namen kann man dann auch bei der Ausgabe des Beitrages im Frontend dann verwenden.

Mit Join ist dies aber doch viel einfacher? Dabei beachtet man dann auch die Normalisierung.

Abgesehen davon, dass ich denke das dein Beispiel ein anderes ist als es hier in diesem Thread geht:

Zitat von Stef

Jeder eingeloggte User erhält seine eigene Session. In der Session ist deren id. Nun bei einem Beitrag wird diese Id in die Beitragtabelle abgespeichert. Nun hat man in dieser Tabelle nur die ID des Posters und seinen Beitrag. Nun muss ich ja irgendwie an den Namen kommen. Ohne Join habe ich dann den Namen durch ein Select-Statement aus der anderen Tabelle, welche die ganzen Registrationsdaten speichert, herausbekommen. Diesen Namen kann man dann auch bei der Ausgabe des Beitrages im Frontend dann verwenden.

So weit, so richtig.

Zitat von Stef

Mit Join ist dies aber doch viel einfacher?

"Einfacher" ist subjektiv, manche machen lieber Joins, ander (Sub)selects.

Zitat von Stef

Dabei beachtet man dann auch die Normalisierung.

Die Normalisierung besagt "nur", dass du Daten nicht doppen speichern sollst, z.B. die Adressen der Nutzer sollst du in eine extra Tabelle speichern (n:1, da ein Benutzer 1 Adresse hat : eine Adresse n Nutzer haben kann). Die Normalisierung wird in dem Thread Beispiel allerdings einhgealten, da beim Beitrag ja nur die jeweilige Nutzer ID gespeichert wird.

In deinem Beispiel beachtest du ja schon die Normalisierung, da wie du oben schreibst, ja der Beitrag und dessen Nutzer ID in einer Zeile stehen, da allerdings nur ein Nutzer diesen Beitrag verfasst hat, und eben nicht Viele nutzer diesen einen Beitrag verfasst haben brauchst du ja pro Beitrag nur einen Nutzer zu speichern (1:n ein Nutzer kann n Beiträge "haben" : ein Beitrag kann 1 Benutzer "haben"), richtig? -> Normalisierung eingehalten.

Beispiel n:n

Wenn du jetzt Aber die Funktion "Beitrag liken" implementieren willst, dann hast du n:n ein Nutzer kann n Beiträge Liken : ein Beitrag kann von n Nutzern geliked werden. Hierfür brauchst du eine Zuweisungstabelle, in der du auch noch Metadaten speichern kannst, z.B. wann der Like gemacht wurde.

Schlusswort

Wie du jetzt bei deinem Beiterag an z.B. den Nutzernamen kommst, ist nicht wichtig für die Normalisierung, hier kannst du eben einen Join oder ein extra Select nutzen. Da bei OOP (ObjektOrientierter Porgammierung) alle Datenbank-Ergebnisse sowieso in Objekten abgespeichert werden, ist dort ein einzelnes Select für den Benutzer sowieso nötig.

Hey,

Joins sind ab und zu doch unübersichtlich oder man kommt mit denen kaum klar. Aber manchmal können sie echt sehr hilfreich sein. Extra Selects sind aber auch gut. Ist zwar ein wenig mehr Code aber die sind meiner Meinung bei einfachen Verknüpfungen doch besser.

Aso. Dann habe ich wohl das ganze Prinzip der Normalisierung nicht so richtig verstanden. Danke für die ausführliche Erklärung. Wieder was dazugelernt.