Azure Active Directory TokenCache basada en Entity Framework DB (issue en código de MS)

Si estás trabajando con Aplicaciones web securizadas con Azure Active Directory, seguramente estarás trabajando con ADAL. ADAL tiene su propia caché de tokens (genialmente explicada en este post del padre de ADAL, Vittorio Bertocci). La caché de tokens incluída en ADAL, sólo es adecuada para aplicaciones nativas, ya que funciona “en memoria”, por lo que para aplicaciones web, será un problema tarde o temprano. Por suerte, desde ADAL v2, podemos implementar nuestra propia caché de tokens, simplemente heredando de la clase TokenCache. Y de hecho, en el mismo post de Vittorio, tienes un par de ejemplos, donde uno esta basado en SQL Server con Entity Framework, por lo que es perfectamente válido para aplicaciones web.

Ese mismo codigo de TokenCache basado en DB, está en varios ejemplos en el GitHub de Azure AD, como este, además de decenas de artículos “around the web” :)

Pues bien, yo estoy lejos de ser un experto en Entity Framework, pero por las pruebas que he hecho y lo poco que se de EF, ese código tiene un issue que puede dar problemas en determinados escenarios. El problema está en el siguiente fragmento del método “AfterAccessNotification

Cache = new PerWebUserCache
{
webUserUniqueId = User,
cacheBits = this.Serialize(),
LastWrite = DateTime.Now
};
//// update the DB and the lastwrite                
db.Entry(Cache).State = Cache.EntryId == 0 ? EntityState.Added : EntityState.Modified;
db.SaveChanges();

Como verás, si en todo momento se está creando un nuevo objeto “PerWebUserCache”, siempre se creará un nuevo registro en la Tabla, y nunca se actualizará el existente. Esto puede dar problemas luego, cuando se consulta la caché y se devuelve el token para el usuario, ya que se podría devolver un Token que ya está expirado.

No soy el primero en detectar el issue, ya que existe un issue abierto en el sitio de GitHub, pero que hasta la fecha MS no ha corregido.

He creado una Pull Request tratando de corregir el issue, y está a la espera de aceptación. De momento, os dejo aquí el código completo de la clase:

Como veis, el fix consiste en comprobar si tenemos ya el registro de BD cargado, y si es el caso, actualizamos el Token serializado, y la fecha de última escritura. De no ser así, entonces sí creamos un nuevo registro.

Expero que os sirva, y si sois unos expertos en EF y tenéis una manera mejor de corregirlo, deja un comentario please!

Luis Mañez

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.