Domanda

Qual è la causa di questa eccezione in ASP.NET? Ovviamente è un'eccezione viewstate, ma non riesco a riprodurre l'errore sulla pagina che genera l'eccezione (un semplice modulo di due TextBox con un pulsante e collegamenti di navigazione).

FWIW, non sto gestendo una web farm.

eccezione

  

Messaggio di errore: impossibile convalidare   i dati.

     

Origine errore: System.Web

     

Sito di destinazione dell'errore: byte []   GetDecodedData (Byte [], Byte [], Int32,   Int32, Int32 ByRef)

Pubblica dati

  

ViewState:

     

/ wEPDwULLTE4NTUyODcyMTFkZF96FHxDUAHIY3NOAMRJYZ + CKsnB

     

EVENTVALIDATION:

     

/ wEWBAK + 8ZzHAgKOhZRcApDF79ECAoLch4YMeQ2ayv / Gi76znHooiRyBFrWtwyg =

Traccia stack eccezioni

   at System.Web.UI.ViewStateException.ThrowError(Exception inner, String persistedState, String errorPageMessage, Boolean macValidationError)
   at System.Web.UI.ObjectStateFormatter.Deserialize(String inputString)
   at System.Web.UI.ObjectStateFormatter.System.Web.UI.IStateFormatter.Deserialize(String serializedState)
   at System.Web.UI.Util.DeserializeWithAssert(IStateFormatter formatter, String serializedState)
   at System.Web.UI.HiddenFieldPageStatePersister.Load()
   at System.Web.UI.Page.LoadPageStateFromPersistenceMedium()
   at System.Web.UI.Page.LoadAllState()
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
   at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
   at System.Web.UI.Page.ProcessRequest()
   at System.Web.UI.Page.ProcessRequestWithNoAssert(HttpContext context)
   at System.Web.UI.Page.ProcessRequest(HttpContext context)
   at ASP.default_aspx.ProcessRequest(HttpContext context)
   at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

~ William Riley-Land

È stato utile?

Soluzione

La causa più probabile di questo errore è quando un postback viene arrestato prima che tutti i carichi di viewstate vengano caricati (l'utente prema i pulsanti stop o back), il viewstate non riuscirà a convalidare e generare l'errore.

Altre potenziali cause:

  • Un pool di applicazioni che ricicla tra il momento in cui il viewstate è stato generato e il momento in cui l'utente lo registra nuovamente sul server (improbabile).
  • Una web farm in cui i machineKeys non sono sincronizzati (non il tuo problema).

Aggiornamento: Articolo di Microsoft sul problema . Oltre a quanto sopra, suggeriscono altre due potenziali cause:

  • Modifica del viewstate mediante firewall / software antivirus
  • Pubblicazione da una pagina aspx a un'altra.

Altri suggerimenti

In .NET 3.5 SP1 la proprietà RenderAllHiddenFieldsAtTopOfForm è stata aggiunta alla configurazione di PagesSection.

web.config

<configuration>

    <system.web>

        <pages renderAllHiddenFieldsAtTopOfForm="true"></pages>

    </system.web>

</configuration>

È interessante notare che il valore predefinito di questo è vero. Quindi, in sostanza, se si utilizza .NET 3.5 SP1, ViewState viene automaticamente visualizzato nella parte superiore del modulo (prima che venga caricato il resto della pagina) eliminando così l'errore ViewState che si sta verificando.

Ho riscontrato il problema con alcune versioni specifiche di Safari 3. La mia soluzione era spostare ViewState nella parte superiore del modulo (ampliato la classe Page e sovrascritto il metodo Render per pre-3.5 SP1 o .Net 3.5 SP1 e versioni successive lo fanno per impostazione predefinita) e per suddividere ViewState in diversi campi anziché in un file mostro. Vedi ViewState Chunking in ASP.NET 2.0 (maxPageStateFieldLength)

Questo strumento online gratuito: http://aspnetresources.com/tools/machineKey genera un elemento machineKey sotto l'elemento system.web nel file web.config. Ecco un esempio di ciò che genera:

<machineKey validationKey="1619AB2FDEE6B943AD5D31DD68B7EBDAB32682A5891481D9403A6A55C4F91A340131CB4F4AD26A686DF5911A6C05CAC89307663656B62BE304EA66605156E9B5" decryptionKey="C9D165260E6A697B2993D45E05BD64386445DE01031B790A60F229F6A2656ECF" validation="SHA1" decryption="AES" />

Quando vedi questo nel tuo web.config, l'errore stesso ha improvvisamente un senso. L'errore che stai ricevendo dice

  

" assicurarsi che la configurazione specifichi lo stesso   validationKey e algoritmo di validazione " ;.

Quando guardi questo elemento machineKey, improvvisamente puoi vedere di cosa sta parlando.


Per " hard coding " questo valore nel tuo web.config, la chiave che asp.net usa per serializzare e deserializzare il tuo viewstate rimane invariata, indipendentemente dal server in una server farm che lo prende. La tua crittografia diventa "portatile", quindi il tuo punto di vista diventa "portatile".

Suppongo anche che forse il server molto simile (non in una fattoria) abbia questo problema se per qualsiasi motivo "dimentica" la chiave che aveva, a causa di un ripristino su qualsiasi livello che lo cancella. Questo è forse il motivo per cui vedi questo errore dopo un periodo di inattività e provi a utilizzare un "vecchio" pagina.

  

" un postback viene arrestato prima che tutti i carichi di viewstate "

Ho avuto questo esatto problema prima, e questa era la causa.

Inizialmente abbiamo disabilitato la proprietà ViewStateMac ( enableViewStateMac = " false " nella direttiva page ) per risolverlo, ma questa non è una vera soluzione al problema e può minacciare l'integrità dei dati. Alla fine l'abbiamo risolto disabilitando il nostro pulsante di invio fino al completo caricamento della pagina e tagliando le dimensioni del nostro viewstate disabilitandolo su alcuni controlli.

Ho trovato la radice di questo problema nel mio sito web e sono finalmente riuscito a risolverlo . Questa non è una risposta diretta alla tua domanda, ma volevo condividere questa piccola informazione.

In passato ho provato di tutto (inclusa la soluzione proposta da Jeffaxe, sopra) ma senza risultati, e non volevo impostare enableViewStateMac = " false " (come menziona Raelshark sopra ) alla mia pagina, perché questo nasconde il problema.

Cosa ha causato il problema nel mio caso? Il problema è stato causato dall'uso del modulo Intelligencia.UrlRewriter (Versione 2.0 RC 1 build 6) in alcune pagine del mio sito web. Stavo usando alcuni link SEO friendly e questo causava l'errore di convalida ViewState. Quando ho usato " normale " link (invece dei link SEO-friendly) il problema è scomparso!

Ho riprodotto il problema alcune volte per assicurarmi che non si trattasse di un falso allarme (utilizzo ASP.NET 3.5).

So che alcuni di voi potrebbero non utilizzare il modulo sopra e continuano a ricevere questo errore, il che implica che la causa è qualcos'altro. Almeno, condividere questa esperienza potrebbe essere utile per alcuni.

Ho ricevuto questo errore quando avevo impostato un tag del modulo sulla mia pagina senza un attributo di azione, e poi nel code-behind ho cambiato l'attributo di azione del modulo in " Action.aspx " ;.

E in JavaScript, ho inviato il modulo (theForm.submit ();)

Penso che nel mio caso si sia trattato di un problema di sicurezza e che non è possibile modificarlo dopo che è già stato impostato sulla pagina ...?

Non sono sicuro che ciò possa aiutare qualcuno, ma la mia soluzione è stata l'esclusione di MachineKey nel mio webconfig per far passare il mio cookie.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top