Hallo Forum,
ich entwickle gerade was für unseren Kunden, dabei muss ich ein Login-Bereich einrichten.Um gleich alles richtig zumachen, wollte ich euch mein kleines und vereinfachtes Konzept vorstellen.
- User gibt Namen und PW auf Seite Login.html ein, via POST wird alles an die Check_Login.php übermittelt.
Warum eine Login.html?
Bei mir ist ein Logn auf jeder "seite" implizit möglich.
Ob eine Login-Prüfung gefordert wird ersehe ich aus einem Formular-Id, die ebenfalls gesendet wurde.
- Check_Login.php verbindet sich mit der DB (MySQL).
2a) Name wird verglichen
- Name wird nicht gefunden? Zurück + Fehlermeldung!
PW wird verglichen
- PW ist falsch? Zurück + Fehlermeldung
Wie und was wird verglichen?
Du solltest keine Klartext Passworte auf dem Server speichern, sondern nur de hashes.
- Name UND PW korrekt?
~~~php
- session_start();
- $_SESSION['sesid'] = md5(session_id());
was liefert die Funktion session\_id() zurück?
Eventuell verschlechterst du mit md5 die Qualität eines erstellten Hashes.
sha1 ist md5 vorzuziehen.
> - Weiterleitung zur der Zielseite
Weiterleitungen finde ich immer doof. Warum nicht den geünschten Kontext direkt ausgeben?
> ============================================================================
>
> Auf jeder Seite auf der nur die User zugriff haben sollen, würde ich folgendes abfragen:
>
> ~~~php
if($_SESSION['sesid'] && $_SESSION['sesid'] == md5(session_id())) ALLES_OK();
> else FEHLER();
Hier verstehe ich nicht, warum du dir jedesmal eine md5 konversion leistest. Die gespeicherten SessionIDs sollten ja bereits hashes sein.
Ist an dieser Logik was Fehlerhaft/Bedenklich?
Je nachdem was du vorhast, ist es Mangelhaft. Mir fehlt zum Beispiel eine Definition für verschiedene Usertypen. Wie loggst du dich als Admin ein?
Wo und wie müsste ich die DB-Zugangsdaten auslagern um sie sicher zu "versteken"?
Du musst sie nicht verstecken. Du musst zuerst die Passworte richtigen Salzen und einen Hash desselben speichern.
mfg Beat
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische