Nous utilisons asp.net 2.x, nous utilisons l'état de session stocké dans le serveur SQL, 2 serveurs Web en charge, iis6. Notre problème est qu'au cours des 3 derniers mois, nous avons eu 2 cas où quelqu'un utilisant notre formulaire de demande a vu l'information de quelqu'un d'autre, par exemple. prénom et nom. Nous ne remplissons pas le formulaire à partir d'objets en cours de session, j'en suis donc arrivé à la conclusion que le second utilisateur a en quelque sorte reçu le viewstate du premier utilisateur, après que cet utilisateur a essayé de soumettre et a reçu une erreur. a posté l'état d'affichage et a renvoyé la même page et l'autre utilisateur a demandé cette page en même temps (doit avoir été sur le même serveur que je devine s'il s'agit d'un problème viewstate).Viewstate semble être détourné par inadvertance
l'un de vous a déjà ressenti cela? quelques questions se posent dans ma tête: comment le processus de travail sait-il renvoyer l'état d'affichage à une requête unique et comment détermine-t-il une requête unique, etc.
merci pour l'article, nous utilisons le cache en mode noyau ou response.output.cache avec varier en fonction param, le formulaire de demande n'est pas ajoutée au cache de sortie. La chose étrange est que c'est un problème viewstate, je suppose que l'article parlait des objets de session cependant, la chose clé ici est que nous utilisons des contrôles personnalisés afin viewstate pourrait être manipulé légèrement différemment plus le fait que l'article mentionne: OutputCacheModule échoue parfois dépouiller les en-têtes Set-Cookie des réponses mises en cache qu'il transmet à Http.sys .. et aux utilisateurs qui se connectent ... cela pourrait servir le même html dans la réponse suivante ... – dvr
plus nous sommes sur win2003 – dvr
sauf si vous surchargez viewstate gestion dans vos contrôles personnalisés, il devrait être assez uniforme avec le reste des contrôles. NET peut être la peine d'enquêter plus .. il peut aussi valoir la peine de mettre à niveau vers le nouveau cadre .. –