Problème Erratic Invalid Viewstate dans une application .NET

Question

Il semble que je reçoive de temps en temps un message "invalid viewstate" dans l'observateur d'événements pour mon site Web. ASP.NET application.

La plupart d'entre eux (95%) semblent faire référence à ScriptResource.axd (l'application utilise le ASP.NET AJAX bibliothèque). Il n'y a aucun moyen de supprimer le Ajax bibliothèque soit car Ajax est utilisé partout..

Comment puis-je réduire ces erreurs ? Je reçois ~ 100-200 erreurs par jour et je n'ai aucune idée de la façon de les corriger ! Elles proviennent de différents navigateurs, de différentes IP et de différents lieux géographiques.

Il m'est difficile de reproduire le problème car il m'est à peine arrivé, il ne m'est arrivé que 3-4 fois de façon inattendue.

Erreur :

Process information: 
    Process ID: 4004 
    Process name: w3wp.exe 
    Account name: NT AUTHORITY\NETWORK SERVICE 

Exception information: 
    Exception type: HttpException 
    Exception message: Invalid viewstate. 

Request information: 
    Request URL: http://domainnamehere/ScriptResource.axd?d=W1R6x9VzZ2C9SKnIkOmX9VRLhSjJ3nOF1GSQvPwKS3html 
    Request path: /ScriptResource.axd 
    User host address: 124.177.170.75 
    User:  
    Is authenticated: False 
    Authentication Type:  
    Thread account name: NT AUTHORITY\NETWORK SERVICE 

Thread information: 
    Thread ID: 1 
    Thread account name: NT AUTHORITY\NETWORK SERVICE 
    Is impersonating: False 
    Stack trace:    at System.Web.UI.Page.DecryptStringWithIV(String s, IVType ivType)
   at System.Web.UI.Page.DecryptString(String s)
   at System.Web.Handlers.ScriptResourceHandler.DecryptParameter(NameValueCollection queryString)
   at System.Web.Handlers.ScriptResourceHandler.ProcessRequestInternal(HttpResponse response, NameValueCollection queryString, VirtualFileReader fileReader)
   at System.Web.Handlers.ScriptResourceHandler.ProcessRequest(HttpContext context)
   at System.Web.Handlers.ScriptResourceHandler.System.Web.IHttpHandler.ProcessRequest(HttpContext context)
   at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Custom event details: 

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

J'obtiens également cette erreur de temps en temps dans mon code .NET qui se produit en même temps, ce qui pourrait être lié :

Exception raised in GLOBAL.ASAX.Application_Error(): 'Padding is invalid and cannot be removed.' at System.Security.Cryptography.RijndaelManagedTransform.DecryptData(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount, Byte[]& outputBuffer, Int32 outputOffset, PaddingMode paddingMode, Boolean fLast)
   at System.Security.Cryptography.RijndaelManagedTransform.TransformFinalBlock(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount)
   at System.Security.Cryptography.CryptoStream.FlushFinalBlock()
   at System.Web.Configuration.MachineKeySection.EncryptOrDecryptData(Boolean fEncrypt, Byte[] buf, Byte[] modifier, Int32 start, Int32 length, IVType ivType, Boolean useValidationSymAlgo)
   at System.Web.UI.ObjectStateFormatter.Deserialize(String inputString)

Answer 1

Il semble que ce soit le même problème que celui rencontré par de nombreuses personnes dans IE8. Ce qui semble se produire, c'est que IE8 (en mode de rendu IE8 et en mode de compatibilité IE7) perd 4096 octets au milieu du document HTML et que ces données manquantes provoquent cette exception (vous voyez généralement cela dans un appel ScriptResource ou WebResource).

Voici un rapport de bogue de Microsoft sur ce problème : https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=434997

Il existe également de nombreux forums, blogs, etc. qui traitent de cette question :

• Paramètres invalides de Webresource.axd générés
• IE 8 perd des pages de mémoire ?
• http://forums.asp.net/t/1373410.aspx?PageIndex=1
• http://forums.asp.net/p/1409964/3085329.aspx

---

Microsoft a répondu à ce problème :

La note est un bogue dans Internet Explorer 8. L'équipe d'Internet Explorer a étudié ce problème.

Impact : Jusqu'à présent, nous pensons que le problème n'a aucun impact sur l'expérience de l'utilisateur final avec l'application web ; le seul effet négatif est celui des requêtes fallacieuses/malformées envoyées par le moteur de téléchargement spéculatif JavaScript. Lorsque le script est réellement nécessaire à l'analyseur, il sera correctement téléchargé et utilisé à ce moment-là.

Circonstances : La demande fallacieuse semble se produire uniquement dans certaines situations temporelles, uniquement lorsqu'une balise META HTTP-EQUIV contenant un Content-Type avec une directive CHARSET apparaît dans le document, et uniquement lorsqu'une URL SRC JavaScript s'étend sur le 4096e octet du corps de la réponse HTTP.

Solution : Par conséquent, nous pensons actuellement que ce problème peut être atténué en déclarant le CHARSET de la page à l'aide de l'en-tête HTTP Content-Type plutôt qu'en le spécifiant dans la page.

Donc, plutôt que de mettre

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">

Dans votre balise head, envoyez plutôt l'en-tête de réponse HTTP suivant :

Content-Type: text/html; charset=utf-8

Notez que la spécification du jeu de caractères dans l'en-tête HTTP améliore les performances de tous les navigateurs, car les analyseurs du navigateur ne doivent pas recommencer l'analyse depuis le début lorsqu'ils rencontrent la déclaration du jeu de caractères. En outre, l'utilisation de l'en-tête HTTP permet d'atténuer certains vecteurs d'attaque XSS.

REMARQUE : Certains rapports indiquent que ce problème se produit toujours lorsque la META HTTP-EQUIV ne figure pas sur la page. Nous mettrons à jour ce commentaire lorsque nous aurons plus d'informations.

Posté par Microsoft le 30/06/2009 à 12:25.

Modifier : Je vois encore cette exception occasionnellement, mais ce bogue est signalé comme étant corrigé : http://blogs.msdn.com/b/ieinternals/archive/2010/04/01/ie8-lookahead-downloader-fixed.aspx

Answer 2

Je suppose que vous utilisez ASP.NET AJAX. J'ai le même problème. Sporadiquement, je trouve cette exception dans mon journal des événements, et le chemin demandé est TOUJOURS ScriptResource.axd.

L'utilisation de la validationKey et du décryptageKey fixes dans machineKey n'a pas résolu le problème pour moi.

D'après ce que j'ai pu rassembler, j'ai tendance à croire que cette erreur n'a rien à voir avec le ViewState ; ma théorie est que, pour une raison quelconque, certaines UA se trompent dans le paramètre "d" du ScriptResource.axd. Le problème peut être facilement reproduit en demandant manuellement le chemin d'accès en question. Cela donne une exception "Invalid ViewState", même si ViewState ne s'applique pas ici.

En fouillant dans mes journaux, j'ai trouvé par exemple :

Cette requête est servie OK (200) : /ScriptResource.axd?d=oFCAB7_vUyp7Hhe9lxZBz37lpoAxhfbWwwdfFy3Zd3z41W_33Y_9Dq6i10g9Q1NRCY1n0_DNg1nE6-DDbsD6r4EiuwoeDzp9mjDDfBNLb1k1&t=41df03cc

Cette demande légèrement différente est également servie OK (200) : /ScriptResource.axd?d=oFCAB7_vUyp7Hhe9lxZBz37lpoAxhfbWwwdfFy3Zd3z41W_33Y_9Dq6i10g9Q1NR5ijsxQts4AfbJdACRwmQ8sHt6UAzui3spEnooPneTz01&t=41df03cc

Cette demande échoue avec une réponse 500 et l'exception Invalid ViewState : /ScriptResource.axd?d=oFCAB7_vUyp7Hhe9lxZBz37lpoAxhfbWwwdfFy3Zd3z41W_3**produits$ctl00$AddToCart1$id**

Si vous regardez attentivement, les premiers caractères des trois requêtes sont les mêmes, mais les derniers caractères de la dernière requête (en gras) sont clairement l'ID du contrôle "products$ctl00$AddToCart1$id" (j'ai des contrôles nommés products et AddToCart). Je ne sais pas comment cet ID est arrivé là, mais dans mon cas, c'est ce qui cause toutes ces exceptions Invalid ViewState.

Je ne sais pas si c'est le même cas que le PO ou non, mais je remarque que l'URL de la requête de Martin se termine par "html", ce qui est un peu une coïncidence pour un paramètre qui est censé être une clé...

J'ai déjà un mal de tête à cause de ce problème. Et jusqu'à présent, le billet le plus perspicace que j'ai trouvé est celui-ci http://bytes.com/topic/asp-net/answers/861764-invalid-viewstate-system-string-decryptstringwithiv

Des idées ?

Answer 3

Les problèmes de Viewstate sont ennuyeux et frustrants - J'ai remarqué que plusieurs personnes ont parlé de problèmes de Viewstate dans ce fil de discussion. Voici donc quelques suggestions que vous pouvez examiner dans l'ordre.

1. Je me fais l'écho de ce que Freddy Rios a dit dans ce fil de discussion. Assurez-vous que vous avez codé en dur la machine de la machine. Cela résoudra la grande majorité majorité de ces problèmes. Le site chose importante à propos du lien lien ScriptResource est qu'il doit avoir un paramètre d et un paramètre t dans la chaîne de requête. Si ce n'est pas le cas Si ce n'est pas le cas, il y a un problème !

2. Ne laissez pas l'utilisateur revenir en arrière avant que vous ayez terminé. Vous pouvez probablement faire cela avec javascript et un peu de css. De mémoire, je pense qu'il y a un moyen de le faire avec une balise méta mais mais c'est peut-être réservé à IE.

3. Je chercherais à évacuer la réponse tôt. Je pense qu'après le gestionnaire script serait le mieux. Mais vous pourriez avoir besoin d'expérimenter un un peu.

4. Si votre état de vue semble gonflé, activez la compression GZip dans IIS.

5. Si votre état de vue est devenu vraiment et que vous ne pouvez pas activer la compression la compression GZip est activée ou qu'elle a un effet secondaire indésirable. Vous pouvez alors compresser et décompresser le état de vue. http://www.codeproject.com/KB/viewstate/ViewStateCompression.aspx

6. Si cela vous laisse toujours avec un état de vue gonflé, vous pouvez envisager de stocker l'état des vues localement. http://blog.arctus.co.uk/articles/2007/04/23/advanced-asp-net-storing-viewstate-in-a-database/ est un bon point de départ.

Answer 4

Utilisez une clé de machine fixe (même en cas de serveur unique).

Le problème se produit lors de l'utilisation de la configuration automatique pour la clé de machine, vous en obtenez une nouvelle à chaque fois que le domaine d'application est recyclé. Cela affecte la validation du viewstate, le décryptage de la chaîne de requête des ressources dynamiques et les tickets d'authentification [insérer d'autres utilisations de la clé machine].

Answer 5

J'ai vu des problèmes de ce genre lorsque le Viewstate est trop grand. Je l'ai vu se produire à cause du problème décrit par Freddy.

Je n'aime généralement pas l'idée d'utiliser Viewstate. Pouvez-vous désactiver complètement Viewstate ?