Holger?
Hi, bei GET werden Formulardaten in der URL �bertragen: http://.../Test.asp?feld1=abc&feld2=123 feld1 und feld2 w�ren in diesem Fall die Formularfelder, die �bertragen werden. Ausgelesen per: Request.QueryString("feld1") Bei dieser Variante ist die m�gliche Datenmenge eher gering, daf�r kann man leicht Links zusammenbasteln, die entsprechende Daten �bertragen. (dazu vgl. Server.URLEncode("Text mit Sonderzeichen & Co?")) Bei POST werden die Daten innerhalb des HTTProtokols �bertragen; scheinbar versteckt. Genau genommen stehen die Daten jedoch im Klartext im der HTTP-Anfrage. Darum ist bei Logins die verschl�sselte �bertragung per HTTPS zu empfehlen. Sonst kann jeder Netzknoten zwischen Dir und dem Client das Login Deines Benutzers mitlesen. Bei POST k�nnen wesendlich mehr Daten �bertragen werden, z.B. Dateien oder gro�e Textfelder k�nnen oft nur per POST �bertragen werden. Abfragen: Request.Form("feldname") Gru� Heiko Richler Fachbereich Informatik Georg-Simon-Ohm-Fachhochschule N�rnberg http://www.informatik.fh-nuernberg.de/heiko.richler/ > -----Original Message----- > From: Patrick-M. Engel [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 27, 2002 5:49 PM > To: ASP Diskussionsliste fuer Anfaenger > Subject: [aspdebeginners] AW: RE: Session-Variablen > > > Hi, > > > 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 .... > > Wie, was? "POST" und "GET" (was ist da eigentlich der > Unterschied?) verwende > ich doch, wenn ich ein Formular absende. Und meinst, die > �bertragung des > Passwortes per Formular-Feld sei unsicher? Aber wie soll ich > es denn sonst > vom Client zum Server bekommen? In eine Session-Variable > bekomme ich das > clientseitig bei Eingabe ja nicht rein (was auch gut so ist, > sonst w�ren ja > Session-Variablen vom Client aus bef�llbar). Wie �bertr�gst > Du denn die > LogIn-Daten? > > Liebe Gr��e > Patrick > > > -----Urspr�ngliche Nachricht----- > Von: Mansur Esmann [OM] [mailto:[EMAIL PROTECTED]] > Gesendet: Donnerstag, 27. Juni 2002 17:20 > An: ASP Diskussionsliste fuer Anfaenger > Betreff: [aspdebeginners] RE: Session-Variablen > > > > > > > > > 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
