Dela via

Felsöka formulärautentisering

Gäller för: Internet Information Services

När du använder formulärautentisering i en ASP.NET webbapp behöver du ofta felsöka ett problem som uppstår när en ny eller en pågående begäran tillfälligt omdirigeras till programmets inloggningssida. Du kan felsöka det här problemet i Visual Studio IDE genom att koppla ett felsökningsprogram i en utvecklingsmiljö. I produktionsmiljöer blir uppgiften dock hektisk och problematisk. Om du vill felsöka ett slumpmässigt problem som det här måste du logga information som är relaterad till problemet så att du kan begränsa rotorsaken.

I den här artikeln beskrivs kortfattat begreppet formulärautentisering. Den beskriver också olika scenarier om en användare som omdirigeras till inloggningssidan och hur du samlar in data som är relevanta för att isolera problemet. Dessutom beskrivs även hur du implementerar ett IHttpModule gränssnitt för att logga formulärautentiseringsinformationen.

Översikt över ASP.NET Forms-autentisering

Med formulärautentisering kan du autentisera användare med hjälp av din egen kod och sedan underhålla en autentiseringstoken i en cookie eller i URL:en. Formulärautentisering deltar i ASP.NET sidlivscykel genom FormsAuthenticationModule klassen. Du kan komma åt formulärautentiseringsinformation och funktioner med hjälp av FormsAuthentication klassen.

Om du vill använda formulärautentisering skapar du en inloggningssida som samlar in autentiseringsuppgifter från användaren och innehåller kod för att autentisera autentiseringsuppgifterna. Vanligtvis konfigurerar du programmet för att omdirigera begäranden till inloggningssidan när användare försöker komma åt en skyddad resurs, till exempel en sida som kräver autentisering. Om användarens autentiseringsuppgifter är giltiga kan du anropa klassmetoder FormsAuthentication för att omdirigera begäran tillbaka till den ursprungligen begärda resursen med en lämplig autentiseringsbiljett (cookie). Om du inte vill ha omdirigeringen kan du bara hämta cookien för formulärautentisering eller ange den. Vid efterföljande begäranden skickar webbläsaren autentiseringscookien med begäran, som sedan kringgår inloggningssidan.

Som standard FormsAuthenticationModule läggs klassen till i filen Machine.config . Klassen FormsAuthenticationModule hanterar processen för formulärautentisering.

Du kan se följande post i filen Machine.config :

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

Du kan konfigurera formulärautentisering med hjälp av konfigurationselementet för autentisering, till exempel genom att ange en inloggningssida. I konfigurationsfilen anger du en URL för att omdirigera oautentiserade begäranden till inloggningssidan.

Efter lyckad autentisering anger modulen FormsAuthenticationModule värdet för egenskapen Användare till en referens till den autentiserade användaren. I följande kodexempel visas hur du programmatiskt läser identiteten för den formulärautentiserade användaren.

String authUser2 = User.Identity.Name;

Ett praktiskt sätt att arbeta med formulärautentisering är att använda ASP.NET medlemskap och ASP.NET inloggningskontroller. ASP.NET medlemskap kan du lagra och hantera användarinformation och innehåller metoder för att autentisera användare. ASP.NET inloggningskontroller fungerar med ASP.NET medlemskap. De kapslar in logiken för att be användarna om autentiseringsuppgifter, validera användare, återställa eller ersätta lösenord och så vidare. I själva verket ger ASP.NET-medlemskap och ASP.NET inloggningskontroller ett abstraktionslager över formulärautentisering. De här funktionerna ersätter det mesta eller allt arbete som du normalt behöver göra för att använda formulärautentisering.

Scenarier

Följande är scenarier för en begäran om att omdirigeras till login.aspx sidan:

Cookien för formulärautentisering går förlorad.

Scenario 1

Du loggar in på webbplatsen. Vid något tillfälle skickar klienten en begäran till servern och FormsAuthenticationModule klassen tar inte emot cookien.

Scenario 2

Cookien för formulärautentisering kan också gå förlorad när klientens cookiegräns överskrids. I Microsoft Internet Explorer finns det en gräns på 20 cookies. När räknaren når 20 tas de föregående 19 cookies bort från klientens samling. Om ASPXAUTH-cookien tas bort omdirigeras du till inloggningssidan när nästa begäran bearbetas.

Scenario 3

När begäran lämnar klienten finns det olika lager som kan påverka de paket som skickas. För att avgöra om en nätverksenhet tar bort cookien måste du samla in en nätverksspårning på klienten och servern och sedan titta i brödtexten i begäran om cookien. Du vill titta på klientbegäran för att se till att cookien skickades och kontrollera serverspårningen för att se till att servern tog emot cookien.

Tidsgränsen för formulärautentiseringsbiljetten överst

I ASP.NET 2.0-program och senare har formulärautentiseringsvärdet timeout som standard ändrats till 30 minuter. Det innebär att efter 30 minuters inaktivitet uppmanas du att logga in igen.

Kommentar

När du öppnar en webbplats varje gång återställs 30-minutersfönsterklockan. Bara om det är inaktivt finns det en timeout.

Om du vill ändra värdet så att det timeout blir längre kan du enkelt ändra timeout värdet i din lokala web.config-fil (värdet timeout är i minuter):

<system.web> 
 <authentication mode="Forms">     
   <forms timeout="120"/>                 
 </authentication>
</system.web>

Scenario 4

Formulärautentisering kan upphöra att gälla innan värdet för attributet timeout som definierats i konfigurationsfilen.

Om formulärautentiseringsbiljetten genereras timeout manuellt åsidosätter egenskapen för biljetten det värde som anges i konfigurationsfilen. Om det värdet är mindre än värdet i konfigurationsfilen upphör därför formulärautentiseringsbiljetten att gälla före attributet för konfigurationsfilen timeout och vice versa. Anta till exempel att FORMS timeout-attributet är inställt på 30 i filen Web.config och att förfallovärdet för biljetten är inställt på 20 minuter. I det här fallet upphör formulärautentiseringsbiljetten att gälla efter 20 minuter och sedan måste du logga in igen.

Event code: 4005
Event message: Forms authentication failed for the request. Reason: The ticket 
supplied has expired.

Scenario 5

I ASP.NET 4-webbappen med formulärautentisering står det i händelseloggmeddelandet:

Event code: 4005 
Event message: Forms authentication failed for the request. Reason: The ticket supplied was invalid.

Datainsamling och felsökning

Felsökningsscenario 1

Du kan avgöra om en begäran inte innehåller cookien genom att aktivera cookieloggning i Microsoft Internet Information Services (IIS). Följ stegen nedan:

  1. Öppna IIS Microsoft Management Console (MMC).
  2. Högerklicka på webbplatsen och välj sedan Egenskaper.
  3. Välj fliken Webbplats och välj sedan Aktivera loggning.
  4. Kontrollera att loggformatet är W3C Extended Log-filformat.
  5. Välj Egenskaper.
  6. Välj fliken Avancerat och välj sedan Utökade egenskaper.
  7. Under Utökade egenskaper väljer du kryssrutorna Cookie(cs(Cookie)) och Referer (cs(Referer)).

När det här problemet har uppstått avgör du vilken klient som hade problemet och klientens IP-adress. Filtrera IIS-loggen på klientens IP-adress och visa <COOKIE> kolumnen.

Kommentar

Använd Log Parser för att parsa IIS-loggarna.

När du har en lista över begäranden från en specifik användare söker du efter begäranden till inloggningssidan. Du skulle veta att de omdirigerades till den här sidan och du skulle vilja se begäranden innan omdirigeringen inträffade. Om du ser något som liknar följande skickade klienten antingen inte cookien eller så togs cookien bort i nätverket mellan klienten och servern.

Kommentar

Den första begäran kommer sannolikt inte att ha en cookie för formulärautentisering om du inte skapar en beständig cookie. IIS-loggen visar endast de cookies som togs emot i begäran. Den första begäran om att få formulärautentiseringscookien efter ett lyckat inloggningsförsök.

Felsökningsscenario 2

Microsoft Internet Explorer uppfyller följande rekommenderade minimibegränsningar för RFC 2109:

  • Minst 300 cookies.
  • Minst 4 096 byte per cookie (mätt med storleken på de tecken som utgör cookien som inte är terminal i syntaxbeskrivningen för Set-Cookie-huvudet).
  • Minst 20 cookies per unik värd eller domännamn.

Cookien för formulärautentisering kan också gå förlorad när klientens cookiegräns överskrids. I Microsoft Internet Explorer finns det en gräns på 20 cookies. När räknaren når 20 tas de föregående 19 cookies bort från klientens samling. Om ASPXAUTH-cookien tas bort omdirigeras du till inloggningssidan när nästa begäran bearbetas. Du kan använda Fiddler för att se HTTP-begärande- eller svarshuvudena för att se om du tar emot cookien från klienten. Ladda ned Fiddler.

Starta Fiddler-verktyget på klientdatorn, ta bort befintliga HTTP-spårningar, få åtkomst till ditt program som implementerar formulärautentisering och försök logga in i programmet och observera HTTP-trafiken på Fiddler för att se om det sker ett utbyte av formulärautentiseringscookie mellan klienten och servern. När du har avbildat trafiken dubbelklickar du på en begäran och väljer sedan Rubriker för att se rubriken Set-Cookie. Om du spårar en lyckad inloggning visas rubriken Set-Cookie i svaret för en lyckad inloggning.

Internet Explorer kan som standard lagra högst 20 cookies för varje domän. Om en server i domänen skickar fler än 20 cookies till en klientdator, tar webbläsaren på klientdatorn automatiskt bort några gamla cookies.

Varje cookie består av ett enda namn/värde-par. Det här paret kan följas av attribut/värde-par som avgränsas med semikolon. Den här gränsen har höjts för att förenkla utvecklingen och värdtjänsten för webbprogram på domäner som måste använda många cookies. Om du installerar uppdatering 937143 ökar antalet cookies som Internet Explorer kan lagra för varje domän från 20 till 50. Mer information finns i Internet Explorer och Vanliga frågor och svar om IT-proffs i Internet Explorer och Microsoft Edge.

Felsökningsscenario 3

När begäran lämnar klienten finns det olika lager som kan påverka de paket som skickas (brandväggar, proxyservrar och lastbalanserare). För att avgöra om en nätverksenhet tar bort cookien måste du samla in en nätverksspårning på klienten och servern och sedan söka efter cookien i brödtexten i begäran. Du kanske vill titta på klientbegäran för att se till att cookien skickades och kontrollera sedan serverspårningen för att se till att servern tog emot cookien.

Klientbegäran

Detta är en GET begäran när användaren har autentiserats. Formulärinformationen för autentiseringsbiljetten är markerad i grått. Detta bekräftar att cookieinformationen lämnade klienten. När du använder ett verktyg för nätverksinsamling, till exempel WireShark, ser du den trafik som faktiskt gick genom adaptern.

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

Begäran på serversidan

När du ser begäran som nådde servern kontrollerar du att servern har fått samma information som klienten skickade. Om servern inte fick samma information måste du undersöka andra enheter i nätverket för att avgöra var cookien togs bort.

Kommentar

Det har också förekommit instanser av ISAPI-filter som tar bort cookies. Om du bekräftar att webbservern har tagit emot cookien, men cookien inte finns med i IIS-loggarna, kontrollerar du ISAPI-filtren. Du kan behöva ta bort filtren för att se om problemet är löst.

Felsökningsscenario 5

  • Om scenariot omfattar en webbgrupp kontrollerar du att konfigurationsfilerna på varje server i webbgruppen har samma värde för valideringsnyckeln och dekrypteringsnycklarna, som används för hashning respektive dekryptering. Använd följande machineKey för att upprätthålla konsekvensen på alla servrar i servergruppen:

    <machineKey validationKey="<yourKey>" decryptionKey="<yourKey>" validation="SHA1" />

    Mer information om datornycklar finns i Maskinnyckel och Planera programsäkerhet.

    Information om hur du genererar datornycklar finns i Inställningar för maskinnyckel.

  • timeout Jämför värdena för båda formulären, d.v.s. autentiseringsmodulen och sessionsmodulen, på alla webbservrar.

  • Jämför den System.Web.dll versionen under mappen Framework för ASP.NET 4 mellan alla webbservrar i servergruppen. Formulärautentiseringen misslyckades för begäran. Anledningen är att det angivna biljetten var ogiltigt. Detta beror på att tillförlitlighetsuppdatering 1 saknas för MS .NET Framework 4 på en av webbservrarna.

  • Installera tillförlitlighetsuppdatering 1 för .NET Framework 4 kb2533523 på servern som saknade den och startade om servern. Problemet har åtgärdats. Mer information finns i Tillförlitlighetsuppdatering 1 för .NET Framework 4.

Mer information

Ansvarsfriskrivning för information från tredje part

De produkter från andra tillverkare som diskuteras i denna artikel tillverkas oberoende av Microsoft. Produkternas funktion eller tillförlitlighet kan därför inte garanteras.

  • Last updated on