NONNNNN

Hallo erstmal.

Bin recht neu und arbeite seit einiger Zeit mit PHP. Begonnen hab ich jedoch erst mit PHP 5

Ich habe bald ein kleines Diplomprojekt und möchte mich auch jetzt schon damit auseinandersetzen und mir möglichst gute Dinge überlegen, die ich danach nur noch umsetzen muss.

Also, es geht bei dem Projekt um eine Website mit Login. Alles läuft also intern ab und ist eigentlich nicht relevant.

Ich habe mich nun also mal hingesetzt und mir Gedanken darüber gemacht, wie ich das am besten aufbaue. Sprich das Login, die ganze Session Sache und die Datenbank.

Meine Schwerpunkte:

- Sessions in die Datenbank
- Ohne Cookies arbeiten, immer die Session in die url werfen
- Saubere URL's, bis auf die sessid^^ (mit mod_rewrite) also etwa so url.com/sessid/page
- Alles soll über eine Seite laufen, von der aus die jeweiligen Pages includet werden...
- Sicheres Login
- SSL Verschlüsselung

Gut, das wären mal meine Punkte, die sicher rein kommen sollen.

Ich weis, jeder hat einen anderen Denkansatz, daher ist mir eure Meinung auch sehr wichtig Wie würdet ihr das ganze handeln? Was haltet ihr von den folgenden 3 Klassen?

db_handler:
Ist zuständig für einen abstrakten Zugriff auf die Datenbank. Arbeitet mit mysqli und beinhaltet Methoden für vielerlei Dinge, unter anderem das escapen von Formularinhalten die in die DB kommen und natürlich die Verbindungen mit einer oder mehreren DB's. Zudem liefert er ein Result zurück, das mittels Argument eben fetch, row, assoc oder array ist.

session_handler:
Der Session-Handler ist für das Session-Management zuständig. Er schreibt die Sessions in eine DB und erstellt auch die Einträge in der Supeglobalen $_SESSION Variable.
Zudem liest er sie aus.

jetzt wirds interessannt. Hab nämlich noch nie ein richtiges Login geschrieben

login_handler:
Der loginhandler prüft die Usereingaben beim Login und danach bei jeder neuen Aktion, ob der User noch eingeloggt ist und ob die session id's übereinstimmen.
dabei wird die session id in der session mit der in der id in der db tabelle der session und des users vergleicht. stimmt sie, gehts normal weiter, stimmt sie nicht, wird alles zurückgesetzt und man bekommt das login zu gesicht.

Die Seite möchte ich über die index.php laufen lassen. Da wird geprüft, ob wer eingeloggt ist, wenn ja wird eine neue seite includet und und und. Hat meiner Meinung nach den Vorteil, dass ich diese ganze Sessionhandling sache nur an einem ort durchführen muss...


So, hört sich in der Theorie gut an, aber ist es das auch? Habe noch nie ein Login geschrieben um ehrlich zu sein, hatte mich damit nie beschäftigen müssen.

Kann mir jemand gute Tips geben? Sind meine Ansätze korrekt? Evt hat jemand ja ne bessere methode um sicher zu stellen, ob ein user noch eingeloggt ist oder nicht.


Gruss und Danke schonmal im Voraus.

Mister Ad

Black Sliver

Das Thema ist mal ganz interessant. Ich finde Sessions, Logins & Co. sind das größte Thema im Gebiet der Sever-Sided Scripts.

1. db_handler:
Je nachdem wie komplex die Aufgaben sind kann's gut oder auch schlecht sein ein einheitliches Interface einzuführen. Für ein Browsergame (leider nie fertig geworden), hab ich ein paar Funktionen geschrieben, die Datenbankabfragen sehr vereinfachen und ein Array zurück geben. Wenn noch keine Verbindung besteht, eine erstellen, etc.

Je nachdem, wie komplex das ganze wird, kannst du auch auf Klassen zurückgriefen. Für mich haben jedoch stink normale Funktionen absolut gereicht.

2. session_handler:
Sessions in URIs (also nicht GET) zu packen ist ganz ganz schlecht für Suchmaschienen! Am Besten nimmt man Cookies, dann funktioniert ein kopierter Link zu 100%. Ansonsten kopiert man mit Links gleich das Login mit
Zusätzlich zur Session-ID kann man auch irgendeinen Hash einführen, der eine eindeutige Identifizierung sicherstellt.
Optional die Session per GET mitzugeben ist OK (per Häckchen beim Login).

3. login_handler:
Wenn du SSL verwendest, musst du dir eigentlich nicht mehr viel Gedanken zur Sicherheit machen. Grundsätzlich sollte man aber nur Hashes von Passwörtern inner DB speichern. Per JS kannst du dann auch gleich beim User den Hash von seinem Passwort beim Login generieren lassen und musst dann nurnoch die 2 Hashes (DB, POST) vergleichen. Wenn der User kein JS aktiviert hat, macht das auch nix. Du kannst dann das übertragene, ungehashte Passwort am Server Hashen.
Stichwörter: MD5, onSubmit, Hidden Input


Ich hab ganz ehrlich noch kaum ein PHP-Projekt richtig fertiggestellt, jedoch schon eine Menge User- / Login-Systeme geschrieben und die obigen Punkte sind 100% Erfahrung.

Thomas

Hi,

zu 1.
Ein Interface für Datenbanken ist in der Regel eine gute Sache, falls die Datenbank austauschbar sein soll. Wenn du eh nur Mysql nehmen wirst, dann kannst du auf ein Interface verzichten und die Datenbanklasse irgendwie implementieren.

zu 2.
Die Session über die URL mitzuschleifen würde ich immer vermeiden, wegen oben genannten Grund des Logins mitkopieren. Für Suchmaschienen sehe ich da kein Problem, da diese eh nicht in den Loginbereich kommen, wo erst die Session zu sehen ist.

zu 3.
MD5 würde ich heute nicht mehr verwenden, da schon zu leicht Kollisionen vorkommen. Den Umweg über JS beim verschlüsseln würde ich nicht gehen, da du eh für den Fall, dass JS nicht aktiviert ist, das Passwort auf dem Server verschlüsseln musst.

Du sagst "Alles soll über eine Seite laufen, von der aus die jeweiligen Pages includet werden...". Das ist in Ordnung, aber es scheint als würdest du nicht OOP programmieren? Denn du würdest dann keine Seiten includen (wenn überhaupt dann nur die Klassen) sondern einfach nur die Aufgabe an die zuständigen Klassen delegieren.

Gruß Thomas

Black Sliver

zu 3. bei z.B. 1...12-Zeichen-Passwörtern, aus denen 16-Byte-Hashes gemacht werden, kommt es kaum zu kollisionen. Bzw. zu keinen die einfach mal so vorkommen.

Der Sinn hinter dem gehashten Passwort ist neben der sicheren Übertragung (da schon per JS) auch die Privatspere des Benutzers. Ich WILL die Passörter meiner User nicht wissen!

Zur Sache wegen JS:
Wenn JS aus ist, wird das Passwort im <input type="password" name="password" ...> übertragen,
wenn JS an ist, dann gehasht in <input type="hidden" name="password_hash" ...> übertragen.
Ich sehe da keine Probleme fürs Script. Für die Leute mit JS an ist die Übertragung sicherer und der Server wird ein wenig entlastet.

NONNNNN

Naja, ich arbeite schon OOP, nur gibt es nicht nur eine Ausgabe womit ich einfach ne neue Klasse include. Irgendwoher müssen die Templates ja kommen? Oder hab ich OOP falsch verstanden? Es ist ja nahezu unmöglich eine ganze Website NUR OOP zu erstellen?

Mach doch mal ein Beispiel, das hilft mir sicherlich Kann dir auch meine MSN oder Email geben.


Wegen den Session-Informationen... Also soll ich alles über Cookies lösen und dann einfach die Session-ID da reinschreiben und kann so dann ohne URL nur durch Cookie und DB den User ermitteln... Würde aber bedeuten, dass Cookies ein MUSS sind?


So, dann mal danke für die bisherige Hilfe.

agrajag

Verwende einfach die ganz normale Session-Funktionalität von PHP. WIE genau die Session-ID dann übermittelt wird ist Einstellungssache und kann dir ja erstmal komplett egal sein.
Du kannst darüber natürlich noch eine eigene Session-Klasse oder so drüber stülpen - aber dadurch ändert sich nicht viel.

__________________
Today you...Tomorrow me.

NONNNNN

Jo hab nen session handler geschrieben, der die sessions in die db legt anstatt ins tmp verzeichnis.
ists ned besser, wenn ich NUR cookies oder sessions nehme? beides ist immer so ne sache... will nen durchgehendes bild haben. also mal mit sessionid und mal ohne ist ja nicht der bringer...

ists nicht sogar sicherer, wenn ichs nur über cookies laufen hab? dann muss n user einfach zwangshaft cookies akzeptieren, damit er die seite nutzen kann...

ne andere möglichkeit als die session id über die url und cookies gibts ja nicht

Thomas

Hi,

Wenn du von Template sprichst, dann hast du ja eine Templateklasse, welche die HTML Seiten einliest und zurückgibt zum ausgeben. Irgendwo in deiner index.php wird also die Ausgabe des Templates erfolgen. Dadurch das du deine HTML Seiten über die Templateklasse ansteuerst ist es ja in OOP gehalten. Die Seiten wirst du dann aber mit file_get_contents einlesen und nicht als include einbinden.

Gruß Thomas

NONNNNN

hm das wär natürlich was... nur muss ich gestehen, dass ich noch nie eine templateklasse geschrieben hab :S hast du dafür nen gescheites tut?
darfst auch gerne selber lehrer spielen

gruss und danke.

agrajag

Versteh ich nicht. Wenn du eine Session verwendest muss die Session-ID übertragen werden. Letztlich wird sie entweder in einem Cookie gespeichert oder per URL übertragen.

Versteh ich auch nicht

Es kommt drauf an was du unter sicherer verstehst... Du hast eben wengier Probleme mit Session-Hijacking weil die Gefahr, dass Links mit Session-IDs weitergegeben werden wegfällt...

Ich glaube irgendwie wir reden aneinander vorbei Ich wollte eigentlich nur darauf aufmerksam machen, dass es in der Regel nicht nötig ist selbst per setCookie() ein Cookie zu setzen, sondern dass das die Session-Funktionen von PHP übernehmen...(können).

__________________
Today you...Tomorrow me.