DetailPage-MSS-KB

Microsoft Knowledge Base

Identificativo articolo: 910439 - Ultima modifica: giovedì 30 maggio 2013 - Revisione: 2.0

 
ASP .NET supporto vocale colonna

Per personalizzare questa colonna in base alle esigenze, desideriamo invitati a inviare le proprie idee sugli argomenti di interesse e sui problemi che si desiderano visualizzare la soluzione nei futuri articoli della Knowledge Base e Support Voice. È possibile inviare idee e commenti e suggerimenti tramite il Richiesti (http://support.microsoft.com/common/survey.aspx?scid=sw;en;1176&p0=&p1=&p2=&p3=&p4=) modulo. È inoltre disponibile un collegamento al modulo nella parte inferiore della colonna.

In questa pagina

Benvenuti alla colonna di ASP.NET Support Voice. Il mio nome è Jerry Messina. I sono state Microsoft per oltre cinque anni e hanno trascorso la maggior parte di personale ora è incentrata su tecnologie correlate al Web come Microsoft FrontPage e nuove tecnologie Microsoft SharePoint. È stata dedicata l'ultimo anno con Microsoft ASP.NET come servizio di supporto tecnico. Questo mese in Support Voice colonna, devo spiegare come risolvere i problemi di autenticazione basata su form in Microsoft ASP.NET.

Quando si utilizza l'autenticazione basata su form in un'applicazione ASP.NET, potrebbe essere necessario risolvere un problema che si verifica quando l'utente è in modo casuale viene reindirizzato alla pagina di accesso. In un mondo ideale, questa problema si verificherà in modo che consente di associare facilmente un individuare il problema e debugger. Negli ambienti di produzione, tuttavia, questo è raramente il caso. Per risolvere un problema casuale come questo, è necessario registrare le informazioni relative al problema in modo che è possibile restringere la radice causa.

In questo articolo, esamineremo brevemente il Concetto di autenticazione form. Quindi ci occuperemo in quali scenari portare a un utente viene reindirizzato alla pagina di accesso e su come acquisire i dati che è rilevante per isolare il problema. Verrà inoltre illustrata l'implementazione di un'interfaccia IHttpModule per registrare le informazioni di autenticazione basata su form.

Forms Authentication Overview

Quando un utente viene autenticato in un sito Web utilizzando l'autenticazione basata su form, il server crea un cookie. Il valore del cookie è un ticket di autenticazione form crittografato. Il cookie viene passato al server ad ogni richiesta di l'applicazione e la classe FormsAuthenticationModule decrittografa il valore del cookie e Determina se l'utente è valido o meno.

Per impostazione predefinita, la classe FormsAuthenticationModule classe verrà aggiunta nel file Machine. config. La classe FormsAuthenticationModule gestisce il processo di FormsAuthentication.

Di seguito è una voce dal file Machine. config:
<httpModule>
     …other modules…
     <add name="FormsAuthentication"
         type="System.Web.Security.FormsAuthenticationModule" />
     …other modules…
</httpModule>
Il traffico HTTP generale per l'autenticazione utilizzando l'autenticazione basata su form è simile al seguente:
  1. Il client invia un verbo HTTP GET a default. aspx. Non viene inviato alcun cookie di autenticazione form.
  2. Il server invia una risposta 302 (reindirizzamento) a Login. aspx.
  3. Il client invia un HTTP POST al login. aspx. Include le informazioni di accesso.
  4. Il server invia una risposta 302 (reindirizzamento) per default. aspx. Il cookie di autenticazione form è incluso.
  5. Il client invia un verbo HTTP GET a default. aspx. Ciò include il cookie di autenticazione form.
Per ulteriori informazioni sull'implementazione e utilizzo autenticazione basata su form, visitare i seguenti siti Web MSDN:
http://msdn2.microsoft.com/en-us/library/7t6b43z4.aspx (http://msdn2.microsoft.com/en-us/library/7t6b43z4.aspx)
aspx (vs.71) http://msdn2.microsoft.com/en-us/library/System.Web.Security.FormsAuthentication (http://msdn2.microsoft.com/en-us/library/system.web.security.formsauthentication(vs.71).aspx)
aspx (vs.71) http://msdn2.microsoft.com/en-us/library/System.Web.Security.FormsAuthenticationTicket (http://msdn2.microsoft.com/en-us/library/system.web.security.formsauthenticationticket(vs.71).aspx)
Per ulteriori informazioni sulla condivisione del cookie di autenticazione form, visitare il seguente sito Web ASP.NET:
http://QuickStarts.ASP.NET/QuickStartv20/ASPNET/doc/Security/FormsAuth.aspx (http://quickstarts.asp.net/QuickStartv20/aspnet/doc/security/formsauth.aspx)

Motivi che un utente può essere reindirizzato alla pagina di accesso

Il cookie di autenticazione form viene perso

Scenario 1

In questo scenario, l'utente accede al sito Web. A un certo punto, il client invia una richiesta al server e Classe FormsAuthenticationModule non riceve il cookie. È possibile determinare se una richiesta dell'utente non contiene il cookie mediante l'attivazione dei cookie registrazione in Microsoft Internet Information Services (IIS). A tale scopo, attenersi alla seguente procedura:
  1. Aprire Microsoft Management Console (MMC) di IIS.
  2. Il pulsante destro del sito Web e quindi fare clic suProprietà.
  3. Scegliere il Sito Web scheda e quindi fare clic su Attiva Registrazione.
  4. Assicurarsi che sia il formato di registro W3C Extended Log File Formato.
  5. Fare clic Proprietà.
  6. Scegliere il Avanzate scheda e quindi fare clic suProprietà estese.
  7. Nella casella di gruppo Proprietà estese, fare clic per selezionare il Cookie(cs(cookie)) casella di controllo e il Referer (cs(Referer)) .
Una volta che si verifica questo problema, determinare quale client ha il problema e l'indirizzo IP del client. Filtrare il registro IIS all'indirizzo IP del client, e visualizzare il cookie> colonna.

Nota. Log Parser consente di analizzare i registri di IIS. Per scaricare il Log Parser, visitare il seguente sito Web Microsoft:
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)
Dopo aver ottenuto l'elenco delle richieste da questo specifico utente, cercare le richieste alla pagina di accesso. Si è certi di che essere trasferiti a questa pagina e si desidera visualizzare le richieste prima di si è verificato il reindirizzamento. Se un codice simile al seguente, il client uno non ha inviato che il cookie o il cookie è stato rimosso in rete tra il client e server.

Questo è l'accesso iniziale.
Riduci questa tabellaEspandi questa tabella
MetodoPaginaRispostaCookie
GET/Default.aspx302 (Reindirizzamento)No Cookie
GET/Login.aspx200 (Esito positivo)No Cookie
POST/Login.aspx302 (Reindirizzamento)No Cookie
GET/Default.aspx200 (Operazione riuscita).ASPXAUTH
GET/SomePage.aspx302 (Reindirizzamento)No .Cookie ASPXAUTH
Si tratta di altre richieste, seguite da una richiesta a una pagina sul sito senza il.Cookie ASPXAUTH.
Riduci questa tabellaEspandi questa tabella
MetodoPaginaRispostaCookie
GET/SomePage.aspx302 (Reindirizzamento)No .Cookie ASPXAUTH
GET/Login.aspx200 (Esito positivo)No .Cookie ASPXAUTH
POST/Login.aspx302 (Reindirizzamento)No .Cookie ASPXAUTH
GET/SomePage.aspx200 (Operazione riuscita).ASPXAUTH

Nota. La prima richiesta dall'utente non può disporre di un form cookie di autenticazione a meno che non si crea un cookie persistente. Nel Registro di IIS solo mostrerà i cookie che sono stati ricevuti nella richiesta. La richiesta prima che il cookie di autenticazione form sarà su richiesta dopo una corretta tentativo di accesso.
Scenario 2

Il cookie di autenticazione form può essere perso anche quando viene superato il limite di cookie del client. In Microsoft Internet Explorer, non esiste un limite di 20 cookie. Al termine di 20 cookie creato sul client, i cookie precedenti vengono rimossi del client insieme. Se il.Cookie ASPXAUTH viene rimosso, l'utente verrà reindirizzato alla pagina di accesso quando viene elaborata la richiesta successiva.

Allo stesso modo, è possibile risolvere questi due scenari. Cerca solo su richiesta prima del reindirizzamento alla pagina di accesso. Se si genera la richiesta a questa pagina i cookie, questo è qualcosa da analizzare.

Per ulteriori informazioni, fare clic sul numero dell'articolo riportato di seguito per visualizzare l'articolo della Microsoft Knowledge Base:
306070  (http://support.microsoft.com/kb/306070/ ) Limiti di numeri e dimensioni di un cookie in Internet Explorer

È possibile utilizzare Fiddler per visualizzare le intestazioni HTTP che vengono inviati al client. Dopo aver acquisito il traffico, fare doppio clic su una richiesta, e quindi fare clic su Intestazioni Per visualizzare l'intestazione Set-Cookie. Se traccia un accesso con esito positivo, verrà visualizzata l'intestazione Set-Cookie nella risposta di un accesso con esito positivo.

Per scaricare Fiddler, visitare il seguente sito Web Fiddler:
http://www.fiddlertool.com/Fiddler/ (http://www.fiddlertool.com/fiddler/)
Scenario 3

Dopo la richiesta lasci il client, esistono vari livelli che può influenzare i pacchetti vengono inviati. Per determinare se è una periferica di rete rimozione del cookie, è necessario acquisire una traccia di rete sul client e server, e quindi cercare nel corpo della richiesta per il cookie. Si desidera Esaminare la richiesta del client per assicurarsi che il cookie è stato inviato e il server traccia per assicurarsi che il server ha ricevuto il cookie.

Richiesta del client

Si tratta di una richiesta GET dopo che l'utente è stato autenticato. Il informazioni sul ticket di autenticazione form viene evidenziati in blu. Questo conferma che le informazioni del cookie lasciato il client. Quando si utilizza un'acquisizione di rete lo strumento, come Netmon, è possibile visualizzare il traffico è diventato effettivamente tramite il adattatore.
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
Richiesta sul lato server

Quando si esamina la richiesta raggiunge il server è si desidera assicurarsi che il server ha ricevuto le stesse informazioni che il client inviati. Se il server non ha ricevuto le stesse informazioni, è necessario esaminare altre periferiche sul rete per determinare quale il cookie è stato rimosso.

Nota. Sono stati inoltre le istanze dei filtri ISAPI rimozione dei cookie. Se si conferma che il server Web ha ricevuto il cookie, ma non è elencato il cookie nei registri di IIS, controllare i filtri ISAPI. Potrebbe essere necessario rimuovere i filtri per vedere se il problema viene risolto.

Timeout del ticket di autenticazione form

È l'altra causa comune per un utente venga reindirizzato se il autenticazione basata su form ticket è scaduto. L'autenticazione basata su form ticket possono scadere in due modi. Il primo scenario si verifica se si utilizza scadenza assoluta. Con scadenza assoluta, il ticket di autenticazione scade quando il termine dell'orario di scadenza. Ad esempio, è possibile impostare una scadenza di 20 minuti e un utente visita il sito alle 2:00 PM. L'utente verrà reindirizzato alla pagina di accesso se l'utente visita il sito dopo 14:20:00.

Se si utilizza la scadenza, il scenario è un po' più complicato. Il cookie e il ticket risultante sono aggiornato se l'utente visita il sito dopo la scadenza è scaduto a metà. Ad esempio, è possibile impostare una scadenza di 20 minuti utilizzando la scadenza. Un utente visita il sito alle 2:00 PM e l'utente riceve un cookie è impostato alle 14:20:00. La scadenza viene aggiornata solo se l'utente visita il sito dopo 2:10 PM. Se l'utente visita il sito alle 2:09 PM, il ticket non è aggiornato perché la metà dei non è trascorso il tempo di scadenza. Se l'utente attende 12 minuti, visita il sito alle 2:21 PM il ticket verrà scaduto. L'utente viene reindirizzato all'account di accesso pagina.

Per affrontare questo tipo di problema, è possibile registrare i moduli informazioni cookie e ticket di autenticazione. In questo modo, è possibile vedere il cookie è stato ricevuto da IIS e quali sono i valori. È possibile eseguire mediante la scrittura un HttpModulee quindi collegare tale modulo nella pipeline delle richieste. Non sarà necessario modificare il codice dell'applicazione per ottenere le informazioni è necessario.

L'esempio allegato funziona in di Microsoft.NET Framework 1.1 e 2.0 di.NET Framework e ha commenti all'interno di. L'esempio include i seguenti file:
  • FormsAuthEvents.cs: La classe che implementa IHttpModule e collega nell'evento Application_BeginRequest .
  • FormsAuthInfo.cs: La classe che consente di recuperare il cookie e Consente di decrittografare il ticket di autenticazione form. Inoltre, controlla l'applicazione File Web. config per assicurarsi che autenticazione basata su form è abilitata.
  • FormsAuthConfig.cs: La classe che legge le informazioni dal File FormsAuthLogger.config.
  • Log.cs: Il file che accetta un oggetto stringbuilder e scrive i valori in un file di registro.
  • FormsAuthLogger.config: Il file XML che viene letto dal file Log.cs. Questo file deve trovarsi nella cartella /bin con la DLL compilata. Il file consente di configurare le seguenti operazioni:
    • Filtro da IP: È possibile filtrare l'acquisizione dei dati IP client. In questo modo, è possibile registrare solo richieste da un client che è noto che riprodurre il problema. Questo riduce la dimensione del registro.
    • Tipo di acquisizione: Specifica se salvare il file. Il valore predefinito è la cartella file temporanei di ASP.NET, ma è possibile salvare questo in qualsiasi punto purché l'account del processo di lavoro è in grado di scrivere il cartella.
Nota. Si prenda un collegamento di download per il codice fornito nel File FormsAuthLogger.zip.

È necessario sottolineare le principali aree:
  1. Creare una classe che implementa l'interfaccia IHttpModule .
    public class FormsAuthEvents : IHttpModule 
    {
    		…code…
    }
  2. Associare l'evento che si desidera esaminare. In questo esempio, Utilizziamo l'evento Application_BeginRequest . In questo modo possiamo esaminare ogni richiesta e determinare se ha il cookie di autenticazione form e il registro FormsAuthenticationTicket se il cookie esiste.
    public void Init(HttpApplication application) 
    {
    	//Wire up the BeginRequest event
    	application.BeginRequest += (new EventHandler(this.Application_BeginRequest));
    }
  3. Implementare l'evento Application_BeginRequest .
    private void Application_BeginRequest(Object source, EventArgs e)
    {	
       …code to log the ticket…
    }
    
  4. Recuperare il cookie di autenticazione form e decrittografare esso.
  5. Registrare i valori. Si consiglia di registrazione riportato di seguito in inoltre le informazioni del form. Ciò consente di allineare i moduli informazioni di autenticazione per i registri di IIS, se necessario:
    • Data: Consente di vedere quando la richiesta proviene in.
    • RequestType: Indica se la richiesta è Get oppure a Post.
    • URL: Viene illustrato il modello di richieste che hanno contribuito al problema.
    • Provenienza
    • ClientIP: Collega di richieste a un oggetto specifico client.

Come sempre, non esitate a inviare idee sugli argomenti desiderati risolto in future colonne o nella Knowledge Base utilizzando il Richiesti (http://support.microsoft.com/common/survey.aspx?scid=sw;en;1176&p0=&p1=&p2=&p3=&p4=) modulo.

Le informazioni in questo articolo si applicano a:
  • Microsoft ASP.NET 1.1
  • Microsoft ASP.NET 1.0
  • Microsoft ASP.NET 2.0
Chiavi: 
kbtshoot kbiis kbcode kbasp kbmt KB910439 KbMtit
Traduzione automatica articoliTraduzione automatica articoli
IMPORTANTE: il presente articolo è stato tradotto tramite un software di traduzione automatica di Microsoft ed eventualmente revisionato dalla community Microsoft tramite la tecnologia CTF (Community Translation Framework) o da un traduttore professionista. Microsoft offre articoli tradotti manualmente e altri tradotti automaticamente e rivisti dalla community con l’obiettivo di consentire all'utente di accedere a tutti gli articoli della Knowledge Base nella propria lingua. Tuttavia, un articolo tradotto automaticamente, anche se rivisto dalla community, non sempre è perfetto. Potrebbe contenere errori di vocabolario, di sintassi o di grammatica. Microsoft declina ogni responsabilità per imprecisioni, errori o danni causati da una traduzione sbagliata o dal relativo utilizzo da parte dei clienti. Microsoft aggiorna frequentemente il software e gli strumenti di traduzione automatica per continuare a migliorare la qualità della traduzione.
Clicca qui per visualizzare la versione originale in inglese dell’articolo: 910439  (http://support.microsoft.com/kb/910439/en-us/ )
LE INFORMAZIONI CONTENUTE NELLA MICROSOFT KNOWLEDGE BASE SONO FORNITE SENZA GARANZIA DI ALCUN TIPO, IMPLICITA OD ESPLICITA, COMPRESA QUELLA RIGUARDO ALLA COMMERCIALIZZAZIONE E/O COMPATIBILITA' IN IMPIEGHI PARTICOLARI. L'UTENTE SI ASSUME L'INTERA RESPONSABILITA' PER L'UTILIZZO DI QUESTE INFORMAZIONI. IN NESSUN CASO MICROSOFT CORPORATION E I SUOI FORNITORI SI RENDONO RESPONSABILI PER DANNI DIRETTI, INDIRETTI O ACCIDENTALI CHE POSSANO PROVOCARE PERDITA DI DENARO O DI DATI, ANCHE SE MICROSOFT O I SUOI FORNITORI FOSSERO STATI AVVISATI. IL DOCUMENTO PUO' ESSERE COPIATO E DISTRIBUITO ALLE SEGUENTI CONDIZIONI: 1) IL TESTO DEVE ESSERE COPIATO INTEGRALMENTE E TUTTE LE PAGINE DEVONO ESSERE INCLUSE. 2) I PROGRAMMI SE PRESENTI, DEVONO ESSERE COPIATI SENZA MODIFICHE, 3) IL DOCUMENTO DEVE ESSERE DISTRIBUITO INTERAMENTE IN OGNI SUA PARTE. 4) IL DOCUMENTO NON PUO' ESSERE DISTRIBUITO A SCOPO DI LUCRO.
Condividi
Altre opzioni per il supporto
Forum del supporto di Microsoft Community
Contattaci direttamente
Ricerca di un partner certificato Microsoft
Microsoft Store