ASP.NET: impossible de valider les données

https://stackoverflow.com/questions/140303

02-07-2019
|

Question

Quelle est la cause de cette exception dans ASP.NET? Évidemment, il s'agit d'une exception viewstate, mais je ne peux pas reproduire l'erreur sur la page qui lève l'exception (un simple formulaire à deux zones de texte avec un bouton et des liens de navigation).

FWIW, je n’exécute pas de ferme Web.

Exception

Message d'erreur: Impossible à valider   données.

Source de l'erreur: System.Web

Site cible d'erreur: octet []   GetDecodedData (Byte [], Byte [], Int32,   Int32, Int32 ByRef)

Publier des données

VIEWSTATE:

/ wEPDwULLTE4NTUyODcyMTFkZF96FHxDUAHIY3NOAMRJYZ + CKsnB

EVENTVALIDATION:

/ WEWBAK + 8ZzHAgKOhZRcApDF79ECAoLch4YMeQ2ayv / Gi76znHooiRyBFrWtwyg =

Trace de pile d'exception

   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

La solution

La cause la plus probable de cette erreur est lorsqu'une publication est arrêtée avant que tous les états d'affichage soient chargés (l'utilisateur appuie sur les boutons d'arrêt ou de retour), l'échec de l'état d'affichage à valider et renvoyer l'erreur.

Autres causes potentielles:

Un pool d'applications recyclant entre le moment où l'état de visualisation a été généré et le moment où l'utilisateur le publie sur le serveur (improbable).
Une batterie de serveurs Web sur laquelle les machinesKeys ne sont pas synchronisées (pas votre problème).

Mise à jour: article de Microsoft sur le problème . En plus de ce qui précède, ils suggèrent deux autres causes potentielles:

Modification de viewstate par des pare-feu / logiciels anti-virus
Publication d'une page aspx à une autre.

Autres conseils

Dans .NET 3.5 SP1, la propriété RenderAllHiddenFieldsAtTopOfForm a été ajoutée à la configuration de PagesSection.

Config. Web

<configuration>

    <system.web>

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

    </system.web>

</configuration>

Fait intéressant, la valeur par défaut est true. Donc, si vous utilisez .NET 3.5 SP1, le ViewState est automatiquement affiché en haut du formulaire (avant que le reste de la page ne soit chargé), ce qui élimine l'erreur ViewState que vous obtenez.

J'ai rencontré le problème avec certaines versions spécifiques de Safari 3. Ma solution consistait à déplacer ViewState en haut du formulaire (extension de la classe Page et remplacement de la méthode Render pour les versions antérieures à la version 3.5 SP1 ou .Net 3.5. Cela s’effectue par défaut avec SP1 et versions ultérieures, et de scinder le ViewState en plusieurs champs différents au lieu d’un seul fichier monstre. Voir ViewState Chunking dans ASP.NET 2.0 (maxPageStateFieldLength)

Cet outil en ligne gratuit: http://aspnetresources.com/tools/machineKey génère un élément machineKey. sous l'élément system.web dans le fichier web.config. Voici un exemple de ce qu’il génère:

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

Une fois que cela se voit dans votre web.config, l’erreur elle-même prend tout son sens. L'erreur que vous obtenez dit

" assurez-vous que la configuration spécifie la même chose validationKey et algorithme de validation ".

Lorsque vous regardez cet élément machineKey, vous voyez tout à coup de quoi il parle.

Par "codage dur" cette valeur dans votre web.config, la clé utilisée par asp.net pour sérialiser et désérialiser votre état de vue reste la même, quel que soit le serveur dans une batterie de serveurs qui le récupère. Votre cryptage devient "portable", votre état de visualisation devient donc "portable".

Je suppose également que le même serveur (pas dans une batterie de serveurs) a peut-être ce problème si, pour quelque raison que ce soit, il "oublie" la clé dont il disposait, en raison d’une réinitialisation à n’importe quel niveau qui l’efface. C’est peut-être pour cette raison que vous voyez cette erreur après une période d’inactivité et que vous essayez d’utiliser une expression "périmée". page.

"une publication est arrêtée avant que tous les états d'affichage soient chargés"

J'ai déjà eu ce problème avec précision, et c'était la cause

Initialement, nous avons désactivé la propriété ViewStateMac ( enableViewStateMac = "false" dans la directive page ) pour la résoudre, mais il ne s'agit pas d'une solution réelle au problème. peut menacer l'intégrité des données. Nous avons finalement résolu le problème en désactivant notre bouton d'envoi jusqu'à ce que la page soit complètement chargée et en réduisant la taille de notre état d'affichage en le désactivant sur certains contrôles.



	
		
	
	
			 J'ai trouvé la racine de ce problème sur mon site Web et j'ai finalement réussi à le  résoudre . Ce n'est pas une réponse directe à votre question, mais je voulais partager cette petite information. 

 Dans le passé, j'ai tout essayé (y compris la solution proposée par Jeffaxe, ci-dessus), mais sans résultat, et je ne voulais pas définir  enableViewStateMac = "faux"  (comme Raelshark le mentionne ci-dessus ) sur ma page, car cela ne fait que masquer le problème. 

 Quelle est la cause du problème dans mon cas? Le problème était dû à l'utilisation du module  Intelligencia.UrlRewriter  (version 2.0 RC 1 build 6) dans certaines pages de mon site Web. J'utilisais des liens amicaux pour le référencement, ce qui entraînait l'échec de la validation ViewState. Quand j'ai utilisé " normal " liens (au lieu des liens SEO-friendly) le problème a disparu! 

 J'ai reproduit le problème plusieurs fois pour m'assurer qu'il ne s'agissait pas d'une fausse alarme (j'utilise ASP.NET 3.5). 

 Je sais que certains d’entre vous ne peuvent pas utiliser le module ci-dessus et continuent d’obtenir cette erreur, ce qui implique que la cause en est une autre. Au moins, partager cette expérience pourrait être utile à certains. 
	


	
		
	
	
			 J'ai eu cette erreur lorsque j'avais configuré une balise de formulaire sur ma page sans attribut d'action, puis, dans le code-behind, j'avais remplacé l'attribut d'action du formulaire par "Action.aspx". 

 Et en JavaScript, j'ai soumis le formulaire (theForm.submit ();) 

 Je pense que dans mon cas, il s'agissait d'un problème de sécurité et que vous ne pouvez pas le modifier après l'avoir déjà défini sur la page ...? 
	


	
		
	
	
			 Je ne suis pas sûr que cela puisse aider quelqu'un, mais ma solution consistait à exclure la machineKey de ma configuration Web afin que mon cookie soit transmis.



	
		
			Licencié sous: CC-BY-SA avec attribution
			Non affilié à StackOverflow