Logga in med Microsoft
Logga in eller skapa ett konto.
Hej,
Välj ett annat konto.
Du har flera konton
Välj det konto som du vill logga in med.

Asp .NET-röstkolumn för support

Felsöka formulärautentisering

Välkommen till kolumnen ASP.NET Support Voice! Jag heter Jerry Orman. Jag har arbetat hos Microsoft i över 5 år och har ägnat större delen av min tid åt webbrelaterad teknik som Microsoft FrontPage och de nya Microsoft SharePoint-teknikerna. Jag har arbetat med Microsoft ASP.NET som supporttekniker det senaste året. Den här månaden i kolumnen Support Voice kommer jag att förklara hur du felsöker Formulärautentisering i Microsoft ASP.NET.

Felsöka formulärautentisering

När du använder Formulärautentisering i ett ASP.NET program kan det hända att det är nödvändigt att felsöka ett problem som uppstår när användaren slumpmässigt omdirigeras till inloggningssidan. I en idealisk värld skulle det här problemet uppstå på ett sätt som gör att du enkelt kan bifoga en felsökare och fånga problemet. I produktionsmiljöer är detta dock sällan fallet. 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 orsaken.

I den här kolumnen kommer vi att kortfattat ta upp begreppet Forms-autentisering. Sedan undersöker vi vilka scenarier som leder till att en användare omdirigeras till inloggningssidan och hur data som är relevanta för att isolera problemet registreras. Vi kommer också att ta reda på hur du implementerar ett IHttpModule-gränssnitt för att logga formulärautentiseringsinformationen.

Översikt över formulärautentisering

När en användare autentiserar till en webbplats med hjälp av Formulärautentisering skapar servern en cookie. Cookiens värde är ett autentiseringsärende för krypterade formulär. Cookien skickas till servern på varje begäran till programmet och klassen FormsAuthenticationModule dekrypterar cookievärdet och avgör om användaren är giltig eller inte.

Som standard läggs klassen FormsAuthenticationModule till i den Machine.config filen. Klassen FormsAuthenticationModule hanterar FormsAuthentication-processen.

Följande är en post från den Machine.config filen:

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

Den allmänna HTTP-trafiken för autentisering med formulärautentisering ser ut ungefär så här:

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

  2. Servern skickar ett 302-svar (omdirigering) till Login.aspx.

  3. Klienten skickar ett HTTP-INLÄGG till Login.aspx. Den innehåller inloggningsinformationen.

  4. Servern skickar ett 302-svar (omdirigering) till Default.aspx. Cookie för formulärautentisering ingår.

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

Mer information om hur du implementerar 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 hur du delar formulärautentiseringscookies finns på följande ASP.NET webbplats:

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

Orsaker till att en användare kan omdirigeras till inloggningssidan

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

Scenario 1


I det här scenariot loggar en användare in på webbplatsen. Vid något tillfälle skickar klienten en begäran till servern och
FormsAuthenticationModule-klassen får inte cookien. Du kan avgöra om en användarbegäran inte innehåller cookien genom att aktivera cookie-loggning i Microsoft Internet Information Services (IIS). 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 sedan på Aktivera loggning.

  4. Kontrollera att loggformatet är W3C Extended Log File Format.

  5. Klicka på Egenskaper.

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

  7. Under Utökade egenskaper markerar du kryssrutan Cookie(cs(Cookie)) och kryssrutan Refererare (cs(Referer)).

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

Obs! Du kan använda Loggparser för att tolka IIS-loggarna. Om du vill ladda ned Loggparser går du till följande Microsoft-webbplats:

http://www.microsoft.com/download/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07 När du har listan med begäranden från den specifika användaren söker du efter begäranden till inloggningssidan. Du vet att de omdirigerades till den här sidan och du vill se förfrågningarna innan omdirigeringen inträffade. Om du ser något liknande följande skickade klienten antingen inte cookien eller så togs cookien bort i nätverket mellan klienten och servern.

Det här är den första inloggningen.

Metod

Sida

Svar

Cookies

/Default.aspx

302 (omdirigering)

Inga cookies

/Login.aspx

200 (framgång)

Inga cookies

INLÄGG

/Login.aspx

302 (omdirigering)

Inga cookies

/Default.aspx

200 (framgång)

. ASPXAUTH

/SomePage.aspx

302 (omdirigering)

Nej. ASPXAUTH-cookie

Det här är andra förfrågningar, följt av en begäran till en sida på webbplatsen utan . ASPXAUTH-cookie.

Metod

Sida

Svar

Cookies

/SomePage.aspx

302 (omdirigering)

Nej. ASPXAUTH-cookie

/Login.aspx

200 (framgång)

Nej. ASPXAUTH-cookie

INLÄGG

/Login.aspx

302 (omdirigering)

Nej. ASPXAUTH-cookie

/SomePage.aspx

200 (framgång)

. ASPXAUTH


Obs! Den första begäran från den användaren kommer sannolikt inte att ha en cookie för formulärautentisering om du inte skapar en beständig cookie. I IIS-loggen visas endast de cookies som togs emot i begäran. Den första begäran om att få formulärautentiseringscookien kommer att finnas på begäran efter ett lyckat inloggningsförsök.

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 den 20:e cookien har skapats på klienten tas tidigare cookies bort från klientens samling. Om . ASPXAUTH-cookie tas bort, användaren omdirigeras till inloggningssidan när nästa begäran bearbetas.

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

Du kan använda Fiddler för att visa HTTP-rubrikerna som skickas till klienten. När du har sparat trafiken dubbelklickar du på en begäran och klickar sedan på Rubriker för att se det Set-Cookie sidhuvudet. Om du spårar en lyckad inloggning visas rubriken Set-Cookie i svaret på en lyckad inloggning.

Om du vill ladda ned Fiddler går du till 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 vilka paket som skickas. För att avgöra om en nätverksenhet tar bort cookien måste du registrera 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 kontrollera att cookien har skickats och kontrollera serverspårningen för att kontrollera att servern har tagit emot cookien.

Klientbegäran

Detta är en GET-begäran efter att användaren har autentiserats. Formulärinformationen för autentiseringsärenden markeras i blått. Detta bekräftar att cookieinformationen lämnade klienten. När du använder ett nätverksverktyg, till exempel Netmon, ser du trafiken 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

Serverbegäran

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

Obs! 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.

Tidsgränsen för formulärautentiseringsbegäran

Den andra vanliga orsaken till att en användare omdirigeras är om formulärautentiseringsbegäran har upphört att gälla. Autentiseringsbegäran för formulär kan nås på två sätt. Det första scenariot inträffar om du använder absolut utgångsdatum. Med absolut utgång går autentiseringsbiljetten ut när förfallotiden går ut. Du kan till exempel ange ett utgångsdatum på 20 minuter och en användare besöker webbplatsen kl. 14:00. Användaren omdirigeras till inloggningssidan om användaren besöker webbplatsen efter 14:20.

Om du använder skjutbara utgångsdatum är scenariot lite mer komplicerat. Cookien och den resulterande biljetten uppdateras om användaren besöker webbplatsen efter att utgångsdatumet har gått ut. Du kan till exempel ange en förfallotid på 20 minuter med hjälp av skjutbar utgångsdatum. En användare besöker webbplatsen kl. 14:00 och användaren får en cookie som går ut kl. 14:20. Förfallodatumet uppdateras endast om användaren besöker webbplatsen efter 14:10. Om användaren besöker webbplatsen kl. 14:09 uppdateras inte biljetten eftersom halva förfallotiden inte har passerat. Om användaren sedan väntar 12 minuter och besöker webbplatsen kl. 14:21 upphör biljetten att gälla. Användaren omdirigeras till inloggningssidan.

Ett sätt att hantera den här typen av problem är att logga formulärautentiseringscookies och biljettinformation. På så sätt kan du se om cookien togs emot av IIS och vilka värden som finns. Det kan du göra genom att skriva en HttpModule och sedan ansluta modulen till begärans pipeline. Du behöver inte ändra koden för programmet för att få den information du behöver.

Det bifogade exemplet fungerar i Microsoft .NET Framework 1.1 och .NET Framework 2.0 och har kommentarer hela vägen. Exemplet innehåller följande filer:

  • FormsAuthEvents.cs: Klassen som implementerar IHttpModule och binder till den Application_BeginRequest händelsen.

  • FormsAuthInfo.cs: Klassen som hämtar cookien och dekrypterar formulärautentiseringsbegäran. Den kontrollerar även programmets Web.config-fil för att säkerställa att formulärautentisering är aktiverad.

  • FormsAuthConfig.cs: Den klass som läser information från den FormsAuthLogger.config filen.

  • Log.cs: Filen som accepterar en strängbyggare och skriver ut värdena till en loggfil.

  • FormsAuthLogger.config: DEN XML-fil som läse log.cs-filen. Den här filen måste finnas i mappen /bin med det inbyggda DLL-biblioteket. Med filen kan du konfigurera följande:

    • Filtrera efter IP: Du kan filtrera datainsamlingen efter klient-IP. På så sätt kan du bara logga begäranden från en klient som är känd för att återskapa problemet. Det här minskar loggens storlek.

    • Inspelningstyp: Det här anger var filen ska sparas. Standardinställningen är mappen Tillfälliga ASP.NET filer, men du kan spara den var som helst så länge arbetsprocesskontot har möjlighet att skriva till mappen.

Obs! Jag anger en nedladdningslänk för koden som anges i FormsAuthLogger.zip filen.

Jag ska peka ut de viktigaste områdena här:

  1. Skapa en klass som implementerar IHttpModule-gränssnittet.

    public class FormsAuthEvents : IHttpModule 
    {
    …code…
    }
  2. Koppla upp händelsen du vill titta på. I det här exemplet använder vi händelsen Application_BeginRequest. På så sätt kan vi undersöka varje begäran och avgöra om den har formulärautentiseringscookien och logga FormsAuthenticationTicket om cookien finns där.

    public void Init(HttpApplication application) 
    {
    //Wire up the BeginRequest event
    application.BeginRequest += (new EventHandler(this.Application_BeginRequest));
    }
  3. Implementera den Application_BeginRequest händelsen.

    private void Application_BeginRequest(Object source, EventArgs e)
    {
       …code to log the ticket…
    }
    
  4. Hämta formulärautentiseringscookien och dekryptera den sedan.

  5. Logga värdena. Jag rekommenderar att du loggar in följande utöver formulärinformationen. På så sätt kan du anpassa formulärautentiseringsinformationen till IIS-loggarna om det behövs:

    • Datum: Låter dig se när begäran kom in.

    • RequestType: Visar om begäran är en Hämta eller ett inlägg.

    • URL: Visar mönstret för begäranden som leder fram till problemet.

    • Hänvisningsadress

    • ClientIP: Kopplar förfrågningarna till en viss klient.

Behöver du mer hjälp?

Vill du ha fler alternativ?

Utforska prenumerationsförmåner, bläddra bland utbildningskurser, lär dig hur du skyddar din enhet med mera.

Communities hjälper dig att ställa och svara på frågor, ge feedback och få råd från experter med rika kunskaper.

Hade du nytta av den här informationen?

Hur nöjd är du med språkkvaliteten?
Vad påverkade din upplevelse?
Genom att trycka på skicka, kommer din feedback att användas för att förbättra Microsofts produkter och tjänster. IT-administratören kan samla in denna data. Sekretesspolicy.

Tack för din feedback!

×