Dois-je ignorer l’erreur occasionnelle de vue invalide?

De temps en temps (une fois par jour à peu près), nous voyons les types d’erreurs suivants dans nos journaux pour une application ASP.NET 3.5

  • Etat d’affichage invalide
  • Argument non valide de publication ou de rappel

S’agit-il de quelque chose qui “se produit” de temps en temps avec une application ASP.NET? Est-ce que quelqu’un recommanderait que nous passions beaucoup de temps à essayer de diagnostiquer ce qui cause les problèmes?

En fait ça dépend. Une vue invalide peut se produire pour diverses raisons.

  1. Viewstate est trop grand et n’a pas fini de rendre avant qu’un utilisateur provoque une publication sur la page. La solution consiste généralement à désactiver tous les contrôles qui déclenchent les publications et à les activer côté client une fois le chargement de la page terminé – voir http://blogs.msdn.com/tom/archive/2008/03/14/validation-of-viewstate- mac-fail-error.aspx
  2. Vous utilisez des MAC de viewstate (et vous devriez l’être, pour des raisons de sécurité), mais vous n’avez pas défini de clé d’ordinateur et le pool d’applications en a généré un nouveau. N’oubliez pas de définir une ViewStateUserKey.
  3. Quelqu’un utilise une ancienne version d’IE sur le mac où il tronque les champs de formulaire masqués. Dans ce cas, vous devrez déplacer le viewstate hors de la page dans l’ état de session .
  4. Les problèmes de Viewstate MAC indiquent généralement que vous êtes sur une batterie de serveurs Web et que vous avez oublié de définir une clé d’ordinateur dans web.config. Cependant, si vous avez fait cela, il est probable que quelqu’un essaie de faire de mauvaises choses (les bots affichent des commentaires, quelqu’un essaie de déclencher des événements pour les contrôles désactivés, etc.).

Quoi que vous fassiez , ne désactivez pas la validation de vue ou d’événement.

Un problème peut être lié aux routeurs d’utilisateurs qui tronquent les champs de formulaire. La solution consiste à définir MaxPageStateFieldLength sur un petit nombre (comme 100) dans web.config et le ViewState est divisé en petits morceaux. C’est très simple à faire et cet article l’ explique pleinement.

BlowDart a la bonne réponse pour le problème Invalid Viewstate. Il est probable que votre pool d’applications soit recyclé et que vous modifiez la clé de cryptage.

Voir ces messages pour le support:

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

Faire en sorte que l’utilisateur se connecte avec ASP .Net Membership

Les exceptions ne se produisent pas de temps en temps. Ils se produisent toujours pour des raisons valables, dont certaines sont déjà répertoriées dans les autres réponses.

Cependant, pour éviter les problèmes avec ViewState, envisagez de le désactiver complètement. En tant que développeurs ASP.NET, nous avons souvent tendance à utiliser ViewState dans toutes sortes d’endroits où il n’est pas nécessaire, car c’est la valeur par défaut. Je pense généralement à utiliser du HTML statique avant d’utiliser un contrôle. Si vous décidez d’utiliser un contrôle, réfléchissez à la nécessité d’activer ViewState. La désactiver entraîne souvent de meilleurs temps de chargement des pages. Si vous le pouvez, faites-le.

Je souhaite que ce soit désactivé par défaut afin que les gens soient obligés de penser de cette façon, mais ce n’est pas le cas.

Mise à jour pour répondre aux commentaires:

Du haut de ma tête, je propose 3 possibilités pour désactiver ViewState.

  1. Désactivez ViewState si des données sont chargées sur chaque publication. Ce sera souvent le cas si vous construisez des sites compatibles avec AJAX (c’est un vrai AJAX, pas du type UpdatePanel;)) où vous chargez généralement des données sur le premier chargement, puis rechargez / mettez à jour les données à l’aide de requêtes AJAX. Dans certains cas, vous pouvez même charger des données à chaque visite dans le seul but de désactiver ViewState, puis mettre en cache les données sur le serveur.

  2. Vous pouvez également envisager de désactiver ViewState si vous vous connectez à un contenu réellement statique. Parfois, je trouve une liste basée sur une petite table de firebase database statique dans la firebase database ou quelque chose du genre. Maintenant, cela peut être dangereux, mais si je suis convaincu que les données ne changeront pas, je pourrais déplacer les données dans la page en tant que contenu statique (vous pourriez l’envelopper dans un contrôle séparé afin de ne pas avoir plusieurs copies statiques des données). ). Mais si les données sont modifiées, vous devrez les modifier manuellement.

  3. Les contrôles simples tels que les étiquettes sont souvent de bons candidats pour désactiver ViewState.

Enfin, vous pouvez passer au framework ASP.NET MVC et dire adieu à ces problèmes pour toujours, c’est ce que je compte faire même si je vais rencontrer d’autres problèmes. 😉

Il n’y a pas grand chose à faire à propos du premier – Je piège ces exceptions et renvoie l’utilisateur vers une page d’erreur avec un message du type “La page sur laquelle vous vous trouviez a expiré. Cela se produit généralement lorsque vous essayez de revenir sur une page avait déjà entré des données. ”

Je vois ce dernier le plus sur une assez grande page qui utilise UpdatePanels. Je pense que lorsque l’utilisateur publie (ou éventuellement rappelle) avant que la page ne soit complètement chargée, tous les javascript marqués à la fin de la page ne sont pas encore exécutés.

Encore une fois, il n’y a pas grand chose à faire à ce sujet, sauf si vous affichez un message approprié sur votre page d’erreur.

Ce n’est probablement pas une bonne idée d’ignorer cette erreur. En plus de toutes les réponses ci-dessus, vous voudrez peut-être envisager la taille de votre vue. Un grand viewstate peut être tronqué par un serveur proxy.

Si votre état d’affichage est important, utilisez une trace ASP.net pour voir quels contrôles utilisent viewstate et où vous pouvez désactiver cette option.

Selon Wayne Walter Berry, dans ce billet de blog, un autre coupable pourrait utiliser le doctype XHTML dans IE8 sans avoir un balisage compatible XHTML sur la page. Cela peut amener IE8 à envoyer des parameters brouillés à scriptresource.axd et lancer l’exception de vue invalide.

Il recommande de s’assurer que tous les blocs javascript sont entourés de // < ![CDATA[]]> ou simplement de modifier le doctype (ce qui pourrait entraîner d’autres problèmes de style / css sur votre page).

J’ai eu ce genre d’exception dans mes journaux et la cause était très différente de celle mentionnée ici. J’ai eu un très grand ViewState, qui fait partie du problème. Mais cela se combinait avec un autre problème pour provoquer ces exceptions (et éventuellement de mauvaises réponses de la part d’IIS).

La base de code sur laquelle je travaille a un code de fantaisie pour éviter les doubles clics, et ajoute du javascript à chaque événement de clic de bouton qui désactive le bouton après le premier clic, puis effectue la publication habituelle. Mais appeler ce postback était un problème car certains de mes boutons avaient déjà un appel postback généré par .NET automatiquement. Je me retrouvais donc avec des doubles postbacks, dont l’un avait un ViewState invalide. Supprimer le postback supplémentaire a arrêté les exceptions pour moi.

Je sais que je devrais vraiment réduire drastiquement la taille du ViewState, mais il s’agit d’une base de code héritée importante et un tel changement serait très invasif.

L’état d’affichage invalide n’a aucune valeur pour votre enregistreur ou pour les utilisateurs ou pour votre site Web, les utilisateurs finaux ne voient jamais ces erreurs. pour éviter cette erreur, essayez d’append ce qui suit dans Global.ascx :

 void Application_Error(object sender, EventArgs e) { if (ex is HttpException && ex.InnerException is ViewStateException) { Response.Redirect(Request.Url.AbsoluteUri); return; } } 

pour plus d’infos consultez le lien suivant:

https://www.karpach.com/viewstateexception-invalid-viewstate.htm

Mise à jour: Microsoft a annoncé que le correctif suivant pour IE 8 résout ce problème:
http://blogs.msdn.com/ieinternals/archive/2010/04/01/IE8-Lookahead-Downloader-Fixed.aspx