.Net 4.0-website nicht identifizieren kann, einige AppleWebKit basierte Browser

Sehen wir einige Safari-Browser fehlschlagen cross-Authentifizierung unserer website, nachdem wir ein upgrade an .NET 4.0 aus .NET 3.5.

Nach viel Untersuchung, es stellt sich heraus, dass ein problem mit ASP.NET die Ermittlung der Safari-Browser einwandfrei. ASP.NET zeigt Safari (evtl. auch andere WebKit-basierte Browser) als Mozilla die Version 0.0. Browser, die nicht unterstützen, cookies, frames, JavaScript, etc. .NET 3.5 hat keine Schwierigkeiten, diese Browser.

Wir haben die vereinfachte Prüfung nach einem einfachen HTTP-handler (ausgeführt auf einem Vanille-4.0-website), dass gibt nur die browser-Funktionen des anforderers.

Hier sind ein paar User-Agents, die nicht identifiziert werden können (Sie identifiziert sich als Mozilla 0.0):

Mozilla/5.0+(Macintosh;+U;+Intel+Mac+OS+X+10_5_8;+en-us)+AppleWebKit/533.19.4+(KHTML,+like+Gecko)+Version/5.0.3+Safari/533.19.4
Mozilla/5.0+(Macintosh;+U;+Intel+Mac+OS+X+10_6_2;+en-us)+AppleWebKit/531.9+(KHTML,+like+Gecko)
Mozilla/5.0+(Macintosh;+U;+Intel+Mac+OS+X+10_6_7;+en-us)+AppleWebKit/533.20.25+(KHTML,+like+Gecko)+Version/5.0.4+Safari/533.20.27
Mozilla/5.0+(Macintosh;+U;+Intel+Mac+OS+X+10_6_6;+en-us)+AppleWebKit/533.18.1+(KHTML,+like+Gecko)

Den hf-code sieht wie folgt aus:

<%@ WebHandler Language="C#" Class="PowershellTemporaryHandler" %>

using System;
using System.Web;
using System.Web.Security;

public class PowershellTemporaryHandler : IHttpHandler
{
    public bool IsReusable
    {
        get { return true; }
    }

    public void ProcessRequest(HttpContext context)
    {        
        HttpBrowserCapabilities hbc = context.Request.Browser;
        context.Response.Write("Type=" + hbc.Type + "<br>");
        context.Response.Write("Name=" + hbc.Browser + "<br>");
        context.Response.Write("Version=" + hbc.Version + "<br>");
        context.Response.Write("Major Version=" + hbc.MajorVersion + "<br>");
        context.Response.Write("Minor Version=" + hbc.MinorVersion + "<br>");
        context.Response.Write("Platform=" + hbc.Platform + "<br>");
        context.Response.Write("Is Beta=" + hbc.Beta + "<br>");
        context.Response.Write("Is Crawler=" + hbc.Crawler + "<br>");
        context.Response.Write("Is AOL=" + hbc.AOL + "<br>");
        context.Response.Write("Is Win16=" + hbc.Win16 + "<br>");
        context.Response.Write("Is Win32=" + hbc.Win32 + "<br>");
        context.Response.Write("Supports Tables=" + hbc.Tables + "<br>");
        context.Response.Write("Supports cookies=" + hbc.Cookies + "<br>");
        context.Response.Write("Supports VBScript=" + hbc.VBScript + "<br>");
        context.Response.Write("Supports Frames=" + hbc.Frames + "<br>");
        context.Response.Write("Supports JavaScript=" + hbc.EcmaScriptVersion.ToString() + "<br>");
        context.Response.Write("Supports Java Applets=" + hbc.JavaApplets + "<br>");
        context.Response.Write("Supports ActiveX Controls=" + hbc.ActiveXControls + "<br>");
        context.Response.Write("User Agent=" + context.Request.UserAgent + "<br>");
    }
}

Sind wir verwirrt, da der Mangel an Erwähnung im Internet über dieses problem. Es scheint, dass wir brauchen, um hinzuzufügen, Browser Definitionen entweder zu Rahmen/config/Browser-Ordner oder sonst den Ordner App_Browsers auf der website-Ebene, aber es scheint Bizarr, dass wir Sie brauchen würden, zu optimieren Browser-Definitionen für eine .NET 4.0 website ordnungsgemäß ausgeführt werden kann.

Hat jemand irgendwelche Erfahrungen mit diesem Problem?

Ich bin auch mit diesem problem .net 3.5 und 4.0. Beispiel für user agent, nicht anerkannt - "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_7; de-de) AppleWebKit/533.20.25 (KHTML, like Gecko) Version/5.0.4 Safari/533.20.27". Erste Mozilla 0.0.
Haben Sie versucht, die Lösung von user1777803 unten?
sorry das war so lange her, kann ich nicht zuverlässig beantworten.

InformationsquelleAutor Chad | 2011-03-29

24

Ich wurden in, was scheint, ein ähnliches Problem. Es scheint, dass ideed einige Safari-user-agents sind nicht richtig erkannt und stattdessen berichtet, wie Mozilla 0.0, ABER einige Untersuchungen zeigten mir, dass dieser Fehler nicht exakt reproduzierbar. Wenn ich mit meinem Firefox den UserAgent-Switcher zu senden, die genau die gleiche Benutzer-agent, der zuvor nicht erkannt zu werden und werfen Sie einen Blick auf die browser-Fähigkeiten, ist es korrekt berichtet als Safari. Gehen durch den server-log-Dateien (nach dem hinzufügen einige debug-Informationen) auch zu bestätigen scheint dieses Verhalten. Die sehr gleichen client mit dem gleichen (Safari) user-agent wird manchmal korrekt erkannt und gelegentlich berichtet als Mozilla 0.0 - die meisten der Zeit es ist falsch erkannten ein paar mal hintereinander, bevor es richtig wieder... Es scheint nur zu beeinflussen, Safari user-agents, wenn jemand interessiert ist, ich habe eine ziemlich lange Liste, der neueste sein:
- |Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_2_1 like Mac OS X; de-de) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8C148 Safari/6533.18.5|
Hat jemand mehr Informationen zu diesem Thema?

BEARBEITEN 2011-08-24

Scheint es, dass ich gefunden habe, die Ursache des Problems. Die UserAgent - - > BrowserCaps-resolving-Mechanismus verwendet einen cache, um vorübergehend zu speichern Zuordnungen. Leider nutzt es (standardmäßig) die ersten 64 Zeichen des UserAgent-string als cache-key und der ist einfach nur BS... Gelegentlich einen user-agent auftaucht, der aussieht wie eine Safari, aber wirklich nicht und dass man sich nicht richtig aufgelöst (Mozilla 0.0), aber die Zuordnung ist immer noch im cache gespeichert, was bedeutet, dass alle UserAgent-strings mit dem gleichen 64-Zeichen-Präfix sind jetzt falsch zugeordnet als gut, bis der cache-Eintrag verfällt (sliding window mit 1 minute). Die Schlüssellänge für die Zwischenspeicherung verwendet zum Glück kann konfiguriert werden, mit
```
<browserCaps userAgentCacheKeyLength="..." />
```
in der config-Sektion. Ich habe steigerte die Schlüssellänge auf 256 und da, dass das problem verschwunden ist. Jetzt werde ich versuchen, herauszufinden, welche UserAgent-string und war zuständig für den cache-poisoning in den Tannen - und ich ' ll aktualisieren diesen post, wenn ich nichts finde.
- läuft in dieser in meiner log-Dateien sowie. Ich werde ihm eine Chance geben. Schöne Fehlersuche.
- Es gibt Zeiten, ich wünschte, ich könnte +1 etwas mehr als einmal. Dies ist eine jener Zeiten.
- Shain: ich kenne das Gefühl. Ich buchstäblich tagelang verfolgen diese nach unten =)
- +1 auch von mir! Gut erklärt und gut gemacht, herauszufinden, die Lösung. Und ja, ich wünschte, ich kann, +2 auf Sie zu.
- Hinzufügen browserCaps mit user-agent-Länge von 256 gelöst, dass problem bei einigen Geräten, aber nicht für diejenigen, die Sie verwenden chrome sowie safari auf Ihrem ipad/iphone. Gibt es eine Möglichkeit, um diese zu löschen-Cache user-agents? clearing browser cache bei beiden Browsern nicht zu funktionieren scheint.
InformationsquelleAutor executor
2

Ich habe versucht, alle Antworten aus diesem thread, aber für den User-Agent aus dem IPhone 4S:

Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_3 like Mac OS X; de-de) AppleWebKit/533.17.9 (KHTML, like Gecko) Mobile/8F190

Ging es doch falsch. Schließlich benutzte ich die ClientTarget-Eigenschaft mit dem Wert "uplevel" zu zwingen ASP.NET immer neue browser-Funktionen. Ich habe diese in eine Basisklasse, die alle Seiten vererben.

Finden Sie unter: http://msdn.microsoft.com/en-us/library/system.web.ui.page.clienttarget.aspx
- +1, denn dies ist mehr zukunftssicher. Ich habe durchaus Zweifel, in der Zukunft wird jemand erstellen Sie einen browser, der ist schlimmer als der IE6.
- Alter thread, aber vielleicht hilft es: ich denke, es ist nicht der caching-Mechanismus, in diesem Fall aber die insgesamt schlechte "browser detection" von ASP.NET. Ich in letzter Zeit hatte, zu beheben einige der Themen, mit aktualisiert (oder custom) ".browser"-Dateien.
InformationsquelleAutor Rody van Sambeek
2

Lösung

Ich die <browserCaps userAgentCacheKeyLength='256'> element unter <system.web> und alles scheint zu funktionieren, wie folgt:
```
<configuration>
    <system.web>
        <browserCaps userAgentCacheKeyLength="256" />
    </system.web>
</configuration>
```
Ausführliche Erklärung

Den 'Browser capabilities user-agent cache-key-Länge" resolving-Mechanismus verwendet einen cache, um vorübergehend zu speichern Zuordnungen.

Standardmäßig verwendet es die ersten 64 Zeichen des UserAgent-string als cache-key, aber wenn ein user-agent auftaucht, wie es aussieht, gehört zu Safari, aber ist wirklich nicht nicht korrekt aufgelöst werden können, D. H. 'Mozilla 0.0'

Die Zuordnung wird im cache gespeichert, was bedeutet, dass alle UserAgent-strings mit der gleichen 64-Zeichen-Präfix jetzt falsch zugeordnet, bis der cache-Eintrag verfällt, d.h. in der Regel 1 minute.

Länge des Schlüssels verwendet für die Zwischenspeicherung konfiguriert ist, mit den folgenden:

Erhöhung der Schlüssellänge auf 256 um das problem zu beheben.

...Ich hatte Probleme bei der Suche nach dem richtigen Platz in meinem web.config - Datei zum einfügen der oben.

Wenn ich einlegen der <browserCaps userAgentCacheKeyLength="..." /> element direkt unter <configuration> in meinem web.config Datei, meine web-Anwendung sofort abgestürzt.

Glücklicherweise geschah dies in der Testumgebung und nicht in einer Produktionsumgebung.

Nachdem die online-Suche, fand ich einen alten MSDN-ASP .NET-Referenz-Seite ( http://msdn.microsoft.com/en-us/library/sk9az15a%28v=vs.71%29.aspx ), die vorgeschlagen, dass die <broswerCaps> element ein untergeordnetes element des <system.web>.

InformationsquelleAutor user1777803
0

Ich empfehlen, dass Sie erwägen, die Nutzung der folgenden:

http://aspnet.codeplex.com/releases/view/41420
- Auf den ersten Blick war ich skeptisch, dass dies helfen würde, weil ich bereits wusste, dass der browser die Definitionen bei dem link, den Sie sind die gleichen Definitionen, die verteilt sind mit den .net 4.0-installation Dateien. Doch auch diese Seite beinhaltet die ALTE browser-Definitionen aus .net 3.5 und schlägt mit den alten Definitionen, wenn Sie Kompatibilitätsprobleme. Es scheint, dass die alten browser-Definitionen sind, für uns zu arbeiten, aber es ist nicht eine satisifying zu beheben, verwenden Sie die alten Dateien. Hat sonst noch jemand irgendwelche Ideen, wie man diese Arbeit mit Hilfe der .Net 4.0-browser-Definitionen?
- Mein Zweck, indem es aus war, um zu sehen, wenn die Erkundung der Dateien würde etwas Licht auf das problem. Es gibt Fälle, wo Sie brauchen, zu zwicken diese Dateien, um Unterstützung für neue/Kunden aufgedeckt.
InformationsquelleAutor Keith Adler

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.