Cookies testen und Langzeit-Cookies

[opi]

Hallo zusammen,

mich würde mal interessieren, wie Ihr so die Möglichkeit testet,
ob beim Besucher das Setzen von Cookies erlaubt ist und wie Ihr
Eure Langzeit-Cookies terminiert.

Beim Testen von Cookies dachte ich an ein http-equiv="refresh"
content="0:...", aber ist das so Gang und Gebe oder gibt es hierfür
Standardmethoden?

Das Gleiche würde ich dann gerne für Browsertypen einsetzen, nur
senden tatsächlich alle Browser den "User-Agent" im Request-Header?

Greez,
opi

[Cheatah]

Hi,

mich würde mal interessieren, wie Ihr so die Möglichkeit testet,
ob beim Besucher das Setzen von Cookies erlaubt ist

das testen wir selbstverständlich gar nicht, weil es sich erstens gar nicht testen lässt und zweitens uninteressant ist, zumal wir die volle Funktionalität eh auch ohne Cookies garantieren.

und wie Ihr Eure Langzeit-Cookies terminiert.

So, wie es für den jeweiligen Anwendungsfall sinnvoll ist.

Beim Testen von Cookies dachte ich an ein http-equiv="refresh"
content="0:...",

Das bringt exakt gar nichts, bis auf einen neuen Request.

Das Gleiche würde ich dann gerne für Browsertypen einsetzen,

Warum das? Es ist völlig uninteressant, welcher Browser verwendet wird.

nur senden tatsächlich alle Browser den "User-Agent" im Request-Header?

Keine Ahnung. Das ist aber auch egal, da die Information im User-Agent-Header völlig aussagefrei ist. Für Statistiken mag es reichen, sofern man sich der Fehlerrate bewusst ist, für mehr aber nicht.

Cheatah

[opi]

Hallo,

Hi,

mich würde mal interessieren, wie Ihr so die Möglichkeit testet,
ob beim Besucher das Setzen von Cookies erlaubt ist

das testen wir selbstverständlich gar nicht, weil es sich erstens gar nicht testen lässt und zweitens uninteressant ist, zumal wir die volle Funktionalität eh auch ohne Cookies garantieren.

das heißt, das du keine Cookies verwendest. Ok.

und wie Ihr Eure Langzeit-Cookies terminiert.

So, wie es für den jeweiligen Anwendungsfall sinnvoll ist.

Das heißt, dass du doch Cookies verwendest? Ok, auch wenn es wider-
sprüchlich ist.

Wie würdest du denn zum Beispiel einen angemeldeten Benutzer
identifieren wollen? Vielleicht kannst du mir einen Tipp geben.

Vielen Dank.

Greez,
opi

[Cheatah]

Hi,

das heißt, das du keine Cookies verwendest. Ok.

nein, ich verwende durchaus Cookies. Niemals allerdings würde ich davon irgend etwas abhängig machen.

Das heißt, dass du doch Cookies verwendest? Ok, auch wenn es wider-
sprüchlich ist.

Wieso ist das widersprüchlich?

Wie würdest du denn zum Beispiel einen angemeldeten Benutzer
identifieren wollen?

An der Session-ID, für deren Mitversand bei folgenden Requests ich sorge.

Cheatah

[opi]

Hallo,

An der Session-ID, für deren Mitversand bei folgenden Requests ich sorge.

meinst du etwa sowas:

<input type="hidden" name="session_id" value="4711">

Oder woran machst du die Session-ID aus? Das wäre doch _fast_ das
Gleiche wie ein Cookie, nur dass du nicht auf die "Erlaubnis" des
Benutzers angewiesen bist!

Mit einem Cookie hätte der Benutzer noch die Möglichkeit klar zu
machen, dass er die Speicherung von Daten nicht wünscht,
mit der Session-ID setzt du dich doch darüber hinweg oder?

Greez,
opi

[Cheatah]

Hi,

meinst du etwa sowas:
   <input type="hidden" name="session_id" value="4711">

wenn es sich um ein Formular handelt: Ja, beispielsweise.

Das wäre doch _fast_ das Gleiche wie ein Cookie,

Nein, weit davon entfernt. Im Falle eines GET-Parameters handelt es sich um den Teil der URL, also _des_ Kennzeichners der Ressource. Die Gemeinsamkeit zu Cookies ist lediglich, dass beide im Request mit versendet werden.

Mit einem Cookie hätte der Benutzer noch die Möglichkeit klar zu
machen, dass er die Speicherung von Daten nicht wünscht,

Nö. Welche Speicherung? Auf seinem eigenen Rechner? Bei Dir sind die Daten eh zwangsläufig gespeichert, er hat sich schließlich bereits eingeloggt.

mit der Session-ID setzt du dich doch darüber hinweg oder?

Nein. Er hat einer impliziten Speicherung bestimmter Daten durch den Vorgang des Logins - _und_ durch die Ermöglichung desselben, nämlich die verherige Registrierung - bereits zugestimmt.

Cheatah

[opi]

Hallo cheatah,

meinst du etwa sowas:
   <input type="hidden" name="session_id" value="4711">

wenn es sich um ein Formular handelt: Ja, beispielsweise.

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

Ok, jetzt habe ich zunächst drei Varianten:

a) Cookie
b) Session-ID
c) HTTP-AUTH von Martin

zu a) fällt weg, weil dies nur Möglich ist, wenn Cookies akzeptiert
werden.

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

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?

Aber welche dieser Varianten ist die sicherste? 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.

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?

Zudem: was ist _so_schlimm_ an einem Cookie? Das habe ich noch nicht
so ganz verstanden.

Greez,
opi

[Cheatah]

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

[opi]

Hallo,

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.

mit anderen Worten müsste ich in allen Links ein skript.cgi?id=4711

anhängen? Und allen Funktionen müsste ich die ID als Argument
mitgeben, damit die ID innerhalb der Funktionen an die Links gehängt
werden kann? Das halte ich für zu umständlich.

zu a) fällt weg,

Kommt drauf an wofür.

Zum Beispiel die Möglichkeit eines automatischen Logins.

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.

Aber von Anfang an meinte ich einen Langzeit-Cookie, der in der Regel
für genau soetwas genutzt wird.

Aber welche dieser Varianten ist die sicherste?

Sicher in Bezug auf ...?

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

Das werde ich noch in meine Anforderung aufnehmen... hatte ich
sowieso vor.

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.

Warst du das nicht gerade selber, der meinte, dass ein Benutzer eine
Richtlinie aktzeptieren muss bezüglich Session-ID, damit er die
Seite nutzen kann? Mit einem Cookie wäre das wirklich nicht anders
oder? Was meinst du? :-)

Greez,
opi

[Cheatah]

Hi,

mit anderen Worten müsste ich in allen Links ein skript.cgi?id=4711
anhängen?

wenn "4711" eine generierte Session-ID ist: Ja. Niemals übertrage Login-Daten in der URL.

Und allen Funktionen müsste ich die ID als Argument
mitgeben, damit die ID innerhalb der Funktionen an die Links gehängt
werden kann? Das halte ich für zu umständlich.

Viele Frameworks machen entsprechendes schon automatisch, auch z.B. PHP.

zu a) fällt weg,
Kommt drauf an wofür.
Zum Beispiel die Möglichkeit eines automatischen Logins.

Stelle Dir die Frage: Welche Nachteile hat der User, wenn diese Funktion nicht zur Verfügung steht? Daraus resultiert, ob Cookies in Frage kommen.

Aber von Anfang an meinte ich einen Langzeit-Cookie, der in der Regel
für genau soetwas genutzt wird.

Am Anfang hast Du sehr allgemeine Fragen gestellt, die entsprechend allgemein beantwortet werden mussten. Zudem ist die Behauptung, ein "Langzeit-Cookie", was Du zudem nicht mal definiert hast, würde in der Regel für einen automatischen Login genutzt werden, schlichtweg falsch. Es handelt sich um einen einzigen von vielen möglichen Einsatzgebieten. Eigentlich ist das aber auch egal, weil Deine Frage nichts mit einer Anzahl Spezialfälle zu tun hatte. Du siehst: Was Du meinst, musst Du _sagen_, nicht denken.

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.
Warst du das nicht gerade selber, der meinte, dass ein Benutzer eine
Richtlinie aktzeptieren muss bezüglich Session-ID, damit er die
Seite nutzen kann?

Bitte? Er muss auch die "Richtlinie" akzeptieren, dass dieses Forum unter http://forum.de.selfhtml.org/ erreichbar ist, nicht unter ftp://hier-will-ich-hin/. URLs sind ein technisches Identifikationsmerkmal, welches an zentraler Stelle festgelegt wird, ähnlich des EAN-Codes. Da gibt es keine "Richtlinie" und auch nichts zu akzeptieren. Wenn jemandem eine URL nicht zusagt, muss er entweder darauf verzichten oder Magie erlernen. Andere Möglichkeiten existieren nicht.

Mit einem Cookie wäre das wirklich nicht anders oder?

Doch, wäre es. Cookies sind kein Identifikationsmerkmal. Zudem sind sie im Gegenatz zu URLs optional.

Cheatah

[Jörg Pescke]

Hallo Chetah,

das testen wir selbstverständlich gar nicht, weil es sich erstens gar nicht testen lässt

Nicht ganz richtig.

und zweitens uninteressant ist,

Schliess nicht von Dir auf andere :)

Warum das? Es ist völlig uninteressant, welcher Browser verwendet wird.

s.o.

[Cheatah]

Hi,

das testen wir selbstverständlich gar nicht, weil es sich erstens gar nicht testen lässt
Nicht ganz richtig.

doch, völlig richtig.

und zweitens uninteressant ist,
Schliess nicht von Dir auf andere :)

Ich gehe grundsätzlich erst einmal von einer sinnvollen Verwendung im allgemeinen Umfeld aus.

Warum das? Es ist völlig uninteressant, welcher Browser verwendet wird.
s.o.

Es _ist_ völlig uninteressant, welcher Browser verwendet wird.

Cheatah

[Jörg Peschke]

Hallo,

Nicht ganz richtig.

doch, völlig richtig.

Du kannst einen Cookie setzen und ihn danach wieder auslesen.
Wenn der Cookie dann existiert, weisst du dass der benutzer diesen einen Cookie erlaubt hat.
Wenn du kühn bist, kannst du dann daraufhin spekulieren, dass der Benutzer vielleicht auch weitere Cookies deiner Seite akzeptieren würde. (was zugegeben, äußerst spekulativ, aber für die Mehrzahl der User zutreffend ist).

Ich gehe grundsätzlich erst einmal von einer sinnvollen Verwendung im allgemeinen Umfeld aus.

Ich finde es schon interessant zu wissen, ob ich auf ein bestimmtes Feature zurückgreifen kann als Entwickler oder nicht.

Es _ist_ völlig uninteressant, welcher Browser verwendet wird.

Bei komplexen DHTML-Sachen z.b. ist es das nicht mehr, weil du für manche Browser mache Sachen deaktivieren/anders machen musst.

[Cheatah]

Hi,

Nicht ganz richtig.
doch, völlig richtig.
Du kannst einen Cookie setzen und ihn danach wieder auslesen.

und was sagt das darüber aus, ob der User (bzw. sein Client) Cookies akzeptiert? Richtig: nichts. Es sagt _maximal_ aus, ob _dieser_ Cookie akzeptiert wurde, aber nicht mal, ob er auch beim nächsten Request noch dabei sein wird.

Wenn du kühn bist,

Wenn Du kühn bist, gehst Du davon aus, dass der User Cookies akzeptiert oder akzeptieren wird, wenn es ohne sie nicht klappt. Dummerweise hat Kühnheit nichts mit der Realität zu tun.

(was zugegeben, äußerst spekulativ, aber für die Mehrzahl der User zutreffend ist).

Und was ist mit der Minderzahl?

Ich gehe grundsätzlich erst einmal von einer sinnvollen Verwendung im allgemeinen Umfeld aus.
Ich finde es schon interessant zu wissen, ob ich auf ein bestimmtes Feature zurückgreifen kann als Entwickler oder nicht.

Sicher: Kannst Du. Immer. Sofern Du Dich nicht davon abhängig machst. In dem Fall stehen Dir exakt zwei Dinge zur Verfügung: HTML und HTTP. Ganz einfach.

Es _ist_ völlig uninteressant, welcher Browser verwendet wird.
Bei komplexen DHTML-Sachen z.b. ist es das nicht mehr, weil du für manche Browser mache Sachen deaktivieren/anders machen musst.

Bei komplexen DHTML-Sachen oder irgendwas anderem ist es immer noch völlig egal, welcher Browser verwendet wird. Wichtig ist immer nur, was er _kann_. Und das lässt sich direkt prüfen. Unter keinen Umständen ist der Name des Browsers von Belang.

Cheatah

[opi]

Hallo,

und was sagt das darüber aus, ob der User (bzw. sein Client) Cookies akzeptiert? Richtig: nichts.

Nöh... Wenn keine ID zurück kommt, ist der Cookie auch nicht
akzeptiert worden.

Greez,
opi

[Cheatah]

Hi,

Nöh... Wenn keine ID zurück kommt, ist der Cookie auch nicht
akzeptiert worden.

zumindest noch nicht. Auch das sagt aber nichts über den nächsten Cookie aus.

Cheatah

[Jörg Peschke]

Hallo

Wichtig ist immer nur, was er _kann_. Und das lässt sich direkt prüfen. Unter keinen Umständen ist der Name des Browsers von Belang.

Ich denke, du spielst auf DOM-Features o.ä. an. Die kann man abprüfen, das ist richtig.

Es gibt aber z.B. Browser-Bugs. Oder, nennen wir sie nicht mal Bugs, sondern "Eigenheiten".
Wenn z.b. Firefox beim Austauschen eines Bildes (mittels document.getElementById....src=...) mist baut, und plötzlich zwei Bilder ineinander klebt (erst vor kurzem gehabt den fall). Dann kann ich das nicht abprüfen.
Deshalb muss ich wohl oder übel zur Kenntnis nehmen, dass der Firefox das wohl nicht mag, und muss Workarounds einbauen.

[Cheatah]

Hi,

Wichtig ist immer nur, was er _kann_. Und das lässt sich direkt prüfen. Unter keinen Umständen ist der Name des Browsers von Belang.
Ich denke, du spielst auf DOM-Features o.ä. an.

nein, allgemein auf Objekte und Methoden.

Es gibt aber z.B. Browser-Bugs. Oder, nennen wir sie nicht mal Bugs, sondern "Eigenheiten".

Diese sind jeweils als bekannt vorauszusetzen, nebst der entsprechenden anderen Fähigkeiten und Unfähigkeiten. Damit kann man arbeiten.

Wenn z.b. Firefox beim Austauschen eines Bildes (mittels document.getElementById....src=...) mist baut, und plötzlich zwei Bilder ineinander klebt (erst vor kurzem gehabt den fall).

Hast Du davon ein Beispiel parat?

Deshalb muss ich wohl oder übel zur Kenntnis nehmen, dass der Firefox das wohl nicht mag, und muss Workarounds einbauen.

Das ändert nichts daran, dass der Name für Dich uninteressant ist. Und der Name ist das einzige, was Du *im Glücksfall* bei einer Browserprüfung erhalten kannst.

Cheatah

[opi]

Hallo,

das testen wir selbstverständlich gar nicht, weil es sich erstens gar nicht testen lässt
Nicht ganz richtig.

doch, völlig richtig.

doch, dass kann man!

"CGI Programmierung mit Perl" 2. Auflage, Seite 314

Skript: cookie_testen.cgi

Greez,
opi

[Cheatah]

Hi,

das testen wir selbstverständlich gar nicht, weil es sich erstens gar nicht testen lässt
Nicht ganz richtig.
doch, völlig richtig.
doch, dass kann man!

nein, das kann man nicht.

"CGI Programmierung mit Perl" 2. Auflage, Seite 314
Skript: cookie_testen.cgi

Wenn es sich bei diesem Buch nicht zufällig um eines magischer Natur handelt, ist eine dort vermerkte gegenteilige Behauptung belanglos.

Cheatah

[opi]

Hallo,

doch, dass kann man!

nein, das kann man nicht.

"CGI Programmierung mit Perl" 2. Auflage, Seite 314
Skript: cookie_testen.cgi

Wenn es sich bei diesem Buch nicht zufällig um eines magischer Natur handelt, ist eine dort vermerkte gegenteilige Behauptung belanglos.

Bücher von Oreilly haben immer was magisches!
Findest du nicht auch ;-)

Wie schon in einem meiner ersten Threads angedeutet...
hier eine kleine Vervollständigung:

a) Benutzer schickt ein Formular mit Benutzername und Kennwort
b) Set-Cookie mit http-equiv="refresh" content="0:..." etc.
c) wenn der Cookie im nächten Request mit kommt, wurde er zunächst
akzeptiert, wenn nicht, dann erhält der Benutzer die freundliche
Aufforderung, Cookies im Browser oder zumindest für diese Seite
zu aktezpieren.

Greez,
opi

[Cheatah]

Hi,

Bücher von Oreilly haben immer was magisches!
Findest du nicht auch ;-)

na gut ;-)

b) Set-Cookie mit http-equiv="refresh" content="0:..." etc.

Welchen Vorteil siehst Du in dem Refresh?

c) wenn der Cookie im nächten Request mit kommt, wurde er zunächst
akzeptiert,

Du solltest mittlerweile wissen, dass diese Information belangfrei ist.

wenn nicht, dann erhält der Benutzer die freundliche
Aufforderung, Cookies im Browser oder zumindest für diese Seite
zu aktezpieren.

Das ist hoffentlich nicht Dein Ernst, oder? Glaubst Du wirklich, auch nur ein einziger Mensch auf dem gesamten Planeten wird ausgerechnet für _Deine_ Site seine Systemkonfiguration verändern? Himmel, ich habe Dienste für das größte deutsche Internetportal geschrieben, mit Millionen von Seitenabrufen pro Tag, und selbst dort habe ich mir nicht diese Arroganz angemaßt. Wenn Du wirklich glaubst, Obiges sei eine Option, dann kann ich Dir leider nicht helfen.

Cheatah

[opi]

Hallo cheatah,

in Bezug auf diesen Thread hier https://forum.selfhtml.org/?t=115742&m=739773
war ich einfach mal so neugierig und habe das getestet... mit GMX!

Klappt wunderbar! Ich habe mir den Quelltext angesehen und man kann
deutlich erkennen, dass an jeden Link ein

CUSTOMERNO=4711

angehängt ist.

wenn nicht, dann erhält der Benutzer die freundliche
Aufforderung, Cookies im Browser oder zumindest für diese Seite
zu aktezpieren

Das ist hoffentlich nicht Dein Ernst, oder? Glaubst Du wirklich, auch nur ein einziger Mensch auf dem gesamten Planeten wird ausgerechnet für _Deine_ Site seine Systemkonfiguration verändern? Himmel, ich habe Dienste für das größte deutsche Internetportal geschrieben, mit Millionen von Seitenabrufen pro Tag, und selbst dort habe ich mir nicht diese Arroganz angemaßt. Wenn Du wirklich glaubst, Obiges sei eine Option, dann kann ich Dir leider nicht helfen.

Okay, eBay scheint für dich sehr, sehr klein zu sein.

------> Copy-Paste vom eBay Login

Der von Ihnen verwendete Browser akzeptiert keine Cookies.

Gehen Sie bitte entsprechend der nachfolgenden Tipps vor, um Ihre Browser-Einstellungen zu ändern.

1. Versuchen Sie erneut, sich anzumelden. Wenn Sie von Ihrem Browser aufgefordert weden, Cookies zu akzeptieren, klicken Sie bitte auf „Akzeptieren” oder „Weiter."
2. Unter Umständen ist Ihr Browser so konfiguriert, dass Cookies nicht akzeptiert werden. Informieren Sie sich, wie Sie die Cookie-Einstellungen Ihres Browsers ändern.
3. Vergewissern Sie sich, dass die Datums- und Zeiteinstellungen Ihres Computers aktuell sind.
4. Möglicherweise ist Ihr Browser veraltet. Aktualisieren Sie Ihren Browser. Laden Sie sich die aktuellste Version von Microsoft Internet Explorer oder Netscape Navigator herunter.

Greez,
opi

[Der Martin]

Hallöchen,

mich würde mal interessieren, wie Ihr so die Möglichkeit testet,
ob beim Besucher das Setzen von Cookies erlaubt ist ...

Gar nicht. Ich versuche sie zu vermeiden.

Das Gleiche würde ich dann gerne für Browsertypen einsetzen, nur
senden tatsächlich alle Browser den "User-Agent" im Request-Header?

User-Agent: Mozilla/4.0 (compatible; Generic Browser; Win32)
Und, was für einen Browser verwende ich nun?

Je nach Lust und Laune könnte es ein IE5.5, ein Firefox, ein Opera oder auch ein IE6 sein. Die melden sich bei mir alle gleich. Soviel zur Aussagekraft des User Agent.

Schönes Wochenende,

Martin

[opi]

Hallo,

Hallöchen,

mich würde mal interessieren, wie Ihr so die Möglichkeit testet,
ob beim Besucher das Setzen von Cookies erlaubt ist ...

Gar nicht. Ich versuche sie zu vermeiden.

Wie identifizierst du denn einen Benutzer, der sich mit Name und
Kennwort angemeldet hat um sicher zu stellen, dass er nur das macht,
was er machen darf?

Greez,
opi

[Der Martin]

Hi opi,

[Cookies]
Gar nicht. Ich versuche sie zu vermeiden.

Wie identifizierst du denn einen Benutzer, der sich mit Name und
Kennwort angemeldet hat um sicher zu stellen, dass er nur das macht,
was er machen darf?

Das hatte ich bisher noch nicht nötig. Für alles, was ich bisher realisiert habe, war die Zugriffsbeschränkung über HTTP-AUTH vollkommen ausreichend.

So long,

Martin

[Jörg Peschke]

User-Agent: Mozilla/4.0 (compatible; Generic Browser; Win32)
Und, was für einen Browser verwende ich nun?

Je nach Lust und Laune könnte es ein IE5.5, ein Firefox, ein Opera oder auch ein IE6 sein.

Windows-IEs haben id.Regel noch ein MSIE mit in der Kennung stehen, wenn ich mich nicht irre, oder? Also kann das schonmal kein IE sein.
Firefox/Mozilla liefert i.d.Regel ein "Gecko" mit.
->ich tippe auf Opera :)

Jörg

[Cheatah]

Hi,

Windows-IEs haben id.Regel noch ein MSIE mit in der Kennung stehen, wenn ich mich nicht irre, oder? Also kann das schonmal kein IE sein.

wieso nicht?

Firefox/Mozilla liefert i.d.Regel ein "Gecko" mit.

In der Regel haben Wikinger rote Bärte. Das sagt aber über den spezifischen Einzelfall, den man gerade betrachtet, exakt gar nichts aus.

->ich tippe auf Opera :)

Ich auf einer Tastatur ;-)

Cheatah

[Jörg Peschke]

Hallo,

wieso nicht?

Erstens ist mir keine Möglichkeit bekannt, dem IE einen anderen als den Default UserAgent-String unterzujubeln (wie es z.B. im Opera geht).

Zweitens, auch wenn das ginge: Eine Anwendung sollte nicht auseinanderfallen, wenn sie sich nur darauf verlässt, das ist richtig.
Aber meine Meinung ist folgende: Wenn ein User bewusst an den Einstellungen seines UserAgents herummanipuliert, darf er sich nicht wundern, wenn er als IE(repsektive Firefox/Mozilla/Safari/Konquerror-)-User nicht das bekommt, was er erwartet hat (z.b. ein IE-Layout).

Gruesse,
Joerg

[Cheatah]

Hi,

Erstens ist mir keine Möglichkeit bekannt, dem IE einen anderen als den Default UserAgent-String unterzujubeln (wie es z.B. im Opera geht).

Begriffe wie "Firewall" und "Proxy" sind Dir nicht wirklich unbekannt, oder?

Aber meine Meinung ist folgende: Wenn ein User bewusst an den Einstellungen seines UserAgents herummanipuliert,

Wie kommst Du darauf, er habe darauf Einfluss?

darf er sich nicht wundern, wenn er als IE(repsektive Firefox/Mozilla/Safari/Konquerror-)-User nicht das bekommt, was er erwartet hat (z.b. ein IE-Layout).

Das sehe ich anders. Vermutlich liegt das daran, dass ich nicht gerne eigenes Versagen auf andere schiebe. Auch wenn der User verantwortlich ist für die Änderung: Ich als Anbieter habe seine Wünsche zu respektieren. Alles andere wäre auch mit dem Gedanken der Usability nicht vereinbar.

Cheatah

[Jörg Peschke]

Hallo,

Begriffe wie "Firewall" und "Proxy" sind Dir nicht wirklich unbekannt, oder?

Ok, dann mache ich eine Regel, die Pakete auf jpgs und gifs-Daten sniffed und selbige blocked, ignoriere alt und title-Attribute in HTML-kodierten Inhalten und wundere mich dann danach dann, wenn ich auf einer Seite nicht mehr so wahnsinnig viel erkenne :)
Es verbietet mir niemand, so etwas zu tun, aber ich muss mir doch beim Einrichten einer solchen Firewall bewusst sein, was für Auswirkungen das für mich und meine user hat.

Aber meine Meinung ist folgende: Wenn ein User bewusst an den Einstellungen seines UserAgents herummanipuliert,

Wie kommst Du darauf, er habe darauf Einfluss?

Ok guter Punkt.

Das sehe ich anders. Vermutlich liegt das daran, dass ich nicht gerne eigenes Versagen auf andere schiebe. Auch wenn der User verantwortlich ist für die Änderung: Ich als Anbieter habe seine Wünsche zu respektieren. Alles andere wäre auch mit dem Gedanken der Usability nicht vereinbar.

Da gehen wir konform.
Aber: Wenn ich z.B. im Touristik-Büro jemanden auf Englisch anrede, brauch ich mich nicht beschweren, wenn ich dann die angebotenen Prospekte erstmal auf Englisch kriege - nur wenn ich ÜBERHAUPT nichts kriege ("Diese Reise wurde optimiert für die griechische Sprache") würde ich sauer werden.

[Cheatah]

Hi,

Ok, dann mache ich eine Regel, die Pakete auf jpgs und gifs-Daten sniffed und selbige blocked, ignoriere alt und title-Attribute in HTML-kodierten Inhalten und wundere mich dann danach dann, wenn ich auf einer Seite nicht mehr so wahnsinnig viel erkenne :)

tu das, wenn Du zufällig in der glücklichen Lage bist, die Firewall beeinflussen zu können. Ob Dir das nützlich erscheint, musst Du natürlich selbst entscheiden.

Es verbietet mir niemand, so etwas zu tun, aber ich muss mir doch beim Einrichten einer solchen Firewall bewusst sein, was für Auswirkungen das für mich und meine user hat.

Richtig.

Aber: Wenn ich z.B. im Touristik-Büro jemanden auf Englisch anrede, brauch ich mich nicht beschweren, wenn ich dann die angebotenen Prospekte erstmal auf Englisch kriege

Richtig.

nur wenn ich ÜBERHAUPT nichts kriege ("Diese Reise wurde optimiert für die griechische Sprache") würde ich sauer werden.

Ich würde ebenfalls sauer werden, wenn das Englisch in den Prospekten so fehlerhaft ist, dass ich es nicht verstehen kann.

Cheatah

[Der Martin]

Hallo Jörg,

User-Agent: Mozilla/4.0 (compatible; Generic Browser; Win32)
Und, was für einen Browser verwende ich nun?

Je nach Lust und Laune könnte es ein IE5.5, ein Firefox, ein Opera oder auch ein IE6 sein.

Windows-IEs haben id.Regel noch ein MSIE mit in der Kennung stehen, wenn ich mich nicht irre, oder?

Okay, dann irrst du dich. Das ist nur in der Defaulteinstellung so, lässt sich aber abstellen. Im IE ab Version 5.0 (ich bin nicht sicher, ob es beim 4er nicht auch schon ging) kannst du den User Agent völlig frei eingeben.

Also kann das schonmal kein IE sein.
->ich tippe auf Opera :)

Wette verloren. ;-)
Es ist ein IE6.0SP1.

Ciao,

Martin

[Jörg Peschke]

Hallo,

Okay, dann irrst du dich. Das ist nur in der Defaulteinstellung so, lässt sich aber abstellen. Im IE ab Version 5.0 (ich bin nicht sicher, ob es beim 4er nicht auch schon ging) kannst du den User Agent völlig frei eingeben.

Cool. Das wusst ich in der Tat nicht. *Gleich mal-probier*

Jörg