La aplicación ASP.NET exhibe un comportamiento extraño a través del firewall

Question

Este problema se ha resuelto gracias a sus sugerencias. Consulte la parte inferior para obtener más detalles. ¡Muchas gracias por tu ayuda!

Se accede a nuestro sitio web ASP.NET desde varias ubicaciones internacionales específicas y altamente seguras. Ha estado funcionando bien, pero hemos agregado otra ubicación de cliente que exhibe un comportamiento muy extraño.

En particular, cuando el usuario ingresa los criterios de búsqueda y hace clic en el botón de búsqueda, la lista de resultados vuelve vacía. Ni siquiera muestra el texto '0 resultados devueltos', por lo que es como si el control Repeater no se vinculara en absoluto. Un comportamiento similar aparece en algunas, pero no en todas, otras partes del sitio. El usuario puede iniciar sesión en el sitio correctamente y se muestra su información de perfil.

He iniciado sesión en el sitio localmente usando exactamente las mismas credenciales que ellos y el sitio funciona bien desde aquí. Hemos seguido los pasos cuidadosamente, así que estoy seguro de que no es un problema del usuario.

Ato los resultados de búsqueda en la página Carga de la página de resultados de búsqueda la primera vez que se carga (el criterio está en la cadena de consulta). es decir

if (!IsPostBack) {
  BindResults();
}

Puedo replicar exactamente el mismo comportamiento localmente al comentar la llamada al método BindResults ().

¿Alguien sabe cómo se calcula el valor de IsPostBack? ¿Es posible que su configuración de firewall altamente segura haga que IsPostBack siempre sea verdadero, incluso cuando se trata de una redirección desde otra página? Eso podría ser una pista falsa, ya que el problema podría estar en otra parte. Sin embargo, sí replica exactamente el resultado.

No tengo acceso al sitio, por lo que la solución de problemas se limita a darles instrucciones y pedirles que me digan el resultado.

¡Gracias por su tiempo!

Información adjunta: el cliente está detrás de un servidor de seguridad Microsoft ISA 2006 que ejecuta reglas predeterminadas. El sitio se ha agregado a la lista de sitios de confianza de Internet Explorer y se ha probado en Firefox y Google Chrome, todo con el mismo resultado.

SOLUCIÓN : El ganador para mí fue la sugerencia de usar Fiddler. Qué excelente herramienta sin la que ningún desarrollador web debería estar. Con esto pude eliminar varios encabezados de la solicitud hasta que reproduje el problema. En realidad, hubo dos factores que causaron este error, como suele ser el caso con problemas tan confusos.

Factor uno: siempre que sea posible, la aplicación web utiliza la compresión GZIP como lo admiten todos los principales navegadores. El firewall estaba eliminando el encabezado que especifica el soporte de descompresión GZIP (Accept-Encoding: gzip, deflate).

Factor dos: un error en mi código significaba que se omitía parte del procesamiento cuando el contenido se enviaba sin comprimir. Este problema no se notó antes porque la aplicación es utilizada por un público limitado, todo lo cual soportaba la descompresión GZIP.

Answer 1

Si son expertos en tecnología, les pediría que descarguen Fiddler o algo similar, capturen toda la sesión HTTP y luego le envíen la sesión guardada. Quizás algo sobresalga.

Mientras tanto, vea si puede obtener una instalación de ISA Server (una instalación de evaluación, si es necesario, o una de MSDN si tiene o conoce a alguien con un sub) y vea si puede replicarlo localmente.

Answer 2

¿Es posible que el cliente haya deshabilitado Javascript y no esté recogiendo el valor del formulario _EVENTTARGET?

Answer 3

Puede ser algún tipo de proxy que cree una solicitud GET a partir de una solicitud POST dada ...

No estoy seguro de cómo se calcula el IsPostBack, pero supongo que verifica la solicitud HTTP para ver si es una POST o una GET ...

Answer 4

Ohh, si. Definitivamente NO es '' _EVENTTARGET '' Por cierto ...

Sé esto porque Ra-Ajax NO pasa ninguno de esos parámetros al servidor y ellos (Ra -ajax solicitudes) se procesan como solicitudes IsPostBack ...

Answer 5

Ubicación, ubicación, ubicación. Verifica la cultura del usuario. Normalmente eso causa problemas.

Answer 6

¿Podría crear una página de publicación de prueba que pase las mismas cosas que su página de búsqueda y en Page_Load escriba de nuevo toda la publicación para asegurarse de que se aprueben, especialmente el __VIEWSTATE.

foreach (string key in Request.Form)
{
    Response.Write("<br>" + key + "=" + Request.Form[key]);
}

Luego, solicite a uno de los usuarios que reenvíe lo que ve en esa página de prueba.

EDITAR: hay documentación de que algunos firewalls pueden dañar el VIEWSTATE y algunos métodos para evitarlo: Ver descripción general del estado

Answer 7

Verifique los registros de IIS para ver si la solicitud llega incluso a su servidor. La configuración de ISA podría estar almacenando en caché la solicitud inicial y sirviéndola en las solicitudes posteriores.