login

Hallo,

es ist doch abartig wie ihr immer auf Lehrbuchwissen und Lehrbuchmethoden zurückgreift

Folgende Variante zum Erstellen einer SessionID...

srand(microtime()*1000000);
$zufall = rand(1,1000000);
$zufall=$zufall.$VielleichtNochDerNutzername; //Oder eben der aktuelle Timestamp
// Kann auch $zufall = session_id().$timestamp; sein
$session = MD5($zufall);

ist in etwa gleichzusetzen mit

session_start();
session_id();

Letztere Variante ist zu gefährlich weil keiner weiß wie viele Sessions der Hoster zur Verfügung stehen hat. Und nicht jeder stinknormale Homepagebastler leistet sich seinen eigenen Root/Managed-Server für geschätzt 100€ im Monat

Lehrbuch schön und gut, aber es gibt auch Grenzen!

VlG

volkard

RandomAccess85 schrieb:

Hallo,

es ist doch abartig wie ihr immer auf Lehrbuchwissen und Lehrbuchmethoden zurückgreift

Folgende Variante zum Erstellen einer SessionID...
srand(microtime()*1000000);
$zufall = rand(1,1000000);
$zufall=$zufall.$VielleichtNochDerNutzername; //Oder eben der aktuelle Timestamp
// Kann auch $zufall = session_id().$timestamp; sein
$session = MD5($zufall);
ist in etwa gleichzusetzen mit
session_start();
session_id();

Kannst Du dafür einen Nachweis erbringen, indem Du Code heranbringst, wie PHP das innendrin macht?

volkard

RandomAccess85 schrieb:

seinen eigenen Root/Managed-Server für geschätzt 100€ im Monat

Kannst Du Dich nochmal über die Preise informieren, und wenn Du bei unter 50€ für einen dedicated und unter 10€ für einen vServer bist? Was soll der Managed-Server bringen, außer daß der Manager PHP-Sachen konfiguriert, ohne daß ich es mitkriege.

nman

RandomAccess85: Für gewöhnlich ist es eine gute Idee, kurz darüber nachzudenken, was Shade und volkard zu sagen haben. Wenn beide an einem Strang ziehen, erst recht. Und in diesem Fall ist das Vorgehen von Shade weithin anerkannte "best practice", dementsprechend wäre es günstiger, Du würdest erläutern, warum Du Dich vor nicht eindeutigen Session-IDs fürchtest.

Sqwan

die session_ids sind doch eindeutig. Jedenfalls werden sie nicht extrem eindeutiger nur weil man nen timestamp anhängt.

Und den ganzen sch*** dann jedes mal mit der Datenbank abgleichen zu müssen stelle ich mir jetzt auch nicht sonderlich performant vor

volkard

Wenn der Webspace-Provider den temp-Speicherplatz so runtergedreht hat, daß Sessions frühzeitig sterben, dann muß man sich mit dem mal unterhalten. Er fängt sich doch bloß damit ein, daß die Kunden ihre Sessions alle in die Datenbank verlagern und die Daten trotzdem auf der Platte landen, dafür aber mehr Rechenpower gebraucht wird. Und das wollen wir doch alle nicht.

Sqwan schrieb:

Und den ganzen sch*** dann jedes mal mit der Datenbank abgleichen zu müssen stelle ich mir jetzt auch nicht sonderlich performant vor

Och, wenn man wie in einem Forum eh die Datenbank aufmacht, ist das schon ok. Mit http://www.dynamic-webpages.de/php/function.session-set-save-handler.php geht es angeblich auch wunderbar, statt der normalen Dateien mysql-Zeilen darunterzulegen.
Alles Sessions-Zeug selber nachprogrammieren würde ich aber nicht. Die schlauen Sachen von PHP, wie auf die IP achten oder auf den HOST, dem der Proxy die Daten weitergibt, bei abgeschalteten Cookies automatisch auf die URL ausweichen und so Krimskrams, auch auf dem aktuellen Stand bleiben, was mit inkompatiblen Browsern Sache ist, das wäre mir nix.

Sqwan schrieb:

die session_ids sind doch eindeutig. Jedenfalls werden sie nicht extrem eindeutiger nur weil man nen timestamp anhängt.

Jup.

RandomAccess85 scheint zu denken, wenn der Hoster an der Schraube dreht und nur 1000 gleichzeitige Sessions zuläßt, daß dann auch der Schlüsselraum auf 1000 mögliche Schlüssel zusammenfällt.

Shade Of Mine

RandomAccess85 schrieb:

es ist doch abartig wie ihr immer auf Lehrbuchwissen und Lehrbuchmethoden zurückgreift

Das hat nichts mit Lehrbuchwissen zu tun. Das ist Erfahrung.
Nicht falsch verstehen bitte, aber gerade so Sachen wie Sicherheit (und Session Managemengt ist ein wichtiger Teil der Sicherheit) sind mir sehr wichtig. Da es hier enorm viel schlechten Code gibt. Ein Beispiel ist zB deine Art der Session ID generierung. Das ist unsicher.

Letztere Variante ist zu gefährlich weil keiner weiß wie viele Sessions der Hoster zur Verfügung stehen hat. Und nicht jeder stinknormale Homepagebastler leistet sich seinen eigenen Root/Managed-Server für geschätzt 100€ im Monat

Tut mir leid ich habe nie Freehoster benutzt. Aber das sollte hier irrelevant sein, denn wenn man sich eben keine 2-3 Euro im Monat leisten kann, dann ist das ein anderes Thema. Ich rede hier davon wie man es richtig macht.

Klar, wenn man keine Infrastruktur hat die etwas taugt, muss man ziemlich bloede Workarounds machen - aber diese Workarounds haben hier nichts verloren.

Wenn du einen bestimmten Workaround auf einem bestimmten Server benutzen musst, ist das deine Sache. Aber um ehrlich zu sein, 2-3 Euro im Monat sollte schon drinnen sein. Du brauchst keinen root Server, Managed Server oder sonstwas, sondern bei all-inkl.com kostet der billigste Webspace 4.95 Euro im Monat. 1GB Speicherplatz, PHP, Perl, MySQL,... und all-inkl ist relativ teuer. Fuer 5 Euro bekommt man mehr als man braucht, wenn man etwas sucht findet man billigere Hoster die halt nicht so gut sind. 1-2 Euro kostet zB Webspace ohne PHP Support. Und in den Preisen ist sogar noch eine Domain drinnen.

Und um ehrlich zu sein: ein Freehoster garantiert keine erreichbarkeit, da wuerde ich lieber selber zu hause hosten...

@ghostboss:
Das verstehe ich nicht. Wenn die Session stribt, also die Session ID ungueltig wird, dann erkennt PHP es daran dass die relevante Datei geloescht wird. Ob du nun etwas in $_SESSION speicherst oder nicht. Oder meinst du, dass du die Session ID nur von PHP generieren hast lassen und ansonsten ein eigenes Session Management implementiert hast?

ghostboss

@Shade Of Mine:
Ich generiere die Session_id nur um den User zu identifizieren. Wenn der User sich Einloggt, dan erstelle ich die Session_id und speichre sie in DB und Cookie.
Ich könnte auch die Id des User im Cookie speichern, aber dann könnte "man" ja selber ein Cookie erstellen (ka ob das geht) und "irgendeine" Id rein schreiben, und schon ist man Admin.
Und mit Session_id geht das nicht so leicht.

Sonst hab ich kein Management.

Shade Of Mine

ghostboss schrieb:

Ich generiere die Session_id nur um den User zu identifizieren. Wenn der User sich Einloggt, dan erstelle ich die Session_id und speichre sie in DB und Cookie.
Ich könnte auch die Id des User im Cookie speichern, aber dann könnte "man" ja selber ein Cookie erstellen (ka ob das geht) und "irgendeine" Id rein schreiben, und schon ist man Admin.
Und mit Session_id geht das nicht so leicht.

Natuerlich schreibt man die Session ID ins Cookie, das ist ja die Idee warum man ueberhaupt eine Session ID generiert.

Meine Frage war ja: ob du die Session ID selber generierst oder ueber session_start() und dann per session_id() ausliest?

ghostboss

Mit session_start() und session_id()

Shade Of Mine

ghostboss schrieb:

Mit session_start() und session_id()

Und warum speicherst du die Daten dann nicht in $_SESSION?

Du nimmst mit session_start() alle Nachteile des PHP Session Managements mit, tust aber die Vorteile selber implementieren.

Was genau ist die Idee dahinter $_SESSION nicht zu verwenden? Du sagst du konntest dich auf $_SESSION nicht verlassen, nur faellt mir dazu keine Server Konfiguration ein wo ich das reproduzieren koennte.

Denn wenn $_SESSION vom Server geloescht werden wuerde, dann waere automatisch die Session ungueltig und session_start wuerde eine neue Session ID generieren. Aber gut, wenn es technische Gruende gibt warum das auf einem bestimmten Server nicht klappt...

Ich wuerde dir dennoch empfehlen das Session Management entweder komplett selber zu machen oder komplett PHP zu ueberlassen. Du kannst ueber session_set_save_handler() naemlich auch die Session Daten in eine Datenbank oder sonstwohin speichern.

Shade Of Mine schrieb:

Tut mir leid ich habe nie Freehoster benutzt. Aber das sollte hier irrelevant sein, denn wenn man sich eben keine 2-3 Euro im Monat leisten kann, dann ist das ein anderes Thema. Ich rede hier davon wie man es richtig macht.

Klar, wenn man keine Infrastruktur hat die etwas taugt, muss man ziemlich bloede Workarounds machen - aber diese Workarounds haben hier nichts verloren.

Wenn du einen bestimmten Workaround auf einem bestimmten Server benutzen musst, ist das deine Sache. Aber um ehrlich zu sein, 2-3 Euro im Monat sollte schon drinnen sein. Du brauchst keinen root Server, Managed Server oder sonstwas, sondern bei all-inkl.com kostet der billigste Webspace 4.95 Euro im Monat. 1GB Speicherplatz, PHP, Perl, MySQL,... und all-inkl ist relativ teuer. Fuer 5 Euro bekommt man mehr als man braucht, wenn man etwas sucht findet man billigere Hoster die halt nicht so gut sind. 1-2 Euro kostet zB Webspace ohne PHP Support. Und in den Preisen ist sogar noch eine Domain drinnen.

Den Vortrag ansich hab ich verstanden. Aber ich habe nicht verstanden wieso du ihn hälst :p

Nur ums klarzustellen:
Ich darf mich Besitzer eines Root-Servers nennen und muss nicht rumfrickeln um eine anständige Session zu Stande zu bekommen. Ich bin mit dem Root-Server aber auch kein Maßstab. Ich gehe von Hobby-Bastlern aus, die eben diese Möglichkeit nicht haben. Und bei "all-inkl" hat man z.B. keine Möglichkeit an den PHP-Ini's zu schrauben. All-inkl selbst sagt sogar aus, dass wen man eine Verbesserung haben möchte, man sich einen Managed-Server zulegen muss (welcher im Monat ab 79€ aufwärts kostet) ...

Was genau ist die Idee dahinter $_SESSION nicht zu verwenden? Du sagst du konntest dich auf $_SESSION nicht verlassen, nur faellt mir dazu keine Server Konfiguration ein wo ich das reproduzieren koennte.

session.cookie_lifetime = 1;
= ziemlicher Blödsinn, könnte aber genau die Situation nachstellen

apache2 reload
= leert soweit ich weiß auch den Session-Cache

apache2 restart
= siehe oben

VlG

Shade Of Mine

RandomAccess85 | offline schrieb:

Nur ums klarzustellen:
Ich darf mich Besitzer eines Root-Servers nennen und muss nicht rumfrickeln um eine anständige Session zu Stande zu bekommen. Ich bin mit dem Root-Server aber auch kein Maßstab. Ich gehe von Hobby-Bastlern aus, die eben diese Möglichkeit nicht haben. Und bei "all-inkl" hat man z.B. keine Möglichkeit an den PHP-Ini's zu schrauben. All-inkl selbst sagt sogar aus, dass wen man eine Verbesserung haben möchte, man sich einen Managed-Server zulegen muss (welcher im Monat ab 79€ aufwärts kostet) ...

Für 5 Euro bekommst du alles was du brauchst. Du brauchst für normale Anwendungen keine Änderungen an der php.ini

Du springst von einem extrem ins andere: Rootserver und Freehoster sind 2 extreme die man idR nicht braucht. Wir hosten zB viele Kundenseiten auf all-inkl - ohne Rootserver. php.ini Anpassungen waren noch nie notwendig. Und schon garnicht für so triviale Sachen wie eine Session.

session.cookie_lifetime = 1;
= ziemlicher Blödsinn, könnte aber genau die Situation nachstellen

Nope, stellt die Situation nicht nach, da die Session ID verloren geht und somit das Speichern in der DB nichts bringt da bei einem neuen Request des Users keine Session ID mitgesendet wird.

apache2 reload
= leert soweit ich weiß auch den Session-Cache

Nope.

apache2 restart
= siehe oben

Nope.

Shade Of Mine schrieb:

Du springst von einem extrem ins andere: Rootserver und Freehoster sind 2 extreme die man idR nicht braucht. Wir hosten zB viele Kundenseiten auf all-inkl - ohne Rootserver. php.ini Anpassungen waren noch nie notwendig. Und schon garnicht für so triviale Sachen wie eine Session.

Ist toll für dich, bedeutet aber noch lange nicht dass das der Normalzustand ist. Frag mal nach memcache (ebenso trivial wie Sessions) bei all-inkl...

Shade Of Mine schrieb:

Nope, stellt die Situation nicht nach, da die Session ID verloren geht und somit das Speichern in der DB nichts bringt da bei einem neuen Request des Users keine Session ID mitgesendet wird.

Deswegen steht sie doch in der DB => damit sie eben nicht verloren geht...
Es geht hier immernoch um einen Login und lediglich um eine SessionID, NICHT um Session-Daten! Was bedeutet, dass sie einmal vergeben wird und danach nur noch der Identifizierung nützt.

Shade Of Mine schrieb:

Zitat:
apache2 reload
= leert soweit ich weiß auch den Session-Cache

Nope.

Zitat:
apache2 restart
= siehe oben

Nope.

Ok, da hab ich mich getäuscht. Ich bin davon ausgegangen, dass zumindest der Restart sämtliche Prozesse killt und die Sessions als "Garbage-Data" weiter behandelt werden, die gemäß Standardkonfiguration nach 3 Minuten entsorgt werden.

VlG

P.S. Im Offline-Post gingen die Quotes etwas daneben. Könnte den bitte einer löschen? Danke!

Shade Of Mine

RandomAccess85 schrieb:

Ist toll für dich, bedeutet aber noch lange nicht dass das der Normalzustand ist. Frag mal nach memcache (ebenso trivial wie Sessions) bei all-inkl...

Birnen und Äpfel.

Aber bitte, dann geh auf einen anderen Hoster. memcache ist bei einem 5 Euro Host aber komplett irrelevant. memcache brauchst du nur aus Performance Gründen die bei 5 Euro egal sind. Geld sollte also wirklich keine Rolle spielen. Wenn man kein Geld hat nimmt man einen billigen Hoster und verzichtet auf advanced Features, wenn man mehr Geld hat bekommt man auch diese Features dazu.

Das ist aber alles nicht Thema. Denn Sessions funktionieren immer.

Shade Of Mine schrieb:

Nope, stellt die Situation nicht nach, da die Session ID verloren geht und somit das Speichern in der DB nichts bringt da bei einem neuen Request des Users keine Session ID mitgesendet wird.

Deswegen steht sie doch in der DB => damit sie eben nicht verloren geht...
Es geht hier immernoch um einen Login und lediglich um eine SessionID, NICHT um Session-Daten! Was bedeutet, dass sie einmal vergeben wird und danach nur noch der Identifizierung nützt.

Wenn die lifetime des Cookies zu niedrig steht, dann wird bei dem nächsten Request des Users die Session ID aber nicht mitgesendet weil das Cookie ausgetimt ist. dh du hast auf der Serverseite keine Ahnung mehr welche Session ID dieser User hat. Ergo ist es egal wo du die Daten gespeichert hast: du hast die Session ID verloren und damit die Daten.

Ich bin davon ausgegangen, dass zumindest der Restart sämtliche Prozesse killt und die Sessions als "Garbage-Data" weiter behandelt werden, die gemäß Standardkonfiguration nach 3 Minuten entsorgt werden.

Die Session Daten liegen in einem temp Verzeichnis als einfache Dateien. Du musst schon den kompletten Server neustarten um eventuell das Verzeichnis zu killen. Ansonsten kannst du natürlich die Daten auch in einer Datenbank oder ähnliches stehen haben. Standard bei PHP sind halt Dateien in einem temp Verzeichnis, lässt sich aber alles konfigurieren.

Kann es sein dass du krampfhaft versuchst Gründe zu finden warum du nicht $_SESSION verwenden willst? Da kann ich dir helfen: es gibt genau einen relevanten Grund: Performance auf Clustern. Aber da gehen wir jetzt erstmal nicht näher ein, da das für einen normalen Programmierer irrelevant ist, da die meisten Leute nie in so eine Situation kommen werden.

PS:
und selbst in so einer Situation könnte man die Standard PHP Sessions verwenden mit einer eigenen PHP Extension.

Sqwan

Shade Of Mine schrieb:

Kann es sein dass du krampfhaft versuchst Gründe zu finden warum du nicht $_SESSION verwenden willst? Da kann ich dir helfen: es gibt genau einen relevanten Grund: Performance auf Clustern. Aber da gehen wir jetzt erstmal nicht näher ein, da das für einen normalen Programmierer irrelevant ist, da die meisten Leute nie in so eine Situation kommen werden.

PS:
und selbst in so einer Situation könnte man die Standard PHP Sessions verwenden mit einer eigenen PHP Extension.

Das erklär mir aber bitte mal. Wieso sollte ich auf $_SESSION verzichten. Das interessiert mich doch als Kunde garnicht. Damit kann sich der hoster rumschlagen. Wenn der Hoster mir die sessions nicht iwie ganz verbietet, dann kann ich sie auch nutzen.
Also als nutzer interessiert mich sowas an für sich garnichts. Egal ob ich ein "normaler Programmierer" bin oder eben nicht. Was auch immer jetzt ein unnormaler ist.

Shade Of Mine

Sqwan schrieb:

Das erklär mir aber bitte mal. Wieso sollte ich auf $_SESSION verzichten. Das interessiert mich doch als Kunde garnicht. Damit kann sich der hoster rumschlagen. Wenn der Hoster mir die sessions nicht iwie ganz verbietet, dann kann ich sie auch nutzen.
Also als nutzer interessiert mich sowas an für sich garnichts. Egal ob ich ein "normaler Programmierer" bin oder eben nicht. Was auch immer jetzt ein unnormaler ist.

Sollst du ja eben nicht, das sage ich ja die ganze Zeit. Ich wiederhole mich hier scheinbar nur... Ich sage die ganze Zeit: PHP Session Management benutzen!

Es gibt lediglich eine Situation wo es Sinn machen kann auf $_SESSION zu verzichten. Und das ist so eine spezielle Situation dass wir sie eigentlich nicht zu diskutieren brauchen.

Wenn du nämlich einen eigenen Cluster hast, hast du ja das Problem dass du die Session Daten nicht lokal auf dem Server speichern kannst. Da HTTP nämlich Stateless ist, ist nicht garantiert dass der User wieder auf diesem Server landet.

Wenn du die Daten nun zwischen allen Servern sharen musst dann brauchst du teilweise einfach Custom Lösungen. Je nachdem wie die Struktur aussieht und was du technisch machen kannst. Hier kann es sein dass du an die Grenzen des PHP Session Management stößt. idR sollte sich das zwar mit einer eigenen PHP Extension lösen lassen, aber uU ist dann dennoch sinnvoller das Management selber zu schreiben.

Aber wie gesagt: das sind so spezielle Situationen dass wir hier eben nicht darüber reden sollten. Denn die wenigsten Leute werden je in so eine Situation kommen.

Mit "normal" meine ich Leute die nicht in solchen extrem Situationen sind.

Shade Of Mine schrieb:

Wenn die lifetime des Cookies zu niedrig steht, dann wird bei dem nächsten Request des Users die Session ID aber nicht mitgesendet weil das Cookie ausgetimt ist. dh du hast auf der Serverseite keine Ahnung mehr welche Session ID dieser User hat. Ergo ist es egal wo du die Daten gespeichert hast: du hast die Session ID verloren und damit die Daten.

Wer hat was von Cookies gesagt? Wenn ich die Session z.B. in der URL mitschiebe, brauch ich keinen Cookie?! Dann muss ich nur noch in der Datenbank prüfen ob "URL-Session" zu "DB-Session" passt und das wars. Mit Logout, oder nach Timeout wird die Session aus der DB gelöscht (falls die Frage auftaucht)...

Shade Of Mine schrieb:

Kann es sein dass du krampfhaft versuchst Gründe zu finden warum du nicht $_SESSION verwenden willst? Da kann ich dir helfen: es gibt genau einen relevanten Grund: Performance auf Clustern. Aber da gehen wir jetzt erstmal nicht näher ein, da das für einen normalen Programmierer irrelevant ist, da die meisten Leute nie in so eine Situation kommen werden.

Um Himmels Willen: Nein! Ich bin jetzt eines Besseren belehrt. Meine Erfahrung gegen dein Wissen. Meine Erfahrung lügt, dein Wissen hat Recht und ich meine Ruhe ;)!

VlG

Shade Of Mine

RandomAccess85 schrieb:

Wer hat was von Cookies gesagt? Wenn ich die Session z.B. in der URL mitschiebe, brauch ich keinen Cookie?! Dann muss ich nur noch in der Datenbank prüfen ob "URL-Session" zu "DB-Session" passt und das wars. Mit Logout, oder nach Timeout wird die Session aus der DB gelöscht (falls die Frage auftaucht)...

dh du verwendest nur Sessions per URL Übergabe? Die Risiken kennst du, oder?

Weiters ist das immernoch kein Problem in diesem Szenario da cookie Lifetime und Session Lifetime 2 unterschiedliche Sachen sind. Nur so angemerkt

Du verwendest also das PHP Session Management nur zum generieren der Session ID und sonst zu garnichts? Nichtmal Cookies, transid, etc? Das ist natürlich eine ziemlich schlechte Idee, da du alle Nachteile des PHP Session Managements dadurch übernimmst, nur die Vorteile nicht.

zB lockt PHP die Session Datei wären der Ausführung des Scripts, was zB bei asynchronen Anfragen durchaus merkbar bremst. Auch wenn du nichts in $_SESSION reinschreibst.

Shade Of Mine schrieb:

Kann es sein dass du krampfhaft versuchst Gründe zu finden warum du nicht $_SESSION verwenden willst? Da kann ich dir helfen: es gibt genau einen relevanten Grund: Performance auf Clustern. Aber da gehen wir jetzt erstmal nicht näher ein, da das für einen normalen Programmierer irrelevant ist, da die meisten Leute nie in so eine Situation kommen werden.

Um Himmels Willen: Nein! Ich bin jetzt eines Besseren belehrt. Meine Erfahrung gegen dein Wissen. Meine Erfahrung lügt, dein Wissen hat Recht und ich meine Ruhe ;)!

Jedenfalls scheint deine Erfahrung mit Session Management nicht so toll zu sein

Oder hast du auch nur ein einziges Argument das gegen $_SESSION spricht (von meinem extrem Beispiel abgesehen)?

ghostboss

So, ich bins noch mal.

* warum speichere ich keine Daten in $_SESSION und warum konnte ich mich auf $_SESSION nicht verlassen?

-> als ich mit Html...Php programmieren angefangen habe, wollte ich erstmal für kein Server zahlen weil ich Anfänger war und nicht wuste wie weit ich komme (kann man ja nachvollziehen ). Also habe ich auf einem Freehoster (www.funpic.de) meine Html...Php Seiten getestet. Und da habe ich dann ein Clan Seite aufgebaut. Als ich ein Loginsystem machen wollte, hab ich erstmal versucht die Daten in $_SESSION zu speichern. Doch nach paar Minuten (mal 9, mal 15, mal 3) wurde die Session zerstört, oder so, auf jeden Fall war die weg. Also habe ich das so gelöst dass ich die session_id() in die DB und Cookie gespeichert habe.

Jetzt habe ich einen richtigen Server und hab einfach mal mein System übernommen, weil das so gut funktionier hat. Aber wenn ich Zeit habe versuche ich es mit Session .
(wo kann ich denn die Session einstellen? Im Script oder bei Serverkonfigurations Seite?)

Und noch was. Ich nutze die session_id() nur um den User zu identifizieren.

if( cookie(session_id) == DB(session_id) ) user = lars
else user = gast

Ich könnte doch statt session_id irgendwas andres hashen, z.B. md5(user_name) oder md5(timestamp()) (ist nur ein Beispiel). Und schon habe ich auch eine Id die ich in DB und Cookie speichern kann und brauche die ganzen Sachen von Session nicht mehr.

Was spricht denn eigentlich gegen mein Login-System? (DB und Cookie)
* wegen DB verbindung bei jeder Seite um User zu identifizieren? (ein DB connect zuviel)
* unsicher? (wieso)
* Cookie?
* ???