Ce problème a été résolu grâce à vos suggestions. Voir le bas pour plus de détails. Merci beaucoup pour votre aide!L'application ASP.NET présente un comportement étrange à travers le pare-feu
Notre site ASP.NET est accessible à partir de plusieurs sites internationaux spécifiques et hautement sécurisés. Il a bien fonctionné, mais nous avons ajouté un autre emplacement client qui présente un comportement très étrange.
En particulier, lorsque l'utilisateur entre des critères de recherche et clique sur le bouton de recherche, la liste des résultats retourne vide. Il n'affiche même pas le texte '0 résultats renvoyés', donc c'est comme si le contrôle Repeater ne se liait pas du tout. Un comportement similaire apparaît dans certaines parties du site, mais pas toutes. L'utilisateur peut se connecter au site correctement et ses informations de profil sont affichées.
J'ai ouvert une session sur le site en utilisant exactement les mêmes informations d'identification et le site fonctionne bien à partir d'ici. Nous avons soigneusement suivi les étapes, donc je suis convaincu que ce n'est pas un problème d'utilisateur. Je lie les résultats de la recherche dans le PageLoad de la page de résultats de recherche la première fois qu'il est chargé (le critère est dans la chaîne de requête). à savoir
if (!IsPostBack) {
BindResults();
}
je peux reproduire exactement le même comportement localement en commentant la méthode BindResults() appel.
Est-ce que quelqu'un sait comment la valeur de IsPostBack est calculée? Est-il possible que leur configuration de pare-feu hautement sécurisé fasse que IsPostBack retourne toujours vrai, même s'il s'agit d'une redirection depuis une autre page? Cela pourrait être un casse-tête comme le problème pourrait être ailleurs. Cela reproduit exactement le résultat.
Je n'ai pas accès au site, le dépannage se limite donc à leur donner des instructions et à leur demander de me communiquer le résultat.
Merci pour votre temps! Information additionnelle: Le client est derrière un pare-feu Microsoft ISA 2006 exécutant des règles par défaut. Le site a été ajouté à la liste des sites de confiance d'Internet Explorer et testé dans FireFox et Google Chrome, tous avec le même résultat.
SOLUTION: Le gagnant pour moi était la suggestion d'utiliser Fiddler. Quel excellent outil qu'aucun développeur Web ne devrait être sans. En utilisant ceci, j'ai été capable de retirer divers en-têtes de la requête jusqu'à ce que je reproduise le problème. Il y avait en fait deux facteurs qui ont causé ce bug, comme c'est souvent le cas avec de tels problèmes confus. Facteur un - Dans la mesure du possible, l'application Web utilise la compression GZIP telle que prise en charge par tous les principaux navigateurs. Le pare-feu supprimait l'en-tête qui spécifiait le support de décompression GZIP (Accept-Encoding: gzip, deflate). Facteur deux - Un bogue dans mon code signifiait que certains traitements étaient ignorés lorsque le contenu était envoyé non compressé. Ce problème n'a pas été remarqué auparavant car l'application est utilisée par un public limité, tous supportant la décompression GZIP.
Merci pour la suggestion. J'ai essayé d'utiliser le site avec Javascript désactivé et cela fonctionne bien (au moins cette partie du site est). En outre, ils ont ajouté le domaine à leur liste des sites de confiance Internet Explorer et ont essayé Firefox et Chrome, donc Javascript aurait dû être activé. – Andrew
Peut-être mettre en place une page de test qui répercute toutes les variables de formulaire et assurez-vous que le __VIEWSTATE est propagé. Pour chaque clé en tant que chaîne dans Request.Form Response.Write (clé & "=" + Request.Form (clé)) Suivant – Turnkey