Problème erratique de Viewstate non valide dans une application .NET

Je semble obtenir un “viewstate invalide” de temps en temps dans la visionneuse d’événements pour mon application ASP.NET .

La plupart d’entre eux (95%) semblent faire référence à ScriptResource.axd (l’application utilise la bibliothèque ASP.NET AJAX ). Je ne peux pas non plus supprimer la bibliothèque Ajax 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 manière de les réparer! Ils proviennent de différents navigateurs, de différentes adresses IP et de différents emplacements géographiques.

Il m’est difficile de reproduire le problème parce que cela m’est à peine arrivé, il ne m’est arrivé que 3 ou 4 fois.

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.DecryptSsortingngWithIV(Ssortingng s, IVType ivType) at System.Web.UI.Page.DecryptSsortingng(Ssortingng s) at System.Web.Handlers.ScriptResourceHandler.DecryptParameter(NameValueCollection querySsortingng) at System.Web.Handlers.ScriptResourceHandler.ProcessRequestInternal(HttpResponse response, NameValueCollection querySsortingng, 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’ai aussi cette erreur de temps en temps dans mon code .NET qui se produit en même temps et 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(Ssortingng inputSsortingng) 

    Cela semble être le même problème IE8 que beaucoup de gens ont connu. Ce qui semble se passer, c’est que IE8 (en mode de rendu IE8 et en mode de compatibilité IE7) perdra 4 096 octets au milieu du document HTML et que cette donnée manquante provoque cette exception (vous le voyez généralement dans un appel ScriptResource ou WebResource) .

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

    Il y a aussi beaucoup de forums, blog, etc. sur ce sujet:


    Microsoft a répondu à ce problème:

    Remarque 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 les demandes erronées / mal formées envoyées par le moteur de téléchargement spéculatif JavaScript. Lorsque l’parsingur a effectivement besoin du script, il sera correctement téléchargé et utilisé à ce moment-là.

    Circonstances : La demande spurious 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 JavaScript SRC couvre le 4096e octet du fichier. Corps de réponse HTTP.

    Solution: Par conséquent, nous pensons que ce problème peut être résolu 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

      

    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 parsingurs du navigateur n’ont pas besoin de recommencer l’parsing dès qu’ils rencontrent la déclaration de jeu de caractères. De plus, l’utilisation de l’en-tête HTTP permet d’atténuer certains vecteurs d’attaque XSS.

    REMARQUE: certains problèmes ont été signalés lorsque ce problème persiste lorsque META HTTP-EQUIV n’est pas sur la page. Nous mettrons à jour ce commentaire lorsque nous aurons plus d’investigations.

    Publié par Microsoft le 30/06/2009 à 12h25.

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

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

    L’utilisation de validKey et de decryptionKey fixes dans machineKey ne m’a pas permis de résoudre le problème.

    Sur la base de ce que j’ai pu rassembler, j’ai tendance à croire que cette erreur n’a rien à voir avec le ViewState que ce soit; Ma théorie est que pour une raison quelconque, certains agents utilisateurs désorganisent en quelque sorte le paramètre “d” de ScriptResource.axd. Le problème est facilement réplicable en demandant manuellement le chemin incriminé. Cela donne une exception “Invalid ViewState”, même si ViewState ne s’applique même pas ici.

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

    Cette demande est envoyée 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 requête échoue avec une réponse 500 et une exception ViewState non valide: /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 des identifiants de contrôle “produits $ ctl00 $ AddToCart1 $ id” (j’ai un contrôle nommé produits et AddToCart). Je ne sais pas comment cet ID est arrivé là, mais dans mon cas, c’est ce qui cause toutes ces exceptions ViewState non valides.

    Je ne suis pas sûr que ce soit le même cas que l’OP ou non, mais je remarque que l’URL de demande de Martin se termine par “html”, ce qui est un peu une coïncidence pour un paramètre supposé être une clé …

    J’ai déjà mal à la tête grâce à ce problème. Et jusqu’ici, le message le plus perspicace que j’ai rencontré est celui-ci: http://bytes.com/topic/asp-net/answers/861764-invalid-viewstate-system-ssortingng-decryptssortingngwithiv

    Des idées?

    Les problèmes de Viewstate sont gênants et frustrants – j’ai remarqué que quelques personnes ont parlé de problèmes avec Viewstate dans ce sujet. Donc, voici quelques suggestions que vous pouvez examiner dans l’ordre.

    1. Je ferais écho à ce que Freddy Rios a déjà dit dans le fil. Assurez-vous que vous avez bien codé la clé de la machine. Cela résoudra la grande majorité de ces problèmes. L’important à propos du lien ScriptResource est qu’il doit avoir un paramètre d’annonce et un paramètre dans la chaîne de requête. Si ce n’est pas le cas, quelque chose ne va pas!

    2. Ne laissez pas l’utilisateur poster jusqu’à votre fin. Vous pourriez probablement le faire avec JavaScript et un peu de CSS. De mémoire, je pense qu’il y a un moyen de faire cela avec une balise META, mais cela pourrait être seulement IE.

    3. Je regarderais rougir la réponse plus tôt. Je pense qu’après le script manager serait le meilleur. Mais vous pourriez avoir besoin d’expérimenter un peu.

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

    5. Si votre viewstate est devenu vraiment gonflé et que vous ne pouvez pas activer la compression de GZip ou qu’il a un effet secondaire indésirable. Ensuite, vous pouvez compresser et décompresser le viewstate. http://www.codeproject.com/KB/viewstate/ViewStateCompression.aspx

    6. Si cela vous laisse toujours une vue gonflée, vous pouvez envisager de stocker le viewstate localement. http://blog.arctus.co.uk/articles/2007/04/23/advanced-asp-net-storing-viewstate-in-a-database/ est un bon sharepoint départ.

    Utilisez une clé de machine fixe (même lorsque vous faites un serveur unique).

    Le problème se produit lorsque vous utilisez la configuration automatique pour la clé d’ordinateur, vous en obtenez un nouveau chaque fois que le domaine d’application est recyclé. Cela affecte la validation du viewstate, le déchiffrement des chaînes de requête des ressources dynamics et les tickets d’authentification [insérer d’autres utilisations de la clé d’ordinateur].

    J’ai vu des problèmes comme celui-ci lorsque Viewstate est trop volumineux. Je l’ai vu arriver en raison du problème décrit par Freddy.

    Je n’aime généralement pas l’idée d’utiliser Viewstate. Pouvez-vous désactiver Viewstate?

    J’ai aussi ce problème et j’ai essayé tout ce qui est mentionné dans tous les blogs que j’ai trouvés (clé de machine fixe, taille de vue, etc.). 99% du temps, l’erreur est enregistrée sur les requêtes à ScriptResource.axd. J’utilise .net 3.5 SP1, sur le serveur Win 2003. L’application est hébergée sur deux serveurs identiques parallèles, équilibrés 50/50. Chaque serveur a la même clé de machine.

    Normalement, cette erreur ne me préoccupe pas beaucoup, cependant, sur une période de trois mois, la tendance a augmenté.

    Est-ce que quelqu’un pense que cette erreur est liée au fait que Viewstate n’est pas UrlEncoded / HtmlEncoded ou UrlDecoded correctement? Peut-être y a-t-il un sous-ensemble de caractères dans le viewstate que certains navigateurs remplacent par une valeur codée. Je ne sais pas si cela a du sens.

    Je pense que vous devez utiliser la page aspx:

       

    Cela résout mon problème

    Est-ce que vous utilisez un système d’exploitation non anglais?

    Pour certaines raisons, le nom de compte de “NT Authority \ Network Service” a été localisé dans d’autres langues.
    Malheureusement, de nombreux programmes ont le nom de compte codé en dur au nom anglais et ne trouveront pas le service réseau lorsqu’ils sont exécutés sur des versions étrangères de Windows, ce qui entraîne toutes sortes d’erreurs géniales dans le journal des événements.

    Je viens de réduire ce problème à un utilisateur avec l’antivirus de Trend Micro et les erreurs ont tout simplement commencé à se produire après avoir mis à jour son logiciel de micro tendance le 21/05/2009. Aucune erreur avant cette date.

    Le problème semble être le téléchargeur de lookahead dans IE8.

    Il semble ne toucher que IE8 dans un ensemble de circonstances assez obscur. L’une des raisons pour lesquelles cela peut passer inaperçu est qu’une partie de données de 4 Ko ajoutée à une URL est souvent rejetée par le serveur. L’une des choses qui semble rendre les choses plus probables est une connexion réseau lente. Quelqu’un dans l’une des ressources ci-dessous a noté qu’il n’avait le problème qu’avec ses clients en Nouvelle-Zélande.

    Beaucoup de personnes expliquant deux problèmes distincts, dont l’un est décrit dans la question ci-dessus (URL mal formées envoyées au serveur):

    http://connect.microsoft.com/VisualStudio/feedback/details/434997/invalid-webresource-axd-parameters-being-generated

    Article expliquant que le téléchargeur de lookahead est corrigé:

    http://blogs.msdn.com/b/ieinternals/archive/2010/04/01/ie8-lookahead-downloader-fixed.aspx

    KB980182 – Mise à jour cumulative dans laquelle le problème est résolu:

    http://support.microsoft.com/kb/980182

    REMARQUE: Étant donné que le script est automatiquement téléchargé de nouveau s’il n’a pas pu être récupéré par le téléchargeur de référence, il devrait être possible de revenir à l’ancien mode de validation dans lequel les fichiers .axd n’ont pas été vérifiés problème: