Saltar al contenido

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript... y lo que venga ;)

17 años online

el blog de José M. Aguilar

Inicio El autor Contactar

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web
ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript...

¡Microsoft MVP!
lunes, 1 de febrero de 2010
aspnetmvc Con objeto de mejorar la seguridad de nuestras aplicaciones, la Release Candidate de ASP.NET MVC 2 introdujo un cambio importante en la forma de procesar peticiones que retornan información serializada como JSON: por defecto, ahora sólo se responde a peticiones de tipo POST.

Dado que en MVC 1.0 era justo al contrario, esta pequeña reorientación hace que aplicaciones que antes funcionaban correctamente dejen de hacerlo al migrarlas a la última versión del framework. Un ejemplo lo tenemos con las aplicaciones que aprovechan la potencia de jqGrid para mostrar y editar rejillas de datos. Recordemos que el intercambio de información entre cliente y servidor se realiza mediante llamadas Ajax que retornan siempre datos en notación JSON.

Los síntomas que notaremos en estos casos son muy simples: ¡las acciones que deberían devolvernos información dejan de hacerlo! En algunas ocasiones, dependiendo del uso que se dé en la vista a la la información retornada, es posible que aparezcan errores de script en el navegador, pero otras ni siquiera eso.

En cualquier caso, no es difícil dar con la solución. Con Firebug, Fiddler, o cualquier herramienta que nos permita monitorizar las peticiones, podremos observar que en la petición Ajax se está produciendo un error HTTP 500 (error interno de servidor):

image

Y si seguimos profundizando en dicha petición, podemos ahora conocer el mensaje descriptivo que envía el servidor, un auténtico detalle por parte del equipo de desarrollo de ASP.NET MVC 2, en el que incluso nos indican la solución al problema:

<html>
<head>
<title>This request has been blocked because sensitive 
information could be disclosed to third party web sites when 
this is used in a GET request. 
To allow GET requests, set JsonRequestBehavior to AllowGet.</title>
<style>

Ante esta situación, podemos optar por dos soluciones. La primera sería indicar explícitamente en la instancia del resultado, de tipo JsonResult, que queremos permitir el método GET, así:

return Json(data, JsonRequestBehavior.AllowGet);

Y otra posibilidad sería realizar las peticiones Ajax utilizando el método POST, algo que podemos conseguir muy fácilmente la mayoría de las veces. En el caso de los ejemplos con jqGrid, sería sustituyendo el ’GET’ por ‘POST’ en código:

[...]
jQuery("#list").jqGrid({
url: '<%= Url.Action("ObtenerDatosGrid") %>',
datatype: 'json',
mtype: 'POST',    // <- Aquí
colNames: ['Apellidos', 'Nombre', 'Fecha Nac.', 'Email'],
[...]

¡Gracias, Maxi, por los comentarios que inspiraron este post!

Publicado en: Variable not found.

4 Comentarios:

Maxi dijo...

Exelente !!!
Ahora me termina de cerrar el concepto por el cual tuve que modificar JSon...un lujo.

Saludos.

josé M. Aguilar dijo...

Me alegro de que te sea útil. :-)

Gracias por comentar.

Hector dijo...

Hola Jose, me volvi loco porque no me funcionaba en mvc 2, gracias!!!
Una consulta, en este ejemplo el parametro lleva:

JsonRequestBehavior.AllowGet

Para que sirver el otro que lo estaba viendo:

JsonRequestBehavior.DenigedGet

????

Es para no permitir recibir parametros? en que casos se usuaría???

Mil gracias

josé M. Aguilar dijo...

Hola, Héctor.

AllowGet indica que la respuesta Json será enviada de vuelta aunque la petición sea de tipo GET.

DenyGet indica que las peticiones de tipo GET serán denegadas, es decir, que se permitirá exclusivamente el POST (y otros verbos, aunque son menos frecuentes).

DenyGet es el valor por defecto, por lo que no es necesario indicarlo expresamente, y es la forma aconsejable por razones de seguridad (más info aquí).

Saludos.