nuja, das sind ja nur die grundlagen. anwenden musst du die dann selber. bspw die sql befehle anpassen usw. ändert der admin was an nem bestehenden datensatz, muss man UPDATE statt SELECT nehmen als bsp. oder wenn man nen neuen datensatz anlegen möchte, dann INSERT. dafür hoffe ich halt, sind die dokus vom ersten posting nützlich. bei detailfragen kann ich aber sicher immernoch versuchen zu helfen ^^ aber ich will dir das ding ja nich in allen einzelheiten schreiben, sollst ja auch was lernen
wegen login: im grunde ist es einfach. du legst nen formular an, wo man sich erstmal reggen kann. da kommt also alles rein, was du zu dem speichern möchtest. name, vorname, personummer als bsp. dann natürlich noch ein passwort - fast das wichtigste vergessen *g* wenn du das abschickst, wird per insert alles in die db geschrieben (immer schauen, obs ned schon sonen datensatz gibt) und der user existiert schonmal. nun bietest du noch nen login formular an, wo er zum bsp die personummer oder name (oder whatever) kombiniert mim passwort aufnimmt, und dann vergleichst du einfach, ob beim user mit der personummer (oder oder) das pw stimmt. stimmts, ist er eingeloggt.
das schwierige is hierbei nur: sobald er wieder kilckt, müsste dieser check erneut erfolgen, sonst is er wieder ausgeloggt ^^ also jedesmal, wenn irgendeine seite vom server (durch nen klick auf nen link oder button) erzeugt wird, muss dieser check erfolgen. nur jedesmal son blödes login formular ausfüllen zu müsen oder so, is ned grad prall. ne lösung bieten die sessions an. loggt sich der user ein, wird bei erfolgreichem login ne session gestartet. bei weiteren klicks, wird dann auf diese session geprüft. jetz muss ich selber erst nochma glotzen, wie das alles funzte
achja: vorweg noch was anderes grundsätzliches zur arbeit mit formularen:
man hat dazu in html ja den <form> tag. für meine login seite hatte ich zum bsp so eins hier:
PHP:
<form name="form" action="index.php?section=login" method="post">
der name ist für php relativ uninteressant. wenn man irgendwas mit javascript macht zum bsp, kann man anhand des namens auf dieses element bspw zugreifen. aber wie gesagt - für unsere zwecke erstmal egal. daher auch dieser äusserst sinnvolle name ^^ gut, bei action kommt die url rein, wo das hingeschickt wird. also wenn man einen button drückt, wird diese url aufgerufen - und dort muss man halt irgendwie druff reagieren. an der adresse hier siehste schon eine der besonderheiten die ich meine. als nächstes kommt noch die methode, mit der wir die daten versenden wollen. hier gibt es 2 varianten (soweit ich weis): get und post. bei action siehst du die get-variante. an eine url werden per ? parameter in der form name=value angehängt (mehrere werden dann mittels & verknüpft. 2 parameter würden dann also so aussehen: index.php?param1=value1¶m2=value2.
gut, an der zielseite (durch action definiert) kannst du dann mit dem "globalen" array $_GET auf eben jene daten zugreifen. dieses array gibts immer und nimmt eben diese parameter auf (sofern vorhanden). um also value1 zu erhalten, müssten wir $_GET['param1'] abfragen/ausgeben/what ever. die methode is natürlich für formulare unschön. und unsicher ^^ bei passwörtern sollte sich die methode natürlich von allein verbieten - bei größeren formularen bombt man sich die adressleiste zu ><
jo, daher gibts noch methode 2: post. da passiert genau das selbe, nur im hintergrund. zugriff gibts dann nicht über $_GET sondern mittels... na? du wirst es erraten - richtig, $_POST ^^ also bei formularen möglichst immer post verwenden.
noch ein kleiner abschließender tip: bei eingabefeldern für passwörter kommen da ja immer so sternchen oder punkte "mittlerweile". um diesen effekt zu erzielen, nutze dieses input-dingelchen:
PHP:
<input type="password" name="userpw">
achja, siehste: der name DIESER elemente ist wichtig. um das klartext-pw bei der "action-seite" zu bekommen, musst du dann $_POST['userpw'] abfragen. also der parametername ist hier der elementname des input-elements. genauso auch alle anderen natürlich.
und wie du gerade lesen konntest: das pw kommt hier ja im klartext an. so sollte man das aber freilich ned speichern. dazu gibts dann die md5 variante. hier mal meine verarbeitung des logins:
PHP:
$login=false;
session_start();
session_regenerate_id();
$ipadresse = $REMOTE_ADDR;
if(isset($_GET['section']) && $_GET['section']=='login') {
if(isset($_POST['username'], $_POST['userpw']) && trim($_POST['username'])!='' && trim($_POST['userpw'])!='') {
$sql="SELECT * FROM user WHERE Login = '".$_POST['username']."';";
$res = mysql_query($sql) OR die("Account-Name prüfen fehlgeschlagen.<br>".mysql_error());
if(mysql_num_rows($res)) {
$row = mysql_fetch_assoc($res);
if($row['Password']==md5($_POST['userpw'])) {
$log='Ihr Login war erfolgreich.';
$login=true;
setcookie('UserID', $_POST['username'], strtotime("+1 month"));
setcookie('Password', md5($_POST['userpw']), strtotime("+1 month"));
$_COOKIE['UserID'] = $_POST['username'];
$_COOKIE['Password'] = md5($_POST['userpw']);
$_SESSION['ID'] = $row['ID'];
$_SESSION['Time'] = strtotime("+10 minutes");
$_SESSION['IP']=$ipadresse;
unset($_GET['section']);
} else
$log='Falsches Passwort!';
} else
$log='Benutzername nicht vorhanden!';
}
}
zuerst prüfe ich, obs nen get-parameter mit dem namen session gibt. haben wir unser formular da abgeschickt, gibts das (stand ja so bei action dabei). und dann prüf ich noch, ob das teil den wert login hat - hats in unserem falle. als nächstes prüf ich, ob alle angaben "sinnvoll" sind - bei mir also, wenn überhaupt was eingetragen wurde. trim() löscht alle leerzeichen aus einem string. gibt man als pw oder so also " " ein, dann würde das durchfallen, da nach trim nur "" über bleit ^^ joa, danach hol ich mir aus der db den datensatz dieses users. wenns einen gibt, is ok, ansonsten sagt er halt, das es keinen mit dem benutzernamen gibt. gibts einen, wirds spannend ^^ dann wandeln wir $res wieder in $row um und schauen, ob die pw's "stimmen":
PHP:
if($row['Password']==md5($_POST['userpw']))
das pw in der datenbank ist als md5 gespeichert, wir müssen unser POST-pw also jetzt auch umwandeln, um vergleichen zu können -> dazu dient die md5() funktion. falls du nicht weisst, was md5 macht: das erzeugt einen hascode(?) aufgrund des eingegebenen wertes. dieser code ist bei gleicher eingabe immer gleich. also aus "abc" wird IMMER (jetzt nur erfunden) "u4ui54w3" (son hashcode ding is glaub 11 zeichen lang). die zuordnung wert->md5wert ist also immer eindeutig. andersrum funzt das allerdings nicht mehr. kann durchaus auch andere eingabewerte geben, die zum selben md5 code führen. jemand mit dem passwort holla_die_waldfeh könnte also rein zufällig auch den md5 code "u4ui54w3" haben. also abc und holla_die_waldfee führen beide (wie gesagt nur rein exemplarisch) zu "u4ui54w3". wäre dem nicht so, könnte man zu jedem md5 code ja auch das pw wieder bekommen ^^ wäre dann also unsinnig. im gegenzug kanns mit nem extremen zufall aber eben passieren, dass man mit dem falschen passwort dennoch zugriff bekommt. aber wie gesagt - äusserst unwarscheinlich.
kurzer zwischenschub: um in ner db einen wert als md5 zu speichern, musste diesen sql befehl nehmen:
PHP:
$sql= "INSERT INTO user
(UName, Password)
VALUES
('".addslashes(htmlspecialchars($_POST['Username']))."',
MD5('".$_POST['Userpw']."'));";
mysql_query($sql) OR die("Fehler beim Schreiben der Daten!<br>".mysql_error());
echo '<b>Registrierung erfolgreich! Sie können sich nun einloggen.</b>';
also INSERT INTO <tabellen-name> (<param1> ... , <paramN>) VALUES (<value1> ... , <valueN>);. und um nun das ganze als md5 zu speichern -> einfach MD5(<value>). die spalte der db muss dann glaub ich als long mit 11 zeichenlänge eingestellt sein. oder 32? irgendwie sowas >< ach ok, 32 war richtig, aber so: varchar(32) <- das format brauch die spalte dann. was dir auch auffallen dürfte: addslashes und htmlspecialchars. die sorgen wiederrum für sicherheit. ganz wichtig! man kann da nämlich ganz locker selber sql code in son eingabefeld tippseln und damit (webnn mans geschickt macht) den im php-code stehenden sql befehl erweitern und somit schundfug treiben. htmlspecialchars sorgt glaub ich dafür, dass eben sonderzeichen in diese html dinger umgewandelt werden. also aus < wird < usw (wenn ich jetz ma keinen blödsinn erzähl ^^). und addslashes baut überall \ <- slash davor. das bewirkt, dass befehle unwirksam werden. nen \SELECT kann ne db ned mehr auswerten ^^ im umkehrschluss muss man dann beim auslesen den krempel wieder entfernen. wie war denn dass nu wieder >< ahja, einfach stripslashes().
gut, so also vergleicht man dann erstmal das pw. failt dieser vergleich, wird ausgegeben, dass dass pw falsch war. für den user ist das hilfreich zu wissen, ob nu pw oder username falsch war - für nen hacker aber notfalls auch ^^ daher ist diese variante nicht unbedingt zu bevorzugen. die viel gehasste simple aussage "nutzername oder pw falsch" ist also die sicherere variante.
weiter: danach kommt das ganze zeugst mit der session. um die session nutzen zu können, muss man erstmal (was ganz am anfang steht) das ganze starten und das regenerate_id ding ist auch wieder was zur sicherheit. da wird die session-id immer geändert oder so. das is zu lange her, wo mir das nen kumpel erklärt hatte >< jedenfalls ändert sich das eben dann bei jedem seiten laden und ist somit schwerer zu hacken. irgendwie so war das.
gut, mit setcookie baust du ein cookie eben. da kommt der name (parametername als vergleich zum bsp), nen wert (parametervalue bla) und ne lebensdauer des cookies rein. ich bau hier 2e, eins mim loginnamen und eins mit dem verschlüsselten pw. zudem fülle ich noch die "globalen" arrays $_COOKIE und $_SESSION mit werten. tme bei session war glaube für mich der inaktivitäts timer. also nach 10 mins erfolgt autologout. sprich, macht man 10 mins nix mehr und lickt in der 11. erst wieder was, dann wird man als ausgeloggt gewertet und das ganze zählt nich mehr.
gut, ok. nu haben wir uns also eingeloggt und alles schön. aber wir müssen die gelegte fährte ja auch wieder aufnehmen. dazu dann dieser codeschnipsel:
PHP:
if(isset($_COOKIE['UserID'], $_COOKIE['Password']) || (isset($_SESSION['ID']) && trim($_SESSION['ID'])!=0)) {
$login=false;
$sql_chk = "SELECT * FROM user WHERE Login='".$_COOKIE['UserID']."' AND Password = '".$_COOKIE['Password']."';";
$res_chk = mysql_query($sql_chk) OR die("Accountkontrolle fehlgeschlagen.<br>".mysql_error());
if(mysql_num_rows($res_chk)) {
if(isset($_SESSION['IP']) && $_SESSION['IP']==$ipadresse) $ip=true;
else if(isset($_SESSION['IP'])){
$ip=false;
unset($_SESSION);
$logout=logout();
$check='Ihre Sitzung wurde durch einen IP-Wechsel beendet, bitte loggen Sie sich erneut ein. <a href="?section=login" class="menu">Einloggen</a><br>';
} else
$ip=false;
if(isset($_SESSION['ID']) && trim($_SESSION['ID'])!=0) {
if(isset($_SESSION['Time']) && trim($_SESSION['Time'])>=time()) {
$_SESSION['Time'] = strtotime("+10 minutes");
$row_chk = mysql_fetch_assoc($res_chk);
$login=true;
$sql_upd = "UPDATE
user
SET
LastOn = '".time()."'
WHERE
ID = '".$user['ID']."';";
mysql_query($sql_upd) OR die("Fehler beim Aktualisieren des Guthabens!<br>".mysql_error());
} else {
$logout=logout();
$check='Ihre Sitzung ist abgelaufen, bitte loggen Sie sich erneut ein. <a href="?section=login" class="menu">Einloggen</a><br>';
}
}
}
}
ich schau also nach, ob mein cookie zeugs da ist und schau dann, obs den im cookie stehenden user auch gibt. ich logge den quasi über die cookie infos ein. dann schau ich noch, ob die ip stimmt. hat der kerl plötzlich ne andere ip, ausloggen! isses der richtige, wird er sich scho wieder einloggen, isses der falsche, kann er die "sitzung" nicht übernehmen. dann schau ich noch, ob diese 10 mins nich scho überschritten wurden und bei mir hab ich dann noch geupdated, dass der kerl jetzt zuletzt on war. kann man dann ne online anzeige in nem forum zum bsp verwirklichen. war der kerl innerhalb der letzten 5 mins on, wird er als on dargestellt im forum. als bsp. oder eben simpel nen nachweis der aktivität für clans oder what ever.
gut, wie gesagt, das mit dem login is harter tobak und ich hoff ich hab nich allzuviel mist erzählt, aber bei mir funzt das jedenfalls ganz gut >< aber andere können hier gerne auch noch was dazu sagen. berichtigen, ergänzen oder oder ^^
aber es hatte php syntax-hl, das reichte mir 
. Einiges könnte man natürlich auch abgespeckter verwenden, z.B. die Cookie-Geschichte wäre ja nicht unbedingt ein "Muss", da die Seite ja sowieso nur Firmenintern aufgerufen werden kann/sollte. 
