Logg på med Microsoft
Logg på, eller opprett en konto.
Hei,
Velg en annen konto.
Du har flere kontoer
Velg kontoen du vil logge på med.

ASP .NET-støtte for talekolonne

Feilsøke skjemagodkjenning

Velkommen til ASP.NET Support Voice-kolonne! Jeg heter Jerry Orman. Jeg har vært hos Microsoft i over fem år, og har brukt mesteparten av tiden på nettrelaterte teknologier som Microsoft FrontPage og de nye Microsoft SharePoint-teknologiene. Jeg har brukt det siste året på å jobbe med Microsoft ASP.NET som kundestøttetekniker. Denne måneden skal jeg forklare hvordan jeg feilsøker skjemagodkjenning i Microsoft ASP.NET.

Feilsøke skjemagodkjenning

Når du bruker skjemagodkjenning i et ASP.NET program, kan det hende det er nødvendig å feilsøke et problem som oppstår når brukeren omdirigeres tilfeldig til påloggingssiden. I en ideell verden ville dette problemet oppstå på en måte som gjør at du enkelt kan legge ved en feilsøkingsfeil og fange opp problemet. I produksjonsmiljøer er dette imidlertid sjeldent tilfelle. Hvis du vil feilsøke et tilfeldig problem som dette, må du logge informasjon relatert til problemet, slik at du kan begrense grunnårsaken.

I denne kolonnen dekker vi kort formsgodkjenningskonseptet. Vi skal deretter se på hvilke scenarioer som fører til at en bruker blir omdirigert til påloggingssiden, og hvordan de registrerer data som er relevante for å isolere problemet. Vi tar også for oss hvordan du implementerer et IHttpModule-grensesnitt for å logge informasjonen om skjemagodkjenning.

Oversikt over skjemagodkjenning

Når en bruker godkjenner et nettsted ved hjelp av skjemagodkjenning, oppretter serveren en informasjonskapsel. Verdien til informasjonskapselen er en kryptert skjemagodkjenningsbillett. Informasjonskapselen sendes til serveren på hver forespørsel til programmet, og FormsAuthenticationModule-klassen dekrypterer informasjonskapselverdien og bestemmer om brukeren er gyldig eller ikke.

Som standard legges FormsAuthenticationModule-klassen til i Machine.config-filen. FormsAuthenticationModule-klassen administrerer FormsAuthentication-prosessen.

Følgende er en oppføring fra Machine.config-filen:

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

Den generelle HTTP-trafikken for godkjenning ved hjelp av skjemagodkjenning ser omtrent slik ut:

  1. Klienten sender en HTTP GET til Default.aspx. Ingen informasjonskapsel for skjemagodkjenning er sendt.

  2. Serveren sender et 302-svar (omadressering) til Login.aspx.

  3. Klienten sender et HTTP POST til Login.aspx. Den inneholder påloggingsinformasjonen.

  4. Serveren sender et 302-svar (omadressering) til Default.aspx. Informasjonskapselen for skjemagodkjenning er inkludert.

  5. Klienten sender en HTTP GET til Default.aspx. Dette inkluderer informasjonskapselen for skjemagodkjenning.

Hvis du vil ha mer informasjon om implementering og bruk av skjemagodkjenning, kan du gå til følgende MSDN-webområder:

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).aspxHvis du vil ha mer informasjon om godkjenningsinformasjonskapsler for deling av skjemaer, kan du gå til følgende ASP.NET webområde:

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

Årsaker til at en bruker kan bli omdirigert til påloggingssiden

Informasjonskapselen for skjemagodkjenning går tapt

Scenario 1


I dette scenarioet logger en bruker seg på webområdet. På et tidspunkt sender klienten en forespørsel til serveren, og
FormsAuthenticationModule-klassen mottar ikke informasjonskapselen. Du kan finne ut om en brukerforespørsel ikke inneholder informasjonskapselen ved å aktivere informasjonskapsellogging i Microsoft Internet Information Services (IIS). Gjør dette ved å følge disse trinnene:

  1. Åpne IIS Microsoft Management Console (MMC).

  2. Høyreklikk webområdet, og klikk
    deretterEgenskaper.

  3. Klikk kategorien Webområde , og klikk deretter Aktiver logging.

  4. Kontroller at loggformatet er W3C Extended Log File Format.

  5. Klikk Egenskaper.

  6. Klikk avansert-fanen, og klikk
    deretterUtvidede egenskaper.

  7. Merk av for Informasjonskapsel(cs(Informasjonskapsel)) under Utvidede egenskaper, og avmerkingsboksen Referer (cs(Referer)).

Når dette problemet oppstår, må du finne ut hvilken klient som hadde problemet og klientens IP-adresse. Filtrer IIS-loggen på klientens IP-adresse, og vis <informasjonskapsel> kolonnen.

Obs! Du kan bruke Log Parser til å analysere IIS-loggene. Hvis du vil laste ned Log Parser, kan du gå til følgende Microsoft-webområde:

http://www.microsoft.com/download/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07 Når du har listen over forespørsler fra den bestemte brukeren, søker du etter forespørslene til påloggingssiden. Du vet at de ble omdirigert til denne siden, og du vil se forespørslene før omadresseringen oppstod. Hvis du ser noe som ligner på følgende, har klienten enten ikke sendt informasjonskapselen eller informasjonskapselen ble fjernet på nettverket mellom klienten og serveren.

Dette er den første påloggingen.

Metoden

Siden

Svar

Informasjonskapsler

/Default.aspx

302 (omdirigering)

Ingen informasjonskapsler

/Login.aspx

200 (Vellykket)

Ingen informasjonskapsler

INNLEGG

/Login.aspx

302 (omdirigering)

Ingen informasjonskapsler

/Default.aspx

200 (Vellykket)

. ASPXAUTH

/SomePage.aspx

302 (omdirigering)

Nei. ASPXAUTH-informasjonskapsel

Dette er andre forespørsler, etterfulgt av en forespørsel til en side på nettstedet uten . ASPXAUTH-informasjonskapsel.

Metoden

Siden

Svar

Informasjonskapsler

/SomePage.aspx

302 (omdirigering)

Nei. ASPXAUTH-informasjonskapsel

/Login.aspx

200 (Vellykket)

Nei. ASPXAUTH-informasjonskapsel

INNLEGG

/Login.aspx

302 (omdirigering)

Nei. ASPXAUTH-informasjonskapsel

/SomePage.aspx

200 (Vellykket)

. ASPXAUTH


Obs! Den første forespørselen fra denne brukeren har sannsynligvis ikke en informasjonskapsel for skjemagodkjenning med mindre du oppretter en fast informasjonskapsel. IIS-loggen viser deg bare informasjonskapslene som ble mottatt i forespørselen. Den første forespørselen om å få informasjonskapselen for skjemagodkjenning vil være på forespørsel etter et vellykket påloggingsforsøk.

Scenario 2


Informasjonskapselen for skjemagodkjenning kan også gå tapt når klientens informasjonskapselgrense overskrides. I Microsoft Internet Explorer er det en grense på 20 informasjonskapsler. Når den 20. informasjonskapselen er opprettet på klienten, fjernes tidligere informasjonskapsler fra klientens samling. Hvis . ASPXAUTH-informasjonskapsel fjernes, brukeren blir omdirigert til påloggingssiden når neste forespørsel behandles.

Du kan feilsøke disse to scenariene på samme måte. Se på forespørselen like før omadresseringen til påloggingssiden. Hvis forespørselen til denne siden genererer informasjonskapsler, vil dette være noe å undersøke.

Du kan bruke Fiddler til å vise HTTP-overskriftene som sendes til klienten. Når du registrerer trafikken, dobbeltklikker du en forespørsel, og deretter klikker du Overskrifter for å se toppteksten Set-Cookie. Hvis du sporer en vellykket pålogging, ser du toppteksten Set-Cookie i svaret på en vellykket pålogging.

Hvis du vil laste ned Fiddler, kan du gå til følgende Fiddler-webområde:

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

Scenario 3


Når forespørselen forlater klienten, finnes det ulike lag som kan påvirke pakkene som sendes. Hvis du vil finne ut om en nettverksenhet fjerner informasjonskapselen, må du registrere en nettverkssporing på klienten og serveren, og deretter se i brødteksten i forespørselen om informasjonskapselen. Du vil se på klientforespørselen for å sikre at informasjonskapselen ble sendt, og kontrollere serversporingen for å sikre at serveren mottok informasjonskapselen.

Klientforespørsel

Dette er en GET-forespørsel etter at brukeren er godkjent. Informasjonen om godkjenningsbilletten for skjemaer er uthevet i blått. Dette bekrefter at informasjonskapselinformasjonen forlot klienten. Når du bruker et nettverksopptaksverktøy, for eksempel Netmon, ser du trafikken som faktisk gikk gjennom adapteren.

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

Serversideforespørsel

Når du ser på forespørselen som nådde serveren, må du kontrollere at serveren har mottatt den samme informasjonen som klienten sendte. Hvis serveren ikke mottok den samme informasjonen, må du undersøke andre enheter på nettverket for å finne ut hvor informasjonskapselen ble fjernet.

Obs! Det har også vært forekomster av ISAPI-filtre som fjerner informasjonskapsler. Hvis du bekrefter at webserveren mottok informasjonskapselen, men informasjonskapselen ikke er oppført i IIS-loggene, kontrollerer du ISAPI-filtrene. Du må kanskje fjerne filtrene for å se om problemet er løst.

Skjemagodkjenningsbilletten blir tidsavbrutt

Den andre vanlige årsaken til at en bruker omdirigeres, er hvis skjemagodkjenningsbilletten er utløpt. Godkjenningsbilletten for skjemaer kan bli tidsavbrutt på to måter. Det første scenarioet oppstår hvis du bruker absolutt utløpsdato. Med absolutt utløp utløper godkjenningsbilletten når utløpstiden utløper. Du angir for eksempel en utløpsdato på 20 minutter, og en bruker besøker nettstedet kl. 14:00. Brukeren blir omdirigert til påloggingssiden hvis brukeren besøker nettstedet etter kl. 14:20.

Hvis du bruker glidende utløp, er scenarioet litt mer komplisert. Informasjonskapselen og den resulterende billetten oppdateres hvis brukeren besøker nettstedet etter at utløpstiden er utløpt. Du angir for eksempel en utløpsdato på 20 minutter ved hjelp av glidende utløp. En bruker besøker nettstedet kl. 14:00, og brukeren mottar en informasjonskapsel som er satt til å utløpe kl. 14:20. Utløpsdatoen oppdateres bare hvis brukeren besøker nettstedet etter kl. 14:10. Hvis brukeren besøker nettstedet kl. 14:09, oppdateres ikke billetten fordi halvparten av utløpstiden ikke er passert. Hvis brukeren deretter venter 12 minutter, går du til nettstedet kl. 14:21, vil billetten utløpe. Brukeren omdirigeres til påloggingssiden.

Én måte å nærme seg denne typen problem på, er å logge informasjonskapselen for skjemagodkjenning og billettinformasjon. På denne måten kan du se om informasjonskapselen ble mottatt av IIS og hva verdiene er. Du kan gjøre dette ved å skrive en HttpModule og deretter koble modulen til forespørselsforløpet. Du trenger ikke å endre programmets kode for å få informasjonen du trenger.

Det vedlagte eksemplet fungerer i Microsoft .NET Framework 1.1 og .NET Framework 2.0 og har kommentarer overalt. Eksemplet inneholder følgende filer:

  • FormsAuthEvents.cs: Klassen som implementerer IHttpModule og knytter seg til Application_BeginRequest-hendelsen.

  • FormsAuthInfo.cs: Klassen som henter informasjonskapselen og dekrypterer skjemagodkjenningsbilletten. Den kontrollerer også programmets Web.config-fil for å sikre at skjemagodkjenning er aktivert.

  • FormsAuthConfig.cs: Klassen som leser informasjon fra FormsAuthLogger.config-filen.

  • Log.cs: Filen som godtar en strengbygger og skriver verdiene ut til en loggfil.

  • FormsAuthLogger.config: XML-filen som leses av Log.cs-filen. Denne filen må være i /bin-mappen med den innebygde DLL-filen. Filen lar deg konfigurere følgende:

    • Filtrer etter IP: Du kan filtrere henting av data etter klient-IP. På denne måten kan du logge bare forespørsler fra en klient som er kjent for å gjenskape problemet. Dette reduserer størrelsen på loggen.

    • Innspillingstype: Dette angir hvor filen skal lagres. Standardinnstillingen er mappen Midlertidige ASP.NET Filer, men du kan lagre dette hvor som helst så lenge arbeidsprosesskontoen har mulighet til å skrive til mappen.

Vær oppmerksom på at jeg angir en nedlastingskobling for koden som er angitt i FormsAuthLogger.zip-filen.

Jeg skal peke på hovedområdene her:

  1. Opprett en klasse som implementerer IHttpModule-grensesnittet.

    public class FormsAuthEvents : IHttpModule 
    {
    …code…
    }
  2. Før opp hendelsen du vil se på. I dette eksemplet bruker vi Application_BeginRequest-hendelsen. På denne måten kan vi undersøke hver forespørsel og avgjøre om den har informasjonskapselen for skjemagodkjenning og logge FormsAuthenticationTicket hvis informasjonskapselen er der.

    public void Init(HttpApplication application) 
    {
    //Wire up the BeginRequest event
    application.BeginRequest += (new EventHandler(this.Application_BeginRequest));
    }
  3. Implementer Application_BeginRequest-hendelsen.

    private void Application_BeginRequest(Object source, EventArgs e)
    {
       …code to log the ticket…
    }
    
  4. Hent informasjonskapselen for skjemagodkjenning, og dekrypter den.

  5. Logger verdiene. Jeg anbefaler at du logger følgende i tillegg til skjemainformasjonen. Dette vil hjelpe deg med å stille opp godkjenningsinformasjonen for skjemaer i IIS-loggene, om nødvendig:

    • Dato: Lar deg se når forespørselen kom inn.

    • RequestType: Viser om forespørselen er en Hent eller et innlegg.

    • NETTADRESSE: Viser mønsteret for forespørsler som fører opp til problemet.

    • Referrer

    • Klienttips: Knytter forespørslene til en bestemt klient.

Trenger du mer hjelp?

Vil du ha flere alternativer?

Utforsk abonnementsfordeler, bla gjennom opplæringskurs, finn ut hvordan du sikrer enheten og mer.

Fellesskap hjelper deg med å stille og svare på spørsmål, gi tilbakemelding og høre fra eksperter med stor kunnskap.

Var denne informasjonen nyttig?

Hvor fornøyd er du med språkkvaliteten?
Hva påvirket opplevelsen din?
Når du trykker på Send inn, blir tilbakemeldingen brukt til å forbedre Microsoft-produkter og -tjenester. IT-administratoren kan samle inn disse dataene. Personvernerklæring.

Takk for tilbakemeldingen!

×