login etc.
-
was ist an Cookies heikel (außer dasss manche User sie abschalten) ?
ansonsten bleibt die möglichkeit mit sessions zu arbeiten, wobei das AFAIK trotzdem ein Cookie benützt.
Ansonsten setz doch einfach nur ein Sitzungscookie, also das nur solange gilt wie der Browser offen ist !
-
falls sessions:
schau dir mal das tutorial von joelh an
-
danke!
-
ne aber wie soll man es denn machen, wenn manche Leute Cookies (so Sessions ? ) ausschalten?
-
normalerweise steht in den cookies nur die session id. wenn du keine cookies verwenden kannst, schickst du die id per GET variable immer zur nächsten seite weiter.
-
Aber das ist doch bestimmt total leicht zu fälschen, oder?
MfG Michael Alexander Völkel
-
nein, ist es nicht..., warum auch!?
-
Weil Get über die Adressleiste sichtbar und änderbar ist.
-
Auf alle Fälle mit Sessions, wie schon gesagt wurde, entweder über Cookies (am besten), wenn diese nicht angenommen werden in irgendeiner Form über die URL (also GET) weitergeben (?SessionID=bla ist das einfachste).
oder durch eine selbstgenerierte session mit auslesen von aktueller ip und browserkennung mit datenbankanbíndung und jeweiliger abfrage bei seitenwechsel, ob der der da ist auch erlaubt ist
Das halte ich nicht für sinnvoll, denn gerade die Stärke von Sessions ist doch, dass man die auch noch fortführen kann, wenn auch mal die Verbindung unterbrochen wurde und man deshalb eine neue IP bekommt. Auch wechsele ich manchmal den Browser wärend des Surfens.
Wozu sollte man das auch tun? Die einzige Lücke wäre, wenn man die SessionID in realtime (also der andere die Nachricht sofort erhält und aufruft) überträgt, denn dann könnte derjenige die Session übernehmen (da es aber wohl ein Freund ist auch nicht so schlimm). Aber: Jeder der Cookies ausgeschaltet hat, sollte auch über die Gefahren von Session IDs informiert sein. Jeder DAU hat doch Cookies an und dann gibts überhaupt keine Probleme.Richtig sicher ist eine Session natürlich nur, wenn man über eine sichere Leitung kommuniziert, wie etwa SSL, sonst könnte man die ID auslesen. Da die ID aber völlig zufällig erstellt wird, ist es kaum möglich diese rauszufinden. Auch über einen BruteForce Angriff ist es kaum möglich, weil es einfach viel zu viele Möglichkeiten gibt. Sicher sieht der Benutzer seine ID, aber das ist auch überhaupt kein Problem, denn er kann ja nicht seine eigene Session missbrauchen (weil die Datenmanipulation ja immer über dein Programm geht). Gegen User, die irgendwas falsch einstellen, kann man dann aber nun wirklich nichts mehr machen (wenn das unter umständen sinnvoll sein könnte, sonst könnte man natürlich die Eingabe sperren.)
-
@Loggy:
Aber s. Unkwon User!PS: Diese Message hatte mehr Abkürzungen als normalen Text *rofl*
MfG Michael Alexander Völkel
-
und wie willst das fälschen?
machs halt so:
sessionstarten()
sessionidregistrieren
sessionidinmysqltabellespeichern
auf nächster seite die sesssion id mit der aus der db vergleich wenn != dann errror
-
Ich hatte mich schon auf "UnknownUsers" Beitrag bezogen.
Es ist so, dass jeder seine Session ID verändern kann. Dadurch verliert er seine Session (außer er merkt sich die alte ID) und da die geänderte Session ID noch nicht vorhanden ist, wird eine neue ID erstellt (die nichts mit der geänderten zu tun hat, man kann also durch Links - die alle die gleiche SessionID haben - nicht alle in die gleiche Session laden) und dem Benutzer zugewiesen. Er wird also so behandelt, als wäre er gerade auf die Seite gekommen. Wenn das der Benutzer will, soll er es tun, aber es nutzt ihm nichts.
Solange er nichts verändert, bleibt er in seiner Session und alles ist Ok. Da man aber oft Cookies angeschaltet hat, erübrigt sich das (wenn man den Inhalt der Cookies ändert, ist es genauso, wie oben).
