No hagas un deploy de lo que no tengas que hacer un deploy

Hoy nos hemos encontrado con uno de esos poltergeist que tan locos nos vuelven de tanto en cuanto.

Resulta que estábamos haciendo un despliegue de una aplicación MVC en un entorno de pruebas. Es una aplicación sencillita con autenticación windows y una autorización personalizada como explicábamos en el anterior artículo. Lo primero que nos hemos encontrado es que al acceder a la aplicación nos daba un error 403. Esto es debido a que el AppPool con el que estaba configurada la aplicación en el IIS tenia el Pipeline Mode a Classic. Este modo evita que podamos acceder a direcciones sin extensión, aunque hay workarounds que solventan el problema.

Pero todavía no sabíamos que teníamos este problema, así que una de las (erróneas) creencias que hemos tenido ha sido pensar que nuestro IIS tenia algún problema con el MVC. Pensando esto, hemos querido desplegar las dlls necesarias con nuestra aplicación, así que nos hemos ido a nuestro querido Visual Studio, hemos hecho clic con el botón derecho sobre la solución y hemos seleccionado la opción “add deployable dependencies”

adddeploymentdependencies2

Esto, después de pedirnos que dependencias queríamos añadir…

adddeploymentdependenciesStep2

…nos ha creado un directorio en la solución con las dependencias necesarias

bin_deployableAssemblies

Esto no nos ha solucionado nada ya que todavía teníamos el AppPool mal configurado. Finalmente nos hemos dado cuenta de nuestro error, hemos cambiado el AppPool y hemos vuelto a ejecutar la aplicación… y todavía nos ha dado un error más sorprendente!!

404

Un 404!! Y un 404 sobre un controlador y una acción que no tenemos definido. Repasamos el web.config para ver si tenemos alguna redirección mal configurada y vemos que no es así. Finalmente, después de mucho buscar nos hemos encontrado con este salvador blog. En él, su autor explica que si teniendo una aplicación con autenticación forms y cambiándole en el web.config el controlador de autenticación, la aplicación se le redirige hacia el mismo controlador que a nosotros. El autor explica que esto es un bug conocido que pasa cuando estamos desplegando las librerías WebMatrix.Data.dll y WebMatrix.DataWeb.dll junto con nuestra aplicación. Aquí podéis ver el error en el Windows Connect. Esto que a él le pasa con autenticación forms, parece que también pasa con autenticación windows.

Finalmente hemos borrado estas dos librerías del bin de nuestra aplicación y voilà!

appok

Así que ya sabéis, id con cuidado con lo que desplegáis, no vayáis a tener resultados inesperados!!

Un saludo!

Autorización personalizada en ASP .Net MVC

El otro día nos surgió un problema al realizar una aplicación Asp .Net MVC 3. Lo que necesitábamos era poder autorizar una aplicación en función de unos grupos que a priori no conocíamos, es decir, que queríamos poder configurar en el .config una serie de grupos que fueran los que tuvieran acceso a la aplicación. Esto nos llevó a tener que hacer una autorización personalizada en MVC. Veamos los pasos que tenemos que seguir para llevarla a cabo.

Para hacer esto nos apoyaremos en los action filters de MVC. Un action filter es un atributo que podemos aplicar a una acción de un controlador o a un controlador entero que modifica la manera en que la acción se ejecuta. En nuestro caso lo que haremos será crear un action filter personalizado para poder implementar la autorización personalizada que queremos.

Si nos vamos al global.asax vemos que hay una función llamada RegisterGlobalFilters en la que se está añadiendo el HandleErrorAttribute. Vamos a añadir nosotros aquí mismo un nuevo filtro llamado CustomAuthenticationAttribute:

Vamos a echarle un ojo a la clase CustomAuthenticationAttribute. Lo primero que vemos es que es una clase que deriva de AuthorizeAttribute, para poder así sobrescribir el comportamiento por defecto de la autorización. En el constructor, lo que estamos haciendo es cargar la lista de roles permitidos de nuestro web.config.

Después vemos que hacemos un override de tres métodos:

OnAuthorization
Este es el método que se llama cuando un proceso solicita autorización. En él, lo que haremos será mirar si la acción o el controlador está decorado con el atributo AllowAnonymous, hecho también por nosotros. Esto nos permitirá tener métodos accesibles para todo el mundo.

AuthorizeCore
Este es el método que realiza la autorización. Devuelve true si el acceso está permitido y false si no lo está. En nuestro caso, miraremos si el usuario que hace la petición es miembro de algún grupo de los definidos en el web.config. Aquí podríamos poner la lógica que fuera necesaria para cada caso en concreto.

HandleUnauthorizedRequest
Este es el método que se llama cuando una petición a una acción no ha sido autorizada. En nuestro caso haremos un redirect a un controlador que mostrará el mensaje de error.

Tal y como hemos comentado anteriormente, tenemos que hacer el atributo que nos permitirá tener un acceso anónimo a una acción:

Para finalizar modificamos el Web.config. En nuestro caso añadimos una entrada en el appSettings para indicar los roles que tienen permisos y configuramos la seguridad básica denegando el acceso a todo usuario que no esté autenticado.

Y con esto ya estamos. Espero que os haya servido.

 

Un saludo!