Post weitergeben?

Hi,
du kannst z.B. ein verstecktes Input erstellen, indem du die Variable einträgst.
Das könnte dann so aussehen:

echo '<input type="hidden" name="ID" value="'.$ID.'">';

Richtig.
Die einzigste Möglichkeit eine Variable auf die nächste Seite weiter zu übergeben ist per GET oder Post.
Ansonsten kann man noch Cookies und Session nutzen.
Diese speichern den Wert jedoch dauerhaft bzw. bis zum Ablauf (welcher Manuel bestimmt werden kann).

Wie Scharock schon sagt wäre der beste weg wenn du es mit Sessions probierts. Diese sind sehr einfach zu handhaben und können dir die Variablen über mehrere Seiten "transpotieren" ohne das du etwas mit hidden feldern oder der gleichen machen brauchst.

Kleines Beispiel wäre sowas:

/*Variable kommt per Get und wird in der Session gespeichert*/
$_SESSION['user_id'] = $_GET['id'];


/*Jetzt hast du solange die Session läuft die Möglichkeit auf die ID zuzugreifen und zwar so*/


$_SESSION['user_id'];

Ich erkläre an dieser Stelle nicht wie man eine Session startet oder wie man diese wieder beendet.

Viel Spass beim weiter Üben
Gruß
Ulle

[FONT="Comic Sans MS"][COLOR="DeepSkyBlue"][SIZE="2"]Schliesse mich der Meinung von ulle an.
Ein hidden-Feld hat zu alledem noch den Nachteil, dass man es manipulieren kann, indem man die $_POST daten ändert.
Ein Cookie is schwieriger zu ändern und für normaluser nicht möglich, ich wüsste zB grade nich, wie ich die Cookies bei firefox ändern kann ;D[/SIZE][/COLOR][/FONT]

Lass mich dich bitte da berichtigen internetfreak

Cookies kann man sehr wohl manipulieren, da diese Clientseitig gespeichert werden. Wäre sonst ja witzlos das du bei deinem Browser die Cokkies löschen kannst :D.

Meiner Meinung nach sind Sessions immer noch das sicherste, man kann diese DB seitig speichern und hat auch sonst mehr Kontrolle darüber. Cookies machen an Stellen wie einem Perm Login Sinn, aber nicht an dieser Stelle.

Lieben Gruß
Ulle

[FONT="Comic Sans MS"][COLOR="DeepSkyBlue"][SIZE="2"] ulle
Ich sagte ja nich, dass man Cookies nich manipulieren kann.
Ich sagte lediglich, dass ein Cookie schwerer zu modifizieren ist, als $_POST Daten, soviel denke ich zumindest dazu.
Wo Cookies gespeichert werden, ist mir auch klar^^
Zum Cookies ändern muss man aber erstmal Ahnung haben, wo es der Browser ablegt, wie er es ablegt und so, er könnte es ja verschlüsselt auf dem PC speichern und vor dem senden dann entschlüsseln oder sowas.
Und das haben viele nicht, für $_PoST zu manipulieren reicht schon TamperData, ein recht cooles FF-Addon[/SIZE][/COLOR][/FONT]

[FONT="Comic Sans MS"][COLOR="DeepSkyBlue"][SIZE="2"]@Well
Was soll wieder die Ironie, mein "Freund"
Dein Ansatz mag zwar logisch erscheinen, ist aber nicht im Sinne des Users außerdem ist das System auf Dauer nicht wirtschaftlich, da kommt ein Webserver bzw Webspace wesentlich billiger ;D[/SIZE][/COLOR][/FONT]

Well Spamm0r.

<?php
session_start();


// Login Teil
$_SESSION['uid'] = $uid;


?>

$uid enthält hier die USERID aus der Datenbank, sekundär lassen sich auch noch weitere Informationen in SESSIONS speichern (z.B. Username) um weitere Datenbank abfragen auf den nächsten Seiten sparen.

Auslesen geht dann im Endeffekt wieder ganz einfach

<?php
session_start(); // Notwenig um mit sessions zu arbeiten
echo "Deine UID ist ".$_SESSION['uid']." und dein Username lautet: ".$_SESSION['username'];
?>

Ich empfehle für weitere Handhabung mit Sessions: http://www.usegroup.de/software/phptutorial/sessions.html

Ich bitte dich, du glaubst doch nicht wirklich das dein Post ernsthaft produktiv zum Thema war?

[COLOR="Red"]Ich muss Drilon recht geben.
Das war eher als Scherzantwort zu lesen.

Ich hab auch eine:
Pc aus.Und raus gehn frische Luft schnappen.Den Pc nie wieder anmachen und alle Probleme sind weg.Billiger gehts nicht.

Das ist zwar eine völlig korrekte Schlussfolgerung.Aber weder Prduktiv zur Frage, noch Sinnvoll >.>

Ich benutze für meine Logins immer Sessions,find Sie iwie besser als Cookies.
Wobei ich nicht abstreiten möchte, dass diese nicht manipuliert werden können.
Kenne mich net in der Hackerszene aus, aber ob Sie wirklich sicherer als Cookies sind?[/COLOR]

Sessions sind Serverseitig, somit kann man sie (falls nicht irgendwo im Code ein Leck ist) nicht manipulieren.

[FONT="Franklin Gothic Medium"][COLOR="Indigo"][SIZE="3"]

Zitat von Well;204048

Lo?!
Nach diesem Prinzip arbeiten - besonders größere Firmen - schon seit vielen Jahren.

stimmt, gerade in china und indien ist das gängige Praxis.[/SIZE][/COLOR][/FONT]

Natürlich, wenn ich mich einloggen will schick ich über die Post ein Brief ans Unternehmen.
Ein Mensch wertet diese Sachen aus und sendet mir erneut über die Post ein Brief auf welcher die Website gezeichnet ist.

[FONT="Comic Sans MS"][COLOR="DeepSkyBlue"][SIZE="2"]Das Problem an Sessions ist aber die geringere Haltbarkeit.
Sessions laufen nach ner gewissen Zeit ab, beim Browser i.d.R wenn er geschlossen wird (also die Sitzung beendet wird) oder wenn man die Cookies löscht.
Auf dem Server werden Sessions nach ner gewissen Zeit ohne Nutzung auch gelöscht (hängt von der Konfiguration des Servers ab)
An sich sind Sessions schon nen Tick sicherer, was die Manipulation angeht, allerdings schützt auch ne Session nicht vorm Diebstahl von Daten.
Unter dem Begriff Session Hijacking ist erklärt, was ich meine, einfach mal Googlen.
Für alle, die googlefaul sind:
Session Hijacking meint das "Klauen" der Session.
Der Hacker (*hust* es heißt eigentlich CRACKER, denn er tut böses, hacker sind lieb*hust*) brauch seinem Opfer nur eine präparierte Seite unterschieben, schon hat er theorerisch das Cookie mit der Sessionid und brauch es nur bei sich ablegen und nutzen.
Theoretisch heißt, dass es nicht so einfach ist.
Sessions und Cookies (Wobei es sich Clientseitig bei ner Session auch um ein Cookie handelt (Sessions sind Cookies mit einer Lebenszeit von ner Browsersitzung und einthalten die Sessionid, mit der der Server die zugehörigen Daten identifiziert und ggf. lädt, wenn er die Daten der Session noch hat)) können nur von der Webseite gelesen und interpretiert werden, die auch die Session/das Cookie erstellt hat.
Und genau dieser Umstand macht die Sache schwerer, es gibt jedoch nen Trick.
Und zwar macht sich der *hust* Hacker *hust* eine so genannte XSS-Attacke nutzbar (sofern es eine gibt)
XSS bedeutet Cross-Site-Scripting und um es zu nutzen, reicht schon ein einfaches $_GET.
Wenn man dieses mit Javascript-Code füttert und das $_GET mangelhaft gesichert wird bzw vll sogar iwie ausgegeben wird ohne Sicherung, so wird es im Falle eines JS Codes vom Browser ausgeführt.
JS kann Cookies setzen/ändern/löschen und auch lesen.
Und genau dies macht eine präparierte Datei, die ausgeführt wird über das $_GET des Opfers (die Datei liegt auf dem Server des Bösen, er ruft sie nur über das src Attribut des <script> Tags auf)
So kommt der Böse an das Cookie, wenn er weiß, wie es heißt (Cookies haben alle nen Namen) bzw wird meist bei XSS eh darauf abgezielt, alle Cookies der betreffenden Seite zu klauen.
Es gibt nochn paar andere Methoden, allerdings fallen die mir nicht ein und es wäre auch zu viel, die noch zu erklären.
Falls ich den Begriff Session Hijacking versehentlich mit der falschen Erklärung benutzt habe, so tuts mir leid und ich bitte drum, dann den richtigen Namen zu nennen für das Ding.
Ausserdem wärs nett, wenn ihr mir sagt, falls ich was falsches in der Erklärung gesagt habe.
Ich hab das ganze nämlich aus dem Kopf heraus geschrieben und nich selber nachgeschlagen.[/SIZE][/COLOR][/FONT]