Cheatah: Cookies testen und Langzeit-Cookies

Beitrag lesen

Hi,

und wenn es sich nicht um ein Formular handelt? Wie könnte es anders
sein?

dann wäre es vermutlich ein Link. Das entsprechende Äquivalent wäre ein URL-Parameter.

zu a) fällt weg,

Kommt drauf an wofür.

zu b) hört sich gut an, nur der Nachteil ist, dass ich kein "Autolog"
implementieren kann

Automatisches Login? Das ist eine völlig andere Funktion, die mit der Identifizierung eines eingeloggten Users absolut nichts zu tun hat. Es ist hierzu eine separate, unabhängige Betrachtung nötig.

zu c) die Passwörter werden in eine Datenbank (Oracle) hinterlegt und
ich kann mir nicht vorstellen, dass der Webserver auf die Datenbank
zugreift und das Passwort dort selektieren kann, oder?

Na, was denn sonst? Der HTTP-Server kann wunderbar als SQL-Client auftreten.

Aber welche dieser Varianten ist die sicherste?

Sicher in Bezug auf ...?

Ich könnte mich auf
einen Kompromiss einlassen... Eine ID wird in allen drei Fällen
übersendet, was also in allen drei Fällen "ausgehorcht" werden kann.

Was bei HTTPS schwieriger wird. Unmöglich natürlich nicht.

Darüber hinaus möchte ich gerne, dass sich ein Benutzer nur einmalig
anmelden muss und er jedesmal, wenn er die Seite betritt, sofort
erkannt wird - sofern er das möchte - und das kann man doch nun
wirklich nur mit einem Cookie lösen. Oder täusche ich mich?

Jein. Das kann man mit einem Cookie lösen, oder indem man ihn die Basis-Funktionen seines Browsers nutzen lässt, die nun mittlerweile wirklich _jeder_ Browser besitzt.

Zudem: was ist _so_schlimm_ an einem Cookie?

Nichts. Sofern man sie nicht voraussetzt. Dann ist das selbe schlimm daran, wie beim Einsatz von z.B. JavaScript: Im Zweifel funktioniert es nicht.

Cheatah

--
X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes