kannst auch gerne per MSN/ICQ um Infos fragen, bin fast immer online 
Hallo!
Ich (PHP-Anfänger) arbeite derzeit an einem kleinen Loginscript um mich selbst in PHP weiterzuentwickeln. Mit größtem Interesse habe ich diesen Thread gelesen, insbesondere den Hinweis von Michi in Bezug auf die Ip-Sperre. Das Script lässt die Registration neuer Benutzer zu und legt diese in einer DB an. Nun hab ich dazu aber nochmal eine paar Fragen^^.
Ich erzeuge eine Session
Auf der Loginseite (Eingabemaske):
<?php
session_start();
include "functions.php";
?>
<input type="text" name="benutzer"....
...Also erzeuge ich hiermit eine neue Session soweit sie noch nicht existiert. Diese wird als Cookie abgelegt. Richtig ?
Nun möchte ich aber auch mit einer Mysqldatenbank arbeiten. Also trage ich im vorgesehenen Feld die Session ein:
functions.php:
/*benutzerlogin -- [start]*/
...
$sql="UPDATE usr_table
SET Benutzersession='".session_id()."'
WHERE Benutzerid=".$userid;
mysql_query($sql);
...Soweit so gut 
. Die Session ist in der DB gepseichert und wenn sich ein Jemand im „Mitgliederbereich“ einloggt und dort auf den Unterseiten rumsurft wird überprüft ob die Session mit der in der DB übereinstimmt. Alles funktioniert so, wie ich es mir vorstelle
Nun möchte ich die IP-Sperre mit einbauen.
Da fallen mir als erstes die 2 Befehle auf.
$_SESSION["ip"]=$_SERVER["REMOTE_ADDR"];Ist das richtig, das der globalen Variable, die sich wie ein Array verhält nun der Benutzer und die Ip des Benutzers zugewiesen werden ?
Aber wie kann ich das nun zusätzlich in die Datenbank eintragen und überprüfen ?
Eigentlich könnte ich doch auch die IP nehmen, beim login in ein extra Feld eintragen und
dann in der „check_loggedin“-Funktion immer wieder überprüfen lassen ob die session noch zur ip gehört:
$se = $session_id();
$ip = $_SERVER["REMOTE_ADDR"];
$_SESSION["werte"]= werte('$se' => '$ip'); naja … lassen wir das mal lieber^^ . Ich steh an der Stelle irgendwie auf dem Schlauch 
1.) Du brauchst du session-id nicht in einer DB speichern (vor allem wenn du die nicht überprüfst ), das erledigt die IP-Sperre
2.) Das globale Array $_SERVER speichert diverse Infos über die aktuelle Verbindung
3.) Das Array $_SESSION verhält sich zunächst wie ein normales Array, nur der Inhalt wird nach Ausführung auf dem Server gespeichert
4.) Aus werte(’$se’ => ‚$ip‘); werde ich auch nicht schlau…das müsste einen Fehler geben
ich will jetzt keinen ärgern oder so. Habe jetzt auch alle antworten gelesen, wie auch das mit globalen variablen und auch cockies. Habe hier zu niemanden auch ne Frage, die er beantworten soll. Ich wollte nur drauf hinweisen und einfach ma zum nachdenken anregen:
- wenn cockies von benutzer her abgeschaltet werden und nicht zugelassen sind?
- wenn globale variablen von server her abgeschaltet wären und nicht akzerpiert werden
Ihr merkt selber den unterschied, dass es mit ip schlecht hinhaut trotzdem macht ihr es weiter. - was ist wenn die ip von provider zufälligerweiße an einem anderen user erteilt wäre.
- Viel spass beim programieren und mein tipp: alleine nur mit sessionid() könnte man wunderbar arbeiten, wobei session_start() am anfang nicht vergessen. Und die session id nicht über url weiterleiten oder sonstwas, sondern über die datenbank.
- Dann müsste man die SSID über GET weitergeben…aber jeder der Cookies deaktivieren kann, kann auch Außnahmen hinzufügen
- Globale Variablen werden nicht abgeschalten, die IP funktioniert super als Sperre gegen das “doppelte Einloggen” und gegen den Session-Klau…für mehr wird es auch nicht verwendet
- Gar nichts…solange er nicht die (noch gültige) Session-ID vom vorherigen Benutzer erhält
Mach dazu mal ne Wahrscheinlichkeitsrechnung: Warscheinlichkeit, dass ein Benutzer vom Anbieter die IP erhält (ca. 0,8) MAL der Warscheinlichkeit, dass der bplaced kennt (0,02-0,1) mal der Warscheinlichkeit, dass der die SSID hat (0,0000000001 - 0,000000002) … Werte hab ich geschätzt, jedenfalls ist das enorm sicher (Proxys ausgenommen) - Warum die SSID nicht über die URL weiterleiten? Der IP-Filter funktioniert ja perfekt
ebenfalls
@michi7x7
zu punkt 4) ich meinte, dass man es auch ohne get machen kann, wenn zb man die sid in datenbank speichert und danach jedesmal abfragt ob die sid noch vorhanden ist mit der jetzt generierten sid zusammenstimmt.
Es ging darum, dass die sessionid als cookie gespeichert wird. Wer Cookies nicht aktiviert hat, könnte demnach sich nicht einloggen. Wenn die sessionid aber über get mitgeliefert wird, braucht man keine Cookies mehr.
darum geht’s…genau
Hm das mit den deaktivierten Cookies ist ein guter Einwand -.-"
ja durch das anhängen der Session_id an den Link wird das Problem einfach umgangen.
Aber wenn man jetzt den die URL der Seite an einen schickt und die sid noch gültig ist, dann wär dieser “Nutzer” ja auch angemeldet. Dann bräuchte man auf jedenfall die IP-Sicherung!
darum geht’s auch
Danke xD ich weis ich hab das Thema erstellt 
Servus erstmal,
Da fällt mir auch eine Frage ein. Wie lange lebt hier eine Session, weil bei funpic hatte ich nur Probleme damit, weil sie alle 75 sek gelöscht wurde. 
Wo kommt das hin? Kurz nach session_start();?
Hallo,
ich würde noch dazuschreiben, die SessionID auch über die URL mitzunehmen. Dann funktioniert der Login auch bei Usern, die die Kekse deaktiviert haben. Einfach
sebbo
du meinst
oder?
aber seid wann ist SID eine Konstante??? Außerdem wird PHPSSID immer interpretiert (zumindest auf bplaced)
aber SID funzt auch und is weniger tipparbeit^^
sebbo
SID ist eine Konstante, seit sie engeführt wurde. Jedenfalls ist sie genau dafür gedacht, die Session-Parameter über die URL weiterzugeben, da sie leer (aber vorhanden) ist, wenn Cookies akzeptiert werden.
Wie schon gesagt: Nein, nur wenn der Session-Parameter PHPSESSID heißt (d. h., wenn man ihn nicht manuell umbenennt). Von daher funktioniert es mit Scripts, die PHPSESSID benutzen, aber auch nur mit denen.
meine Rede^^
