Felsökning: Formulärautentisering

ASP .NET stöd röst kolumn

Felsöka formulärautentisering

Vi vill bjuda in dig att skicka dina idéer om ämnen som intresserar du och problem som du vill se i framtida adresserat kunskapsbasartiklar och Support röst kolumner om du vill anpassa den här kolumnen efter dina behov. Du kan skicka dina idéer och feedback med hjälp av formuläret Fråga för den . Det finns också en länk till formuläret längst ned i den här kolumnen.

Välkommen till kolumnen ASP.NET stöd röst! Jag heter Jerry Orman. Jag har Microsoft under 5 år och använt de flesta av min tid fokuserat på Web-relaterade tekniker, till exempel Microsoft FrontPage och ny Microsoft SharePoint-teknik. Jag har lagt ned det sista året som arbetar med Microsoft ASP.NET som en supporttekniker. Den här månaden i kolumnen stöd röst ska vi förklara hur du felsöker formulärautentisering i Microsoft ASP.NET.

Felsöka formulärautentisering

När du använder formulärautentisering i ASP.NET-program kan det vara nödvändigt för att felsöka ett problem som uppstår när slumpvis omdirigeras användaren till inloggningssidan. I en perfekt värld skulle inträffa på ett sätt som skulle gör att du enkelt kan koppla en felsökare och fånga problemet. I produktionsmiljöer, men är detta sällan fallet. Om du vill felsöka ett slumpmässigt problem som det här måste du logga information om problemet så att du kan begränsa orsaken.

I den här kolumnen rapporterar vi kortfattat begreppet formulärautentisering. Sedan ska vi titta i vilka fall leda till en användare dirigeras till inloggningssidan och hur du kan samla in data som är relevanta för att isolera problemet. Vi beskriver också hur du implementerar ett gränssnitt IHttpModule logginformation formulärautentisering.

Formulär autentisering: översikt

När en användare autentiseras på en webbplats genom att använda formulärautentisering, skapar servern en cookie. Värdet på en cookie är en biljett för autentisering av krypterade formulär. Cookien skickas till servern för varje begäran till programmet och klassen FormsAuthenticationModule dekrypterar cookie-värde och avgör om användaren är giltig eller inte.

Klassen FormsAuthenticationModule läggs i filen Machine.config. Klassen FormsAuthenticationModule hanterar processen FormsAuthentication.

En transaktion från filen Machine.config är följande:

<httpModule>     …other modules…
<add name="FormsAuthentication"
type="System.Web.Security.FormsAuthenticationModule" />
…other modules…
</httpModule>

Den allmänna http-trafiken för autentisering genom att använda formulärautentisering ser ut ungefär så här:

  1. Klienten skickar en HTTP GET till Default.aspx. Ingen cookie för autentisering av formulär skickas.

  2. Servern skickar svaret 302 (omdirigering) till Login.aspx.

  3. Klienten skickar en HTTP POST till Login.aspx. Den innehåller inloggningsinformation.

  4. Servern skickar svaret 302 (omdirigering) till Default.aspx. Autentiseringscookien formulär ingår.

  5. Klienten skickar en HTTP GET till Default.aspx. Detta inkluderar formulär autentiseringscookien.

Mer information om implementering och använder formulärautentisering finns på följande MSDN-webbplatser:

http://msdn2.microsoft.com/en-us/library/7t6b43z4.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(vs.71).aspxMer information om att dela formulär autentiseringscookies följande ASP.NET-webbplats:

http://quickstarts.asp.net/QuickStartv20/aspnet/doc/security/formsauth.aspx

Orsaker till att en användare kan dirigeras till inloggningssidan

Autentiseringscookien formulär går förlorade

Scenario 1


I det här fallet loggar en användare in på webbplatsen. Någon gång klienten skickar en begäran till servern, och
FormsAuthenticationModule -klass får inte cookien. Du kan avgöra om en begäran inte innehåller cookien genom att aktivera loggning i Microsoft Internet Information Services (IIS) cookie. Gör så här:

  1. Öppna IIS Microsoft Management Console (MMC).

  2. Högerklicka på webbplatsen och klicka sedan på
    Egenskaper.

  3. Klicka på fliken webbplats och klicka sedan på Aktivera loggning.

  4. Kontrollera att loggfilens format är W3C Extended Log File Format.

  5. Klicka på Egenskaper.

  6. Klicka på fliken Avancerat och klicka sedan på
    Utökade egenskaper.

  7. Klicka på om du vill markera kryssrutan Cookie(cs(Cookie)) under Utökade egenskaperoch referent (cs(Referer)) kryssrutan.

När detta inträffar Bestäm vilken klient hade problemet och att klientens IP-adress. Filtrera på att klientens IP-adress i IIS-loggen och visa kolumnen <cookie>.

Obs! Du kan använda loggen tolken för att parsa IIS-loggar. Om du vill hämta loggen tolken finns på följande Microsoft-webbplats:

http://www.microsoft.com/downloads/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07När du har listan med begäranden från den specifika användaren söka efter begäran till inloggningssidan. Du vet att de har omdirigerats till den här sidan och du vill se begäranden innan omdirigeringen uppstod. Om du ser något som liknar följande klienten antingen skickade inte cookien eller cookien har tagits bort i nätverket mellan klienten och servern.

Detta är den första inloggningen.

Metoden

Sidan

Svar

Cookies

HÄMTA

/Default.aspx

302 (omdirigering)

Inga Cookies

HÄMTA

/Login.aspx

200 (lyckades)

Inga Cookies

BOKFÖR

/Login.aspx

302 (omdirigering)

Inga Cookies

HÄMTA

/Default.aspx

200 (lyckades)

.ASPXAUTH

HÄMTA

/SomePage.aspx

302 (omdirigering)

Nej. ASPXAUTH Cookie

Det här är andra begäranden, följt av en begäran till en sida på webbplatsen utan att de. ASPXAUTH cookie.

Metoden

Sidan

Svar

Cookies

HÄMTA

/SomePage.aspx

302 (omdirigering)

Nej. ASPXAUTH Cookie

HÄMTA

/Login.aspx

200 (lyckades)

Nej. ASPXAUTH Cookie

BOKFÖR

/Login.aspx

302 (omdirigering)

Nej. ASPXAUTH Cookie

HÄMTA

/SomePage.aspx

200 (lyckades)

.ASPXAUTH


Obs! Den första begäran från användaren sannolikt inte har en autentiseringscookie formulär såvida du inte skapar en beständig cookie. IIS-loggen kommer endast visa cookies som tagits emot i begäran. Den första begäran till har autentiseringscookien formulär kommer att på begäran efter en lyckad inloggningsförsöket.

Scenario 2


Autentiseringscookien formulär kan också gå förlorade när klientens cookie gränsen överskrids. Det finns en gräns på 20 cookies i Microsoft Internet Explorer. Efter 20 cookien skapas på klienten, tas tidigare cookies bort från klientens samling. Om den. ASPXAUTH cookie tas bort kan användaren omdirigeras till inloggningssidan när nästa begäran bearbetas.

På samma sätt kan du felsöka dessa två scenarier. Titta på begäran innan omdirigering till inloggningssidan. Om begäran till den här sidan genererar cookies, är detta något att undersöka.

För mer information klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:

306070 nummer och storleksbegränsningar för cookies i Internet Explorer


Du kan använda Fiddler för att visa HTTP-huvuden som skickas till klienten. När du fångar upp trafiken dubbelklickar du på en begäran och klicka sedan på rubriker om du vill se Set-Cookie-huvudet. Om du vill spåra en lyckad inloggning, visas Set-Cookie-huvudet i svaret för en lyckad inloggning.

Om du vill hämta Fiddler följande Fiddler-webbplats:

http://www.fiddlertool.com/fiddler/

Scenario 3


När begäran lämnar klienten, finns det olika lager som kan påverka de paket som skickas. Ta reda på om en nätverksenhet tar bort cookien måste du fånga ett nätverksspår på klienten och servern och leta i själva begäran för cookie. Du vill titta på klientbegäran för att säkerställa att cookien skickades och kontrollera serverspårning för att kontrollera att servern har tagit emot cookien.

Klientbegäran

Det här är en GET-begäran när användaren har autentiserats. Formulär för biljett autentiseringsinformation markeras i blått. Det bekräftar att cookie-information lämnas klienten. När du använder ett nätverk capture verktyg, som Netmon, se trafik som faktiskt gick igenom kortet.

47 45 54 20 68 74 74 70-3a 2f 2f 6c 6f 63 61 6c   GET http://local68 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

SSI-begäran

När du tittar på den begäran som nått servern vill du kontrollera att servern har fått samma information som skickas av klienten. Om servern inte få samma information, måste du undersöka andra enheter i nätverket för att fastställa om cookien har tagits bort.

Obs! Dessutom har instanser av ISAPI-filter tar bort cookies. Om du bekräftar att webbservern fått cookien, men inte cookien visas i IIS-loggarna Kontrollera ISAPI-filter. Du kan behöva ta bort filter för att se om problemet är löst.

Formulär-autentiseringsbiljetten timeout

Andra vanliga orsaken för en användare att omdirigeras är om autentiseringsbiljetten formulär har upphört att gälla. Formulär-autentiseringsbiljetten kan timeout på två sätt. Det första scenariot inträffar om du använder absolut förfallodatum. Med absolut förfallodatum autentiseringsbiljetten upphör att gälla när förfallotiden som upphör att gälla. Till exempel du anger ett förfallodatum på 20 minuter, och en användare besöker webbplatsen kl 2:00. Användaren dirigeras till inloggningssidan om användaren besöker webbplatsen efter 14:20:00.

Om du använder glidande förfallodatum är något mer komplicerat. Cookie-filen och den resulterande biljetten uppdateras om användaren besöker webbplatsen efter förfallotiden är hälften har upphört. Till exempel kan du ange ett förfallodatum på 20 minuter med glidande förfallodatum. En användare besöker webbplatsen kl 2:00 och användaren tar emot en cookie som ska löpa ut kl 2:20. Sista giltighetsdag uppdateras endast om användaren besöker webbplatsen efter 14:10:00. Om användaren besöker webbplatsen kl 2:09, uppdateras inte biljetten eftersom hälften av förfallotid inte har överskridits. Om användaren väntar sedan 12 minuter besöker webbplatsen kl 2:21, biljetten upphöra att gälla. Användaren dirigeras till inloggningssidan.

Ett sätt att metoden den här typen av problem är att logga informationen formulär autentisering cookie och biljett. På så sätt kan du se om cookien togs emot av IIS och värdena är. Du kan göra detta genom att skriva en HttpModuleoch sedan ansluta modulen till begäran rörledning. Du kommer inte att ändra programkoden för att få den information du behöver.

Bifogade provet fungerar i Microsoft.NET Framework 1.1 och.NET Framework 2.0 och har kommentarer i hela. Provet innehåller följande filer:anteckning ska jag ger en hämtningslänk för koden i filen FormsAuthLogger.zip.

Jag ska peka ut de huvudsakliga områdena:


Som alltid, gärna skicka idéer om ämnen som du vill använda i framtiden upp kolumner eller i Knowledge Base med den
Be för det formulär.

Behöver du mer hjälp?

Utöka dina kunskaper
Utforska utbildning
Få nya funktioner först
Anslut till Microsoft Insiders

Hade du nytta av den här informationen?

Hur nöjd är du med översättningskvaliteten?

Vad påverkade din upplevelse?

Har du ytterligare feedback? (Valfritt)

Tack för din feedback!

×