Mostrando entradas con la etiqueta Security. Mostrar todas las entradas
Mostrando entradas con la etiqueta Security. Mostrar todas las entradas

lunes, 5 de mayo de 2014

Event message: Error de autenticación de formularios para la solicitud. Motivo: el vale suministrado no era válido. Event detail code: 50201 (invalid ticket)

 

Tengo una solución de autentificación por formularios completamente personalizada, es decir que no utiliza el objeto FormsAuthentication para generar los vales (ticket) y ni para recuperarlos ni para actualizarlos.

La solución se encarga de crear el Principal, la cookies y así como de la encriptación y la firma de las cookies.

El síntoma

Haciendo unas mejoras para la lectura de propiedades desde la configuración de repente me apareció este error terrible. Terrible porque porque no tenía ni pies ni cabeza, no había manera de diagnosticarlo por razonamiento, más que por algo parecido a un “ataque de diccionario”, paso a pasito…

Este error “Event detail code: 50201” tiene muchas entradas en la Web pero en mi caso la solución no tiene nada que ver con ellas o por lo menos con las que leí, ¡algunas del año 2007!

image

El problema

Event code: 4005 
Event message: Error de autenticación de formularios para la solicitud. Motivo: el vale suministrado no era válido. 
Event time: 22/04/2014 10:12:19 p. m. 
Event time (UTC): 23/04/2014 03:12:19 a. m. 
Event ID: f90558d63abd44fea22996ac07792f94 
Event sequence: 58 
Event occurrence: 9 
Event detail code: 50201 

La cookie se adjunta inicialmente a la petición del contexto HTTP pero, cuando se intenta reenviar una petición Web cualquiera o simplemente re direccionar a la página inicial después de autentificarse correctamente (en términos de usuario en DB)  pues resulta que la cookie ha desaparecido y ya no está adjunta al nuevo Request, por lo tanto, nunca se puede salir de la página del LogOn, porque la autentificación por Forms desparece.


 


Solución


En mi caso el código hace referencia a varias propiedades del objeto FormsAuthentication, con el objeto de aprovechar la lectura simple de la configuración definida en la sección correspondiente.


Pues todo va bien, excepto por una propiedad, que si usted la referencia “todo se va a bolina” y aparece el error mencionado:


NO SE PUEDE referenciar la propiedad FormsAuthentication.FormsCookieName, en su lugar debe utilizar una constante.


Según mis pruebas ni siquiera se puede leer directamente la sección de configuración correspondiente, la cargué como XML puro y la leí directamente por XPath y el error aparece, supongo debido a que especifiqué un nombre de cookie en la sección <forms name=”.xname” /> e igualmente se inicializa el módulo HTTP default para FormsAuthentication.


Es decir el sólo hecho de pretender tomar el nombre de la cookie desde dicha propiedad, activa un comportamiento predeterminado (no deseado en este caso) para comprobar la validez del ticket de la cookie mediante los algoritmos predeterminados que lógicamente dirán que “el vale suministrado no era válido”.


Entonces, NO haga referencias al nombre de la cookie ni la coloque en la sección “forms” de la configuración. Deje su nombre como una constante o póngala en la sección del “appSettings” si cree que no puede vivir con un nombre fijo.


Etiquetas de Technorati: ,,,,

martes, 15 de noviembre de 2011

El tipo no está resuelto para el miembro “X”.

El contexto

Se desarrolla un especialización para IIdentity y se establece un nuevo IPrincipal mediante GenericPrincipal con MVC3.

El síntoma

System.Runtime.Serialization.SerializationException was unhandled by user code
  Message= Type is not resolved for member 'X'.
  Source=WebDev.WebHost40

Todo bien antes de autentificarse.

image

Ingresar las credenciales

image

Horror

image

Causa poco estudiada a detalle

El problema con la serialización logré reproducirlo tanto en un sitio con Telerik (quién reportaba el error y parecía un responsable, pero nada que ver) y con un proyecto nuevo y limpio de MVC3, quién sabe por qué en mi proyecto Web antiguo (MVC2) convertido a MVC3 sí funcionaba bien.

En fin, la causa no está muy bien explicada y tiene que ver con que el Servidor Web de desarrollo de ASP.NET (WebDev.WebHost40) se ejecuta de alguna forma en la que carga el serializador por un lado (GAC) y al intentar aplicar la deserialización no encuentra el ensamblado. Por algún motivo trata de buscar el ensamblado de seguridad personalizado en otros lugares pero no el el directorio bin del propio proyecto de desarrollo.

Existen algunas soluciones alternativas recomendadas en los sitios Web

Referencia 1: Implementing a Custom Identity and IPrincipal in MVC

Referencia 2: Update on my struggles with the ASP.NET Development Server

El problema sólo sucede durante la depuración utilizando en Servidor Web de desarrollo de ASP.NET. Cuando publicas en un sitio Web de IIS no hay problemas en el encontrar el tipo.

  • Hay algunas soluciones como copiar los ensamblados relacionados a las carpetas del Net Framework correspondientes bajo Windows, pero a mí no me funcionaron.
  • Otra solución con el GAC que en ningún caso adoptaré ni lo recomiendo, además a mi tampoco me funcionó y es como volver al pasado (¡DLL HELL!).
  • Otra es personalizar completamente la serialización implementando ISerializable, es relativamente  tedioso aunque fácil, pero requiere pruebas y es absurdo en mi caso, no me gusta.

En conclusión es posible utilizar su API y publicar en los sitios de destino con IIS sin problemas.

Para poder depurar tendría que ejecutar el VS en modo administrador y cambiar el servidor Web para utilizar IIS local en las propiedades de tu proyecto.

Una solución más simple es la siguiente

Abrir en el explorador de Windows la ubicación de su servidor Web de desarrollo (WebDev.WebHost40), en mi caso:

C:\Program Files (x86)\Common Files\microsoft shared\DevServer\10.0

Copiar allí, en la raíz, sus ensamblados que están relacionados y son necesarios para ejecutar su código de seguridad, sólo se requieren los ensamblados con los métodos que se cargarán durante la ejecución de su código de seguridad. No son necesarios otros ensamblados, que aunque estén relacionados en términos de referencias, no se utilicen en la comprobación.

Listo, en mi caso funciona perfecto y sigo utilizando el servidor Web de desarrollo y Visual Studio se puede ejecutar en modo de usuario, no administrador.

Gracias por todas las respuestas anteriores que me permitieron encontrar esta solución.

Saludos,

image