Extender el tiempo de inicio de sesión según la elección del usuario.
Escenario: la aplicación web ASP.NET MVC 5 está alojada en Azure WebApp WebConfig está configurada para el tiempo de espera en 60 minutos sin solicitudes al servidor como se muestra a continuación
Configuración web:
<authentication mode="Forms"> <forms loginUrl="~/Account/Login" timeout="60" slidingExpiration="true" name="MYAUTHDV" cookieSameSite="None" requireSSL="true" /> </authentication>
En la pantalla de inicio de sesión, nos gustaría proporcionar una CAJA DE VERIFICACIÓN y si el usuario la marca e inicia sesión, la aplicación web no debería cerrar la sesión durante las próximas 12 horas, incluso si no hay actividad.
Hasta ahora, probé un temporizador de JavaScript que se ejecuta en _layoutpage.chtml y un valor de tiempo de almacenamiento local registrado en el momento de inicio de sesión en el lado del cliente. El temporizador de javascript hará ping al servidor cada 20 minutos para mantener vivo el inicio de sesión. Esto no siempre funciona por múltiples razones, como el navegador, el modo de suspensión de la máquina, las interrupciones de Internet por apagado del disco duro y otras razones desconocidas, etc. microsoft.com/en-us/dotnet/api/system.web.security.formsauthentication.slidingexpiration?view=netframework-4.8 También estoy abierto a soluciones relacionadas con el manejo de servidores. Con la esperanza de que una solución del lado del cliente incurra en menos modificaciones en nuestra aplicación existente.
Bueno... esa es una pregunta difícil, ¡simplemente me encanta!
¿Por qué es complicado? Porque las reglas de ASP.NET config
son en su mayoría estáticas y se aplican a todo el proyecto. Es por eso que un tiempo de espera predeterminado de 60 minutes
afectará a todos los usuarios como política general.
La solución más directa (sin tocar las partes internas de su aplicación web) será definir 2 formularios: uno para usuarios regulares (se iniciará después de 1 hora) y otro formulario con tiempo de espera prolongado. Por supuesto, eso también hará un cambio en la interfaz de usuario (en lugar de una casilla de verificación, deberá usar un enlace que redirija al usuario a un formulario diferente). No es una solución muy elegante pero funcionará.
El problema es que cada sección de configuración solo puede tener una sola etiqueta <forms>
(lo cual es muy extraño: la directiva en sí está en plural). Siguiendo esta publicación , hay una manera de evitar este problema declarando 2 secciones con 2 carpetas de trabajo diferentes.
Entonces, sí, la solución elegante está fuera de la mesa, pero aún es posible y funcionará sin tocar ASP.NET internals
, lo que considero positivo. La solución general puede verse así
web.config
defina 2 carpetas de trabajo diferentes (usando la directiva <location>
) el archivo web.config
debería verse así:
<location path="/{MAIN_FOLDER}"> <system.web> <authentication mode="Forms"> <forms loginUrl="~/Account/Login" timeout="60" slidingExpiration="true" name="MYAUTHDV" cookieSameSite="None" requireSSL="true" /> </authentication> </system.web> </location> <location path="/{EXTENDED_LOGIN_FOLDER}"> <system.web> <authentication mode="Forms"> <forms loginUrl="~/ExtendedLogin" timeout="720" slidingExpiration="true" name="MYAUTHDV" cookieSameSite="None" requireSSL="true" /> </authentication> </system.web> </location>
Nuevamente, no es bonito pero es lógico: para 2 comportamientos diferentes, usamos 2 configuraciones diferentes para definir cómo debe reaccionar cada comportamiento. Cualquier otra solución solicitará una implementación personalizada y, en lo que a mí respecta, desea evitar esto en primer lugar.
Y como nota personal: comparta aquí su solución final para ayudar a otros también en el futuro. Gracias