> > > Hallo Holger, > > danke f�r die prima Antwort. Folgende Nachfragen: > > > > a.) Unter welchen Umst�nden funktionieren Session-Variablen > > > nicht (Mit Cookies gibt es z.Bsp. Bei IE6 Probleme)? > > Eine Session erfordert zumindest tempor�re Cookies. > > Okay, k�nnen diese tempor�ren Cookies deaktiviert werden? Kann es > also sein, > dass ein Teilnehmer seinen Browser so einstellt, dass er _nicht_ mit > Session-Variablen funktioniert?
Hi, Ja session-Cookies k�nnen deaktiviert werden. Es gibt aber auf den Browsern eine Unterscheidung dazu: -Alle Cookies ablehnen -Alle Cookies annehmen -Sitzungscookies immer akzeptieren (Optional) > > > > > b.) Werden die Session-Variablen im Server gehalten (da ja im ASP > > > zug�nglich) oder - bzw. oder auch - am Client? > > Die Session wird per Cookie wiedererkannt. Dieser Cookie liegt nat�rlich > > beim Client. Die abgelegten Daten bleiben jedoch auf dem Server. > > Das ist ja prima! Ich k�nnte also, bei erfolgreichem LogIn (Passwortcheck) > einfach die UserID in die Session-Variable "UserID" reinschreiben ... und > wenn da was drin ist, dann gilt der User als eingeloggt. Und das > ist sicher > NICHT manipulierbar vonseiten den Users? (Davon ausgehend, dass der Server > sicher ist). Ich habe dabei n�mlich noch ein unwohles Gef�hl, > denn wenn ein > User irgendwie irgendeine User-ID selbst in die Session-Variable 'UserID' > reinbekommt, w�rde er als eingeloggt unter dieser ID gelten. Das > w�re nicht > so toll. Sessions sind ansich sicher im kontext des verwendeten Servers und des verwendeten Protokolls. Server muss halt sicher sein Protokoll http: (Nicht verschl�sselt) k�nnen ja mit geeigneten Mitteln ausspioniert und auch manipuliert werden. Dies ist aber die Aufgabe eines guten Hackers (Nicht die Script Kiddys). Alternativ dazu kann man SSL verschl�sseln (https://) hierbei ist ein aushorchen, sowie manipulieren der Sessions nahezu unm�glich. sessions sind eine �bliche Art Login-Informationen zu speichern. Laut gesetz soll man wohl dies aber in den AGB's der Site verlautbaren, damit der User damit einverstanden sein kann. Einzige Alternative dazu ist ja "POST" und "GET", wobei diese ja wesentlich unsicherer sind, da sie in "reintext" �bertragen werden und somit nicht nur die Referenz auf das Passwort sichtbar ist (Sessions), sondern de facto das passwort selber .... Also sessions ist was auf das man nicht verzichten kann und sehr gut im Griff haben sollte. Gru� Mansur > > Liebe Gr��e > Patrick > > | Oft Gefragtes: http://www.aspgerman.com/aspgerman/faq/ | [aspdebeginners] als [email protected] subscribed | http://www.aspgerman.com/archiv/aspdebeginners/ = Listenarchiv | Sie knnen sich unter folgender URL an- und abmelden: | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdebeginners.asp
