2009-04-20 12 views
13

Usando DotNetOpenAuth 3 en ASP.NET MVC y la implementación de un centro de RememberMe ...RememberMe con DotNetOpenId en ASP.NET MVC

estoy encontrando que incluso si fijo createPersistentCookie en true en FormsAuthentication.RedirectFromLoginPage y FormsAuthentication. SetAuthCookie el usuario no se recuerda una vez que la sesión de ASP.NET agote el tiempo.

Si inspecciono la cookie, me parece que está marcada como persistente y tiene una fecha de caducidad en el futuro, supongo que porque configuré el tiempo de espera de mis formularios web.config dentro de unos años. De todos modos, si el usuario cierra el navegador y vuelve a abrirlo, se recuerda correctamente, siempre que no se haya agotado el tiempo de espera de la sesión ASP.

An older post de Scott Hanselmann me hace preguntar si es porque FormsAuthentication intenta renovar el ticket de autenticación y tal vez en un modelo OpenId que no funciona pero he configurado FORMS SlidingExpiration = "false" en web.config y de todos modos I pensó que forzar una cookie persistente haría que eso fuera irrelevante.

También me pregunto por qué la muestra DotNetOpenId MVC no incluye una casilla de verificación RememberMe. ¿Hay algo complicado en ello?

Por otro lado, aquí en StackOverflow veo que me recuerdo automáticamente en todas las sesiones. Se pregunta si usaron algo más que DotNetOpenId para hacer su autenticación OpenId.

¿Alguien más ha realizado RememberMe con éxito con DotNetOpenId en ASP.NET MVC? ¿Algún truco?

[Actualización]

Gracias por intentar ayudar, Andrew. Resulta que esto no se trataba de DotNetOpenId.

Entiendo, después de leer this, que mi proveedor de hosting probablemente está reciclando el grupo de aplicaciones regularmente y eso está causando que el cifrado de la autenticación se realice con una nueva clave de máquina.

Según el artículo enlazado anterior que añade lo siguiente bajo System.Web en mi Web.Config y se resuelva el problema:

<machineKey 
    validationKey="(generated a new key to place here)"  
    decryptionKey="(generated a new key to place here)" 
    validation="SHA1" 
    decryption="AES" /> 
+0

Hola Martin, StackOverflow sí utiliza DotNetOpenId. Creo que su problema con la sesión de cookies probablemente no tiene nada que ver con OpenID, ya que no creo que haya ninguna posibilidad de que DNOI interfiera con su cookie y nunca desconecta a un usuario. Trataré de investigar sobre esto y publicar una respuesta si aprendo algo. –

+0

Gracias por esto. Me ayudó. Debes publicar tu solución como respuesta para que se pueda subir el número y obtener la insignia de "autoaprendizaje" – BigJoe714

Respuesta

2

¿Coincide el nombre de la cookie en su archivo web.config y su controlador de llamar a FormsAuthentication.SetAuthCookie? Esto puede ser un error en el ejemplo DNOI, pero sospecho que si tiene un nombre de cookie en su archivo web.config (como lo hace el ejemplo DNOI), entonces probablemente tenga que establecer el nombre de la cookie como el tercer parámetro para SetAuthCookie o RedirectFromLoginPage . De lo contrario, auth de formularios no reconoce la cookie persistente que configura como la cookie de inicio de sesión.

3

Todavía creo que el nombre de la cookie debe coincidir ... pero aquí hay algo más.

Parece que está diciendo que mientras el tiempo de espera en el archivo web.config sea grande, entonces las cosas funcionarán. Pero una vez que lo acorta, su cookie persistente no dura más que el valor de tiempo de espera. Este tema del foro me ayudó a responder esto: http://forums.asp.net/p/1010241/1347970.aspx#1347970

Parece que el tiempo de espera en web.config afecta a todas las cookies. Dice cuánto dura el ticket de autenticación. Todas las cookies de autenticación tienen este tiempo de espera 'time to live', ya sea que sean 'persistentes' o no. Entonces, la diferencia entre las cookies persistentes y las cookies no persistentes es que la primera durará en diferentes sesiones de navegador y la última morirá (temprano) si el navegador está cerrado.

¿Tiene sentido?