DetailPage-MSS-KB

Knowledge Base

Artikel-ID: 910439 - Geändert am: Donnerstag, 30. Mai 2013 - Version: 2.0

 
ASP .NET Support Voice-Kolumne

Um diese Kolumne an Ihre Bedürfnisse anpassen, möchten wir möchten Sie einladen, reichen Sie Ihre Ideen zu Themen und Problemen, die Sie anzeigen möchten, in zukünftigen Knowledge Base-Artikeln und Support Voice-Kolumnen behandeln. Sie können Ihre Ideen und Feedback mit übermitteln die Danach Fragen (http://support.microsoft.com/common/survey.aspx?scid=sw;en;1176&p0=&p1=&p2=&p3=&p4=) Formular. Es gibt auch ein Link zu dem Formular am Ende dieser Spalte.

Auf dieser Seite

Willkommen Sie bei der ASP.NET Support Voice-Kolumne! Mein Name ist Jerry Orman. Ich seit 5 Jahren für Microsoft und die meisten verbracht Meine Zeit konzentriert, Web-Technologien wie Microsoft FrontPage und die neue Microsoft SharePoint-Technologien. Ich habe das letzte Jahr arbeiten mit Microsoft ASP.NET als Support Engineer. Diesen Monat in Support Voice Spalte, werde ich erläutern Sie die Behandlung von Formularauthentifizierung in Microsoft ASP.NET.

Wenn Sie in einer ASP.NET Anwendung Formularauthentifizierung verwenden, Sie finden es möglicherweise erforderlich, ein Problem zu beheben, das auftritt, wenn der Benutzer ist nach dem Zufallsprinzip umgeleitet auf die Anmeldeseite. In einer idealen Welt dies Problem würde auftreten, in einer Weise, mit denen Sie das einfache Anschließen würde ein Debugger und das Problem zu erfassen. In Produktionsumgebungen handelt es sich jedoch nur selten der Fall. Um eine zufällige Problem dieser Art zu beheben, müssen Sie Informationsmeldungen protokolliert das Problem so, dass Sie den Stamm einschränken können verursachen.

In dieser Spalte umfassen wir kurz die Forms Authentication Konzept. Wir werden dann die Szenarien ansehen dazu führen Sie, dass ein Benutzer auf die Anmeldeseite und wie Sie Daten erfassen umgeleitet zum Eingrenzen des Problems relevant ist. Wie implementieren eine IHttpModule-Schnittstelle, um die Formularauthentifizierung Informationen protokolliert werden auch besprochen.

Forms Authentication Overview

Wenn auf einer Website Benutzerauthentifizierung durch Verwenden der Formularauthentifizierung der Server erstellt einen Cookie. Der Wert des Cookies ist ein verschlüsseltes Formularauthentifizierungsticket. Das Cookie wird bei jeder Anforderung an den Server übergeben. die Anwendung und die FormsAuthenticationModule -Klasse entschlüsselt den Cookiewert und bestimmt, ob der Benutzer gültig ist.

Standardmäßig wird die FormsAuthenticationModule Klasse wird in der Datei Machine.config hinzugefügt. FormsAuthenticationModule -Klasse verwaltet den FormsAuthentication-Prozess.

Der folgende Code ist ein Eintrag aus der Datei Machine.config:
<httpModule>
     …other modules…
     <add name="FormsAuthentication"
         type="System.Web.Security.FormsAuthenticationModule" />
     …other modules…
</httpModule>
Der allgemeine HTTP-Datenverkehr für die Authentifizierung mithilfe von Formularauthentifizierung sieht etwa wie folgt:
  1. Der Client sendet eine HTTP-GET-Nachricht an Default.aspx. Es wird keine Formularauthentifizierungscookie gesendet.
  2. Der Server sendet eine Antwort 302 (Redirect), an Login.aspx.
  3. Der Client sendet eine HTTP POST an Login.aspx. Sie enthält die Login-Informationen.
  4. Der Server sendet eine Antwort 302 (Redirect), auf "default.aspx". Das Formularauthentifizierungscookie ist enthalten.
  5. Der Client sendet eine HTTP-GET-Nachricht an Default.aspx. Dazu gehören das Formularauthentifizierungscookie.
Weitere Informationen über die Implementierung und Verwendung Formularauthentifizierung finden Sie auf der folgenden MSDN-Websites:
http://msdn2.Microsoft.com/en-us/library/7t6b43z4.aspx (http://msdn2.microsoft.com/en-us/library/7t6b43z4.aspx)
http://msdn2.Microsoft.com/en-us/library/System.Web.Security.FormsAuthentication (werden) aspx (http://msdn2.microsoft.com/en-us/library/system.web.security.formsauthentication(vs.71).aspx)
http://msdn2.Microsoft.com/en-us/library/System.Web.Security.FormsAuthenticationTicket (werden) aspx (http://msdn2.microsoft.com/en-us/library/system.web.security.formsauthenticationticket(vs.71).aspx)
Weitere Informationen zum Freigeben von Formularauthentifizierungscookies finden Sie auf folgenden Website von ASP.NET:
http://QuickStarts.ASP.NET/QuickStartv20/ASPNET/doc/Security/formsauth.aspx (http://quickstarts.asp.net/QuickStartv20/aspnet/doc/security/formsauth.aspx)

Ursachen dafür, dass ein Benutzer zur Anmeldeseite umgeleitet werden kann

Das Formularauthentifizierungscookie geht verloren

Szenario 1

In diesem Szenario meldet sich der Benutzer auf die Website. An einem bestimmten Punkt der Client sendet eine Anforderung an den Server und die FormsAuthenticationModule -Klasse erhält keine Cookies. Sie können Prüfen Sie, ob eine Benutzeranforderung nicht das Cookie enthalten, indem Sie Cookies aktivieren die Protokollierung in Microsoft-Internetinformationsdienste (IIS). Gehen Sie hierzu folgendermaßen vor:
  1. Öffnen Sie die IIS Microsoft Management Console (MMC).
  2. Auf der Website, und klicken Sie dann aufEigenschaften.
  3. Klicken Sie auf die Website Registerkarte, und klicken Sie dann auf Aktivieren Protokollierung.
  4. Stellen Sie sicher, dass das Format ist W3C Extended Log File Format.
  5. Klicken Sie auf Eigenschaften.
  6. Klicken Sie auf die Erweiterte Registerkarte, und klicken Sie dann aufErweiterte Eigenschaften.
  7. Klicken Sie unter Erweiterte Eigenschaften, aktivieren Sie die Cookie(cs(Cookie)) das Kontrollkästchen und die Referer (cs(Referer)) das Kontrollkästchen.
Nachdem dieses Problem auftritt, bestimmen, welcher Client hatte die Problem und die IP-Adresse des Clients. Filtern Sie das IIS-Protokoll auf den Client IP-Adresse, und zeigen Sie das Cookie> Spalte.

Hinweis Log Parser können Sie die IIS-Protokolle analysieren. Log Parser herunterladen, finden Sie auf der folgenden Microsoft-Website:
http://www.Microsoft.com/downloads/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07 (http://www.microsoft.com/downloads/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07)
Nachdem Sie die Liste der Anfragen von diesem bestimmten haben Benutzer, suchen Sie nach den Anforderungen an die Anmeldeseite. Sie wissen, dass sie weitergeleitet wurden auf diese Seite, und Sie möchten Anforderungen vor finden Sie unter der Umleitung ist aufgetreten. Wenn Sie etwas ähnlich dem folgenden Client finden Sie unter entweder hat nicht gesendet, dass das Cookie oder das Cookie auf dem Netzwerk zwischen dem Client entfernt wurde und Server.

Dies ist die erste Anmeldung.
Tabelle minimierenTabelle vergrößern
-MethodeSeiteAntwortCookies
GET/ Default.aspx302 (Redirect)Nein Cookies
GET/Login.aspx200 (Erfolg)Nein Cookies
POST-TEST/Login.aspx302 (Redirect)Nein Cookies
GET/ Default.aspx200 (Erfolg).ASPXAUTH
GET/SomePage.aspx302 (Redirect)Nein .ASPXAUTH-Cookie
Dies sind die anderen Anforderungen, gefolgt von einer Anforderung einer Seite auf der Website ohne die.ASPXAUTH-Cookie.
Tabelle minimierenTabelle vergrößern
-MethodeSeiteAntwortCookies
GET/SomePage.aspx302 (Redirect)Nein .ASPXAUTH-Cookie
GET/Login.aspx200 (Erfolg)Nein .ASPXAUTH-Cookie
POST-TEST/Login.aspx302 (Redirect)Nein .ASPXAUTH-Cookie
GET/SomePage.aspx200 (Erfolg).ASPXAUTH

Hinweis Die erste Anforderung von diesem Benutzer wahrscheinlich keine Formen haben Authentifizierungs-Cookie, wenn Sie ein dauerhaftes Cookie erstellt werden. Das IIS-Protokoll zeigt nur Sie die Cookies, wurden in der Anforderung empfangen. Die erste Anforderung an das Formularauthentifizierungscookie haben werden die Anforderung nach einer erfolgreichen Anmeldung fehlerhaft.
Szenario 2

Das Formularauthentifizierungscookie kann auch verloren, wenn der Client Cookies Grenze überschritten wird. In Microsoft Internet Explorer sind maximal 20 Cookies. Nach dem 20. Cookie ist auf dem Client erstellt, werden vorherige Cookies aus des Clients entfernt. Auflistung. Wenn die.ASPXAUTH-Cookie wird entfernt, der Benutzer zur Anmeldeseite umgeleitet, wenn die nächste Anforderung verarbeitet wird.

Sie können diese beiden Szenarien auf die gleiche Weise behandeln. Betrachten Sie die Anforderung nur die Umleitung zur Anmeldeseite. Wenn die Anforderung an diese Seite wird generiert Cookies, werden dadurch etwas zu untersuchen.

Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base:
306070  (http://support.microsoft.com/kb/306070/ ) Anzahl und Größe Grenzen eines Cookies in Internet Explorer

Fiddler-Tool können Sie die HTTP-Header anzeigen an den Client gesendet wurden. Doppelklicken Sie auf eine Anforderung, nach der Aufzeichnung des Datenverkehrs, , und klicken Sie dann auf Kopfzeilen den Set-Cookie-Header zu sehen. Wenn Sie verfolgen ein erfolgreiche Anmeldung sehen Sie den Set-Cookie-Header in der Antwort von einem erfolgreiche Anmeldung.

Um Fiddler-Tool herunterzuladen, die folgenden Fiddler-Website:
http://www.fiddlertool.com/Fiddler/ (http://www.fiddlertool.com/fiddler/)
Szenario 3

Nachdem die Anforderung des Clients verlassen hat, gibt es verschiedene Ebenen Das kann die Pakete auswirken, die gesendet werden. Um festzustellen, ob ein Netzwerkgerät ist entfernen das Cookie, müssen Sie eine Netzwerkablaufverfolgung auf dem Client und dem Server zu erfassen, und suchen Sie in den Hauptteil der Anforderung für das Cookie. Sie möchten Betrachten Sie die Clientanforderung um sicherzustellen, dass das Cookie gesendet wurde, und überprüfen Sie den server Ablaufverfolgung, um sicherzustellen, dass der Server das Cookie erhalten.

Client-Anfrage

Dies ist eine GET-Anforderung, nachdem der Benutzer authentifiziert wurde. Die Formularauthentifizierungsticket-Informationen ist blau hervorgehoben. Dadurch wird bestätigt die Cookieinformationen den Client verlassen. Wenn Sie eine Netzwerksammlung verwenden Tool, wie Netmon, sehen Sie den Datenverkehr, der eigentlich durch ging die Adapter.
47 45 54 20 68 74 74 70-3a 2f 2f 6c 6f 63 61 6c   GET http://local
68 6f 73 74 2f 46 6f 72-6d 73 41 75 74 68 4c 6f   host/FormsAuthLo
67 54 65 73 74 2f 57 65-62 46 6f 72 6d 31 2e 61   gTest/WebForm1.a
73 70 78 20 48 54 54 50-2f 31 2e 31 0d 0a 41 63   spx HTTP/1.1..Ac
63 65 70 74 3a 20 69 6d-61 67 65 2f 67 69 66 2c   cept: image/gif,
…Other headers of the GET request…
63 68 65 0d 0a 43 6f 6f-6b 69 65 3a 20 2e 41 53   che..Cookie: .AS
50 58 41 55 54 48 3d 33-43 45 46 39 42 39 41 30   PXAUTH=3CEF9B9A0
43 33 37 41 44 46 36 33-45 36 42 44 33 37 42 36   C37ADF63E6BD37B6
39 43 44 41 32 35 30 30-30 46 38 30 37 32 38 46   9CDA25000F80728F
35 31 43 39 35 36 36 44-31 34 43 35 34 31 34 35   51C9566D14C54145
38 31 43 39 33 45 32 41-30 31 44 44 43 44 45 46   81C93E2A01DDCDEF
32 34 41 31 37 34 32 39-34 31 30 43 30 39 37 34   24A17429410C0974
42 33 45 43 42 30 36 34-32 32 38 45 33 35 33 39   B3ECB064228E3539
39 41 38 32 32 42 33 42-39 33 36 44 46 30 38 46   9A822B3B936DF08F
42 41 42 44 33 45 31 30-32 44 30 30 32 31 30 43   BABD3E102D00210C
32 45 31 33 39 38 30 37-39 42 32 33 35 32 39 46   2E1398079B23529F
34 46 35 44 37 34 41 3b-20 50 72 6f 66 69 6c 65   4F5D74A; Profile
3d 56 69 73 69 74 6f 72-49 64 3d 62 32 34 65 62   =VisitorId=b24eb
Server-Side-Anforderung

Wenn Sie die Anforderung anzeigen, die den Server erreicht Sie wollen, stellen Sie sicher, dass der Server hat die gleiche Informationen erhalten, die Client gesendet. Wenn der Server die gleiche Informationen nicht erhalten haben, müssen Sie andere Geräte auf untersuchen die Netzwerk, um zu bestimmen, in dem das Cookie entfernt wurde.

Hinweis Es gab auch Instanzen der ISAPI-Filter entfernen von Cookies. Wenn Sie bestätigen, dass der Webserver erhalten hat, das Cookie, das Cookie wird jedoch nicht aufgeführt Überprüfen Sie in den IIS-Protokollen die ISAPI-Filter. Sie müssen möglicherweise entfernen Sie die Filter, um festzustellen, ob die Problem ist gelöst.

Das Formularauthentifizierungsticket Timeout

Andere häufige Ursache für einen Benutzer umgeleitet wird Wenn die Formularauthentifizierung Ticket ist abgelaufen. Die Formularauthentifizierung Ticket ein Timeout auf zwei Arten möglich. Das erste Szenario tritt auf, wenn Sie verwenden absolute Ablaufzeit. Mit absoluten Ablaufzeit das Authentifizierungsticket abläuft als die Ablaufzeit abläuft. Legen Sie z. B. eine Ablaufzeit von 20 Minuten und einen Benutzer die Site besucht, um 14:00 Uhr. Der Benutzer wird zur Anmeldeseite umgeleitet der Benutzer besucht die Website nach 14:20 Uhr.

Wenn Sie die gleitende Ablaufzeit verwenden die Szenario ist etwas komplizierter. Das Cookie und das resultierende Ticket sind aktualisiert, wenn der Benutzer die Website besucht, nachdem die Ablaufzeit Hälfte abgelaufen ist. Legen Sie z. B. eine Ablaufzeit von 20 Minuten mit gleitende Ablaufzeit. Ein Benutzer die Site besucht, um 14:00 Uhr, und der Benutzer erhält einen Cookie, der festgelegt wird, um 14:20 Uhr abläuft. Die Ablaufzeit wird nur aktualisiert, wenn der Benutzer die Website nach 14:10 Uhr besucht. Wenn der Benutzer die Website um 14:09 Uhr aufruft, das Ticket wird nicht aktualisiert, da die Hälfte der die Ablaufzeit hat nicht bestanden. Wenn der Benutzer dann 12 Minuten wartet, besuchen Sie die Website um 14:21 Uhr Das Ticket läuft bald ab. Der Benutzer wird zur Anmeldung umgeleitet. Seite.

Eine Möglichkeit, diese Art von Problem nähern ist sich die Formulare Authentifizierung Cookie und Ticket-Informationen. Auf diese Weise sehen Sie die Cookie wurde empfangen, indem Sie IIS und was sind die Werte. Hierzu können Sie durch Schreiben ein HttpModule, und klicken Sie dann das Modul in der Anforderungspipeline anschließen. Sie müssen nicht so ändern Sie den Code der Anwendung um die Informationen zu erhalten Sie müssen.

Im angefügte Beispiel arbeitet in der Microsoft.NET Framework 1.1 und.NET Framework 2.0 und hat Kommentare in der gesamten. Das Beispiel enthält die folgenden Dateien:
  • FormsAuthEvents.cs: Die Klasse, die IHttpModule implementiert und bindet in das Ereignis Application_BeginRequest .
  • FormsAuthInfo.cs: Die Klasse, die das Cookie abruft und entschlüsselt das Formularauthentifizierungsticket. Außerdem überprüft Sie der Anwendungdes Datei "Web.config", um sicherzustellen, dass die Formularauthentifizierung aktiviert ist.
  • FormsAuthConfig.cs: Die Klasse, die liest Informationen aus der FormsAuthLogger.config-Datei.
  • Log.cs: Die Datei, die einen Stringbuilder akzeptiert und schreibt die Werte in einer Protokolldatei gespeichert.
  • FormsAuthLogger.config: Der XML-Datei, die gelesen wird durch die Datei Log.cs. Dies Datei muss im Ordner "/ bin" mit der DLL erstellt werden. Die Datei können Sie Konfigurieren Sie Folgendes:
    • Filtern nach IP: Sie können die Erfassung von Daten durch Filtern Client-IP. Auf diese Weise können Sie nur Anforderungen von einem Client anmelden, die bekannt ist Reproduzieren Sie das Problem. Dies reduziert die Größe des Protokolls.
    • Typ: Gibt an, wo die Datei gespeichert. Der Standardwert ist der Ordner Temporary ASP.NET Files, aber Sie können dies speichern an einer beliebigen Stelle solange das Konto des Arbeitsprozesses die Berechtigung zum Schreiben in die Ordner.
Hinweis Ich gebe einen Downloadlink für der Code in bereitgestellten der FormsAuthLogger.zip-Datei.

Ich werde hier die wichtigsten Bereiche hinweisen:
  1. Erstellen Sie eine Klasse, die IHttpModule -Schnittstelle implementiert.
    public class FormsAuthEvents : IHttpModule 
    {
    		…code…
    }
  2. Wire, um das Ereignis, die, dem Sie betrachten möchten. In diesem Beispiel Wir verwenden das Ereignis Application_BeginRequest . Auf diese Weise können wir jede Anforderung zu untersuchen und bestimmen, ob Es wurde der Formularauthentifizierungscookies und des Protokolls FormsAuthenticationTicket , wenn das Cookie vorhanden ist.
    public void Init(HttpApplication application) 
    {
    	//Wire up the BeginRequest event
    	application.BeginRequest += (new EventHandler(this.Application_BeginRequest));
    }
  3. Implementieren Sie das Ereignis Application_BeginRequest .
    private void Application_BeginRequest(Object source, EventArgs e)
    {	
       …code to log the ticket…
    }
    
  4. Das Formularauthentifizierungscookie abrufen und dann zu entschlüsseln Es ist.
  5. Melden Sie sich die Werte. Ich empfehle Ihnen Folgendes anmelden Zusätzlich zu den Formularinformationen. So können Sie Ihre Formulare richten Authentifizierungsinformationen an den IIS-Protokollen, bei Bedarf:
    • Datum: Können Sie sehen, wenn die Anforderung stammt in.
    • "RequestType": Zeigt, ob die Anforderung eine Get oder Post.
    • URL: Zeigt das Muster der Anforderungen, die zu dem Problem führen.
    • Referrer
    • ClientIP: Bindungen in der Anforderungen an ein bestimmtes Client.

Wie immer gerne und Wünsche zu Themen wirklich in einem zukünftigen Artikel oder in der Knowledge Base mithilfe der Danach Fragen (http://support.microsoft.com/common/survey.aspx?scid=sw;en;1176&p0=&p1=&p2=&p3=&p4=) Formular.

Die Informationen in diesem Artikel beziehen sich auf:
  • Microsoft ASP.NET 1.1
  • Microsoft ASP.NET 1.0
  • Microsoft ASP.NET 2.0
Keywords: 
kbtshoot kbiis kbcode kbasp kbmt KB910439 KbMtde
Maschinell übersetzter ArtikelMaschinell übersetzter Artikel
Wichtig: Dieser Artikel wurde maschinell übersetzt und wird dann möglicherweise mithilfe des Community Translation Framework (CTF) von Mitgliedern unserer Microsoft Community nachbearbeitet. Weitere Informationen zu CTF finden Sie unter http://support.microsoft.com/gp/machine-translation-corrections/de.
Den englischen Originalartikel können Sie über folgenden Link abrufen: 910439  (http://support.microsoft.com/kb/910439/en-us/ )
Microsoft stellt Ihnen die in der Knowledge Base angebotenen Artikel und Informationen als Service-Leistung zur Verfügung. Microsoft übernimmt keinerlei Gewährleistung dafür, dass die angebotenen Artikel und Informationen auch in Ihrer Einsatzumgebung die erwünschten Ergebnisse erzielen. Die Entscheidung darüber, ob und in welcher Form Sie die angebotenen Artikel und Informationen nutzen, liegt daher allein bei Ihnen. Mit Ausnahme der gesetzlichen Haftung für Vorsatz ist jede Haftung von Microsoft im Zusammenhang mit Ihrer Nutzung dieser Artikel oder Informationen ausgeschlossen.
Freigeben
Weitere Supportoptionen
Microsoft Community-Supportforen
Kontaktieren Sie uns direkt
Zertifizierten Partner finden
Microsoft Store