Serverseitig Browser erkennen

[Sandra]

hallo!

kann ich serverseitig mit perl/cgi eine browserabfrage starten und wenn ja, wie sehen die verschiedenen bezeichnungne für die browser aus (netscape 6, netscape älter als 6, ie älter als 5.5, ie ab 6, opera, usw.) hat jemand eine liste oder eine abfrage bereits fertig?

danke!

sandra

[Kai Lahmann]

hi

kann ich serverseitig mit perl/cgi eine browserabfrage starten und wenn ja, wie sehen die verschiedenen bezeichnungne für die browser aus (netscape 6, netscape älter als 6, ie älter als 5.5, ie ab 6, opera, usw.) hat jemand eine liste oder eine abfrage bereits fertig?

ja, es geht :)

die berüchtigten ID-Strings sind auch für den Server sichbar. Haken: die Wahrscheinlichkeit, das das drin ist, was dranstelt ist nicht die Größte..
Opera tarnt sich schon seit einiger Zeit so, dass man ihn auf den ersten Blick für einen IE hält.

[Sandra]

hi

kann ich serverseitig mit perl/cgi eine browserabfrage starten und wenn ja, wie sehen die verschiedenen bezeichnungne für die browser aus (netscape 6, netscape älter als 6, ie älter als 5.5, ie ab 6, opera, usw.) hat jemand eine liste oder eine abfrage bereits fertig?

ja, es geht :)

die berüchtigten ID-Strings sind auch für den Server sichbar. Haken: die Wahrscheinlichkeit, das das drin ist, was dranstelt ist nicht die Größte..
Opera tarnt sich schon seit einiger Zeit so, dass man ihn auf den ersten Blick für einen IE hält.

ja, aber die wahrscheinlichkeit, dass meine user java aktiviert haben, ist eben auch nur 70%...

was muss ich denn machen und wo gibt es eine übersicht über die verschiedenen browsernamen?

danke!

sandra

[Michael Schröpl]

Hi,

was muss ich denn machen

was willst Du denn überhaupt erreichen? Was würde Dir diese Information nützen?

Viele Grüße
      Michael
(der selbst eine serverseitige Browsererkennung einsetzt, aber nur für ein "nice to have", nicht für etwas Wichtiges)

[Sandra]

ich versuche alles, was möglich ist serverseitig zu regeln, da es dann gültig für alle läuft und nicht nur für einige. ich habe ein neues projekt mit hoher fakerquote und vielen non-java-usern und ich kann die faker nur erfolgreich filtern, wenn alles bei hundert prozent der user klappt, also serverseitig...

:-)))

sandra

[Michael Schröpl]

Hi Sandra,

ich versuche alles, was möglich ist serverseitig zu
regeln, da es dann gültig für alle läuft und nicht
nur für einige.

sehr lobenswert. :-)

ich habe ein neues projekt mit hoher fakerquote und
vielen non-java-usern und ich kann die faker nur
erfolgreich filtern, wenn alles bei hundert prozent
der user klappt, also serverseitig...

Das sagt mir aber nicht, was genau Du mit dem UserAgent-String anfangen können willst. Denn der ist so was von leicht zu fälschen, daß Dich diese 'Information' nicht wirklich glücklich machen wird.

Nur so eine Idee: Mach doch mal ein paar Tests, was die einzelnen UserAgents an "Accept:"-Headern senden.
Das ist zwar auch ziemlich schauerlich, aber es ist sehr viel weniger Leuten bekannt, daß auch diese Information ggf. eine Art "fingerprint" des UserAgents darstellt. Insofern ist die Chance, daß jemand _das_ fälscht, sehr gering - vor allem, weil er dabei die Semantik seines Browsers ändern würde.
Andererseits könnte diese Liste von der Browser-Installation abhängen (plugins?) - es wird also ggf. schwierig sein, ein hinreichend tolerantes Parsing-Verfahren zu schreiben.

Ein geeignetes Spielzeug zur Datenerfassung:
http://www.schroepl.net/cgi-bin/http_trace.pl

Alternative: den "Accept"-Header in das Log-Format Deines Apache aufnehmen, zusammen mit dem UserAgent - und dann ein Skript schreiben, das eine Korrelation dieser Felder zu finden versucht.

Viele Grüße
      Michael

[Sandra]

hallo michael!

nun, da ich noch recht neu im netz und in der programmierung bin, sagt mir das von dir geschriebene zur zeit nicht viel...

also zu meinem system. bei meinem system nutzt ein webmaster einen von mir bereitgestellten html-code zum einbinden eines iframe auf seiner seite. um nun manipulationen beim einbau zu verhindern (width=1 height=1 zum beispiel) möchte ich für diesen fall beispielsweise einen window.resizeTo einsetzen. der klappt für ie auch einwandfrei, der iframe wird vergrößert, netscape verkleinert stattdessen das äußere fenster... :-(

es geht also nicht um webmaster, die ihre browserinfos faken können, sondern darum, dass der webmaster ganz normale user ohne interesse am faken auf seiner seite hat und diese muss ich nach browsern unterscheiden...

konnte man das nachvollziehen? klingt so durcheinander,

sandra

[Michael Schröpl]

Hi Sandra,

also zu meinem system. bei meinem system nutzt ein
webmaster einen von mir bereitgestellten html-code
zum einbinden eines iframe auf seiner seite.

gemäß welcher vertraglichen Absprache zwischen Euch?

um nun manipulationen beim einbau zu verhindern
(width=1 height=1 zum beispiel)

Was ist daran "manipuliert"?

möchte ich für diesen fall beispielsweise einen
window.resizeTo einsetzen.

Aha - also doch JavaScript! Damit das irgendwas bewirkt, muß der Browser JavaScript aktiv haben.

Wenn er das aber tut, kannst Du über die Eigenschaften des Browsers (document.all, document.layers) viel zuverlässiger den verwendeten Browser herausfinden als über den UserAgent-String.

es geht also nicht um webmaster, die ihre
browserinfos faken können, sondern darum, dass
der webmaster ganz normale user ohne interesse
am faken auf seiner seite hat

Es sind diese ganz normalen User, die sehr wohl Interesse am Faken ihres UserAgent haben.

Vielleicht wissen sie noch nicht mal, daß sie das tun - weil sie beispielsweise irgend einen Proxy-Server oder WebWasher oder eine Personal Firewall oder was auch immer einsetzen, der/die auf ihrem Rechner installiert ist und HTTP-Header on the fly umschreibt ...

konnte man das nachvollziehen?

Durchaus.

Aber wenn Du auf JavaScript ohnehin angewiesen bist, dann nützt Dir eine serverseitige Browser-Erkennung einfach nichts.

Viele Grüße
      Michael

[sandra]

hi michael

gemäß welcher vertraglichen Absprache zwischen Euch?

gemäß meiner nutzungsbestimmungen für mein system.

um nun manipulationen beim einbau zu verhindern
(width=1 height=1 zum beispiel)

Was ist daran "manipuliert"?

eigentliche größe ist 450x300, darin wird werbung dargestellt, width=1 height=1 bedeutet gutschrift für den webmaster, obwohl er nichts zeigt, bzw nur einen pixel groß

möchte ich für diesen fall beispielsweise einen
window.resizeTo einsetzen.

Aha - also doch JavaScript! Damit das irgendwas bewirkt, muß der Browser JavaScript aktiv haben.

aber nur für die größenabfrage, andere betrugsversuche will ich mit perl abfangen

Wenn er das aber tut, kannst Du über die Eigenschaften des Browsers (document.all, document.layers) viel zuverlässiger den verwendeten Browser herausfinden als über den UserAgent-String.

ich kenne auch für eine javascript-browser-abfrage keine seite, wo ich die verschiedenen bezeichnungen aller wichtigen browser einsehen kann

es geht also nicht um webmaster, die ihre
browserinfos faken können, sondern darum, dass
der webmaster ganz normale user ohne interesse
am faken auf seiner seite hat

Es sind diese ganz normalen User, die sehr wohl Interesse am Faken ihres UserAgent haben.

Vielleicht wissen sie noch nicht mal, daß sie das tun - weil sie beispielsweise irgend einen Proxy-Server oder WebWasher oder eine Personal Firewall oder was auch immer einsetzen, der/die auf ihrem Rechner installiert ist und HTTP-Header on the fly umschreibt ...

also gibt es gar keine vernünftige lösung? javascript hat nicht jeder an und serverseitig gibt es zu viele probleme mit den einstellungen der einzelnen user?!? :-(

konnte man das nachvollziehen?

Durchaus.

Aber wenn Du auf JavaScript ohnehin angewiesen bist, dann nützt Dir eine serverseitige Browser-Erkennung einfach nichts.

siehe oben

Viele Grüße
      Michael

danke dir vielmals, sandra

p.s.: bleibt mir wohl nur, alle seiten auf denen mein code auftaucht per get_url einzulesen und mit suchmustern zu arbeiten...

[Michael Schröpl]

Hi Sandra,

Wenn er das aber tut, kannst Du über die
Eigenschaften des Browsers (document.all,
document.layers) viel zuverlässiger den
verwendeten Browser herausfinden als über den
UserAgent-String.
ich kenne auch für eine javascript-browser-abfrage
keine seite, wo ich die verschiedenen bezeichnungen
aller wichtigen browser einsehen kann

Du brauchst die Bezeichnungen doch gar nicht.

Was Du brauchst, sind die _Fähigkeiten_ der Browser.
Diese kannst Du in JavaScript ausprobieren.
Jede sinnvolle Browserweiche arbeitet so, behaupte ich mal.

Es sind diese ganz normalen User, die sehr wohl
Interesse am Faken ihres UserAgent haben.
Vielleicht wissen sie noch nicht mal, daß sie
das tun ...
also gibt es gar keine vernünftige lösung?

Keine, die auf dem UserAgent-String beruht.

javascript hat nicht jeder an und serverseitig gibt
es zu viele probleme mit den einstellungen der
einzelnen user?!? :-(

Wie ich schon geschrieben habe: Der UserAgent schickt noch viele andere HTTP-Header, die sich schwerer fälschen lassen und die kaum jemand fälschen wollen wird.

Wenn Du beispielsweise die "Accept:"-Liste eine Menge bekannter Browser gegeneinander abgreichst, wirst Du mit hoher Wahrscheinlichkeit etwas finden, das Dir eine einigermaßen zuverlässige Erkennung ermöglicht.

Dasselbe gilt für "Accept-Encoding:" - da können die bekannten Browser auch alle unterschiedlich viel.

Wenn Du drei oder vier dieser Felder kombinierst, dann ist das mindestens so sicher wie der UserAgent.

Viele Grüße
      Michael

[sandra]

ja michael,

und wo fange ich als völlig ahnungslose frau nun an?

gruß

sandra

ich habe echt keine ahnung, was du da beschreibst... :-(

[Michael Schröpl]

Hi Sandra,

und wo fange ich als völlig ahnungslose frau nun an?

Hoppla - vorher klangst Du aber nicht so mutlos!

ich habe echt keine ahnung, was du da beschreibst...

Also:

1. Zum Thema "Browserweiche in JavaScript" wirst Du im Forum-Archiv reichlich fündig, da gehe ich jetzt mal nicht ins Detail. Mit "document.layers" und "document.all" hast Du auch passende Suchbegriffe.

2. Wenn Du serverseitig eine Browser-Erkennung über den UserAgent-String machen willst, woher nimmst Du den?
Aus einer Environment-Variable, weil das CGI-Interface (zumindest das des Apache) alle HTTP-Header dort als Variablen ablegt.
Wenn Du aber den UserAgent dort prüfen kannst, dann geht das mit jedem anderen Header-Feld genauso!

Verstehen, was die diversen Inhalte bedeuten, das mußt Du in jedem Fall.
Dazu kannst Du Dir einerseits ansehen, was in den Headern steht (Methoden habe ich Dir genannt - vor allem über Dein Apache-Log kommst Du schnell an große Datenmengen), oder andererseits in den Konfigurationen der einzelnen Browser nachsehen.

Bei Mozilla gibt es beispielsweise eine Konfigurationsdatei (defaults/pref/all.js), in der Du einen nennenswerten Teil der HTTP-Header nachsehen (und auch ändern!) kannst. (Das ist halt der Trend bei den modernen Browsern - sie geben den Benutzern immer mehr Möglichkeiten, zu bestimmen, was genau sie dem Serve sagen wollen und was nicht.)
Bei M$IE 5 stehen zumindest die Werte der "Accept:"-Liste in der Registry. Schau Dir mal "HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Internet Settings/Accepted Documents" an, da stehen die einzelnen Werte der Liste drin. Und bestimmte installierte Programme hängen sich da hinten dran - insbesondere natürlich die Micro$oft-Produkte. Wenn Du einen Browser antriffst, der Deinem Server explizit erzählt, daß er Micro$ofts PowerPoint-Format verstehen würde - na, was wird das für ein Browser sein?
Teilweise kannst Du sogar aus der Reihenfolge der Werte Deine Schlüsse ziehen ... wahrscheinlich sogar aus der Reihenfolge der gesendeten HTTP-Header! Denn die ist laut HTTP ziemlich beliebig, und es wäre doch ein irrer Zufall, wenn zwei Browser da unbedingt dieselbe Reihenfolge verwenden würden. Die Frage ist nur, ob Du an diese Reihenfolge noch heran kommen kannst - über die normale CGI-Schnittstelle bin ich mir nicht sicher. (Ich weiß nicht, in welcher Reihenfolge der Apache die einzelnen Environment-Variablen setzt und ob Du in PHP oder Perl auf diese Reihenfolge noch irgendwie zugreifen kannst.)

Ich habe nicht behauptet, daß das nicht in ziemlich viel Arbeit ausarten könnte. Aber - es würde Dir die Information liefern, die Du haben willst! Und zwar erheblich zuverlässiger, als dies der UserAgent-String tut.
Schau Dir nur weiter oben im Forum die Diskussion über den Opera-Marktanteil an ... hier wäre vielleicht ein Ansatz, sehr viel zuverlässigere Zahlen zu bekommen.

Was _ich_ nun ganz toll fände, das wäre, wenn Du diesen Wert konsequent gehst und am Ende Deine Erkenntnisse in Form eines kleinen Feature-Artikels zusammenfaßt. Ich kann mich an keinen Forum-Beitrag zu diesem Thema erinnern - hier würdest Du meines Wissens im Bereich von HTTP völliges Neuland betreten. (Das soll Dich jetzt motivieren, ey - nicht erschrecken! ;-)
Und eine zuverlässige (!) serverseitige Browser-Weiche, dafür würden sich vermutlich eine Menge Leser interessieren ... und Dir über weitere Threads sicherlich auch gerne Testdaten zahlreicher Exoten-Browser liefern, welche bei Dir nicht installiert sind. Wir können das Thema gerne auch per Mail weiter vertiefen ... aber den Artikel möchte ich Dir nicht wegnehmen. Ich habe schon welche ... ;-)

Die Methode, die ich einer solchen Browser-Erkennung zugrunde legen würde, habe ich natürlich nicht selbst erfunden, sondern nur adaptiert.
Denn ungefähr so versuchen Hacker, fingerprints von Rechnern zu bekommen, indem sie auf irgendwelchen niedrigeren Netzwerkebenen Pakete an eine Maschine senden und sich dann die Art (z. B. auch das Zeitverhalten!) der Reaktion ansehen. Selbst ein Server, der ein Paket einfach nur ablehnt, tut das nicht exakt so wie ein beliebiger anderer Server!
Genau das selbe Prinzip könntest Du bei HTTP anwenden: Du wendest zur Browser-Erkennung nicht den UserAgent-String aus, sondern möglichst viele Header.

Als Beispiel aus dem normalen Leben: Wenn Du mit jemandem sprichst und dieser Dir seinen Namen sagt, dann hast Du aus diesem Namen nur sehr geringe Informationen darüber, wo Dein Gesprächspartner z. B. wohnt. Aber Du hast in diesem Falle die Möglichkeit, auch seinen Tonfall, seinen "Dialekt" auszuwerten.
Genau das schlage ich Dir - übertragen ins HTTP-Universum - vor. Je genauer Du "zuhörst", desto besser wirst Du die Browser "verstehen".

Viele Grüße
      Michael
(den ein solcher Artikel übrigens auch sehr interessieren würde)

[sandra]

hallo michael,

vielen dank für den ewig langen beitrag. ich werde mir das alles mal zu gemüte führen und drüber nachdenken.

allerdings bin ich froh, dass ich perl etwas verstehe und ein javascript meinen bedürfnissen anpassen kann.

alles andere, wie informationen zwischen servern und browsern übertragen werden, habe ich noch nie verstanden und das wird wahrscheinlich auch ewig dauern...

ich brauche einfach was simples für meine bedürfnisse... einige gute lösungsansätze habe ich ja nun und werde mir was überlegen.

bis dann!

sandra