Tiempo de espera de la sesión

Entiendo tu razonamiento, Stephen, pero no es alarmista.

Los profesionales de TI lidiamos a diario con usuarios desprevenidos y/o con los llamados “usuarios inexpertos”. Intentamos implementar sistemas que puedan manejar cualquier eventualidad, y eso no es fácil. La identidad es un tema crucial en la actualidad, y fue solo mediante pruebas que descubrimos este problema; habría sido útil tener una advertencia, especialmente considerando que esto se ha discutido (y una vez corregido) desde 2016.

Mi esperanza era haber pasado por alto algo o que hubiera una mala configuración, pero ahora sé que funciona según lo diseñado. Buscaremos soluciones externas para sortear esto, la documentaremos para nuestros usuarios y, con suerte, en algún momento futuro otros ejercerán presión para que este problema se aborde dentro de Discourse.

¿Pero qué pasa si el usuario olvida cerrar el navegador? ¿Cómo funciona eso?

Sin embargo, tengo curiosidad, @falco, ¿por qué se revertió el parche de 2016? ¿Es un cambio inseguro?

Algunos puntos justos.

Sin embargo, me han sorprendido bastante algunos de tus ejemplos:

Hospitales: Los que he visitado en los últimos años definitivamente tienen bloqueos de sesión únicos, hasta el punto de que la enfermera que realiza los análisis de sangre debe volver a iniciar sesión después de alejarse solo unos segundos.

En la unidad de emergencias, puede haber algunos sistemas especializados con acceso a datos relevantes para emergencias, pero no deberían tener acceso a información de identificación personal (PII) ni al foro de chat del departamento.

Bibliotecas:
Todas las bibliotecas públicas locales (incluidas algunas de pueblos muy pequeños con personal poco familiarizado con la tecnología) tienen un ID de inicio de sesión genérico. (El mismo para todos los usuarios, publicado directamente en el monitor). También tienen una política de reinicio al alejarse, y se espera que todos, incluidos los niños, la cumplan. La secuencia de reinicio incluye borrar automáticamente el historial, la caché y las cookies del navegador.

No digo que una política más cuidadosa en el lado del discurso sea algo malo; simplemente, algunas de las situaciones “detonantes” enumeradas en este tema me preocupan, porque los mensajes del foro mal atribuidos son lo de menos entre sus problemas.

1 me gusta

La línea de tiempo es la siguiente:

  • 2012 - mayo de 2016: la cookie de sesión de Discourse siempre se configuraba como permanente.

  • mayo de 2016 - julio de 2016: la cookie de sesión de Discourse se configuraba como permanente por defecto, pero la configuración del sitio podía hacer que desapareciera al cerrar el navegador.

  • julio de 2016 - hoy: la cookie de sesión de Discourse se configura en 1440 horas y se renueva al usarse. La configuración del sitio puede controlar la duración máxima. Se eliminó la configuración de cookie de sesión del navegador.

Se eliminó en gran parte porque:

Puedo entender que compartir computadoras con extraños sea un concepto muy ajeno en algunas partes del mundo, incluso más con dispositivos personales móviles y ahora con la COVID-19, pero es muy común en lugares como bibliotecas escolares, lugares de trabajo, etc.

La mayoría de las veces, lo que hacen es apagar la computadora después de usarla. Apagar la computadora cierra el navegador, por lo que apagar la computadora termina indirectamente la sesión iniciada en las aplicaciones web.

Cuando el siguiente empleado llega para el siguiente turno, se enciende nuevamente la computadora y el navegador ya no contendrá las cookies basadas en la sesión anterior.

1 me gusta

Exacto, pero también creo que establecer este valor en algo como 0 debería, si es posible (si no genera demasiados problemas de soporte o no es demasiado difícil a nivel técnico), provocar el comportamiento de que “la cookie solo funciona durante la sesión del navegador”. Así que la descripción de la configuración del sitio podría indicar eso.

edad máxima de la sesión [predeterminado 1440 horas]

El usuario permanecerá conectado durante n horas desde su última visita. Cuando se establece en 0, el usuario será desconectado al cerrar el navegador.

3 Me gusta

Hospitales: Solo comparto lo que sé que se hace por experiencia. Estoy de acuerdo en que las pantallas se bloquean rápidamente, pero eso no es un cierre de sesión del navegador, y mucho menos del usuario del sistema operativo. ¿Pueden imaginarse qué haría la gente si la computadora tuviera que iniciar sesión, aplicar políticas, configurar conexiones de red, todo antes de cargar alguna aplicación para hacer lo que los médicos y enfermeras hacen mientras alguien está muriendo? En una línea similar, los inicios de sesión generalmente no son usuario/contraseña, sino más bien una tarjeta de identificación más un PIN corto, por la misma razón. Las salas de urgencias, quirófanos y la mayoría de las demás salas aún necesitan documentar información del paciente, por lo que donde he trabajado ha sido consistente en todas partes.

Bibliotecas: Existen políticas de reinicio al cerrar sesión y son efectivas siempre que los administradores limpien manualmente las cachés de todo lo que hay en la máquina, pero he visto tantos lugares que hacen lo contrario (una de las muchas razones por las que nunca usé estaciones de trabajo compartidas, en absoluto, nunca, con mis credenciales). He visto la misma configuración desafortunada en hoteles y cibercafés (o cafeterías) regularmente, por lo que vale la pena mencionarlo.

Me parece extraño que cualquier aplicación tenga esta configuración por defecto para todos los usuarios en todas las instalaciones. La seguridad no es el foco de la mayoría de las personas cuando configuran computadoras por primera vez, y es lo suficientemente compleja en general como para que sean profesiones de tiempo completo. Quienes configuran computadoras para el público deberían saber mejor, pero los navegadores tienen la idea de las cookies de sesión para facilitar a los desarrolladores de aplicaciones tener sesiones cuando sea intuitivo para los usuarios.

Exigir a los usuarios que entiendan que deben borrar manualmente las cookies de un sitio para cerrar sesión, cuando muchos sitios tanto agotan el tiempo de la sesión como la terminan al cerrar el navegador, parece exigir demasiado a las personas. No permitir la alternativa en absoluto, de modo que un usuario deba recordar usar el enlace específico de cierre de sesión de Discourse, se convierte en un problema cuando los usuarios pasan por alto el enlace por cualquier razón; por ejemplo:

  • El usuario se aleja de Discourse siguiendo un enlace.
  • El usuario se aleja de Discourse porque usa la pestaña para ir a otro lugar explícitamente.
  • El usuario cierra la pestaña con prisa para ir a una clase/reunión/etc.
  • El navegador se bloquea por cualquier razón.
  • El implementador de SSO tiene SAML para iniciar sesión, pero no sabe que la aplicación requiere un cierre de sesión explícito para terminar la sesión de la aplicación.

Además, dos (2) meses parecen un tiempo REALMENTE largo para que persista un inicio de sesión. Sé que algunos otros sitios hoy en día pueden hacer eso, o incluso más tiempo, pero los usuarios generalmente pueden controlar esto con esas casillas de verificación de “Computadora pública”, lo cual no aplica con SSO, o quizás en absoluto (no soy un gurú de Discourse).

Solo son más ideas para considerar.

Yo también tengo este problema y no sé cómo solucionarlo.

Gracias por esto, @codinghorror. ¿Cuál sería el proceso y los plazos para que esto sea evaluado e implementado?

No lo sé, depende de lo técnicamente difícil que sea el cambio. @sam, ¿cuál es tu opinión sobre la dificultad de lo que se propone en mi publicación anterior?

Creo que esta sería una función genial también, ya que permitiría a la gente saber quién está realmente en línea y quién solo está ausente.

Realmente necesitamos una nueva configuración de sitio aquí, ya que esto está desacoplado conceptualmente y haría que el código fuera difícil de razonar.

Específicamente, tendríamos que agregar mínimos aquí:

Y en algunos otros lugares para asegurar que el código siga funcionando.

La configuración que queremos es una opción discreta del tipo “cerrar sesión automáticamente de los usuarios cuando se cierra el navegador”.

La duración de la sesión sigue aplicando incluso si usas cookies de sesión (es decir, omites el parámetro expires).

Así que, por ejemplo, podrías decir:

  1. Si alguien cierra su portátil y lo vuelve a abrir 3 horas después, quieres que haya cerrado sesión.
  2. Si alguien cierra Chrome, quieres que haya cerrado sesión.

Son preocupaciones diferentes.

¿Quizás agregamos persistent_sessions con valor predeterminado true? “Cuando se establece en true, la sesión se mantiene cuando se cierra el navegador”. Este cambio tomaría unos 20 minutos.

4 Me gusta

Ok, si una configuración de sitio separada es mejor y es un cambio sencillo de 20 minutos, entonces digo que vamos a por ello.

2 Me gusta

¿Quizás en el futuro esta buena idea pueda ampliarse para una configuración “por usuario” en lugar de solo una “por sitio”?

1 me gusta

Esto ahora se realiza como una configuración por sitio.

https://review.discourse.org/t/feature-add-support-for-not-persistent-sessions/15171

Parece que es realmente una decisión del administrador. Es una característica de seguridad. A largo plazo, podríamos considerar una lista de direcciones IP permitidas que omitan esta limitación (por ejemplo, que las computadoras en la red corporativa permanezcan iniciadas sesión, mientras que las computadoras externas se desconecten automáticamente).

4 Me gusta

Creo que, por la naturaleza de esta solicitud, se trata de una función por usuario.

Algunos usuarios están en sus computadoras en casa o en la oficina y no necesitan que las cookies caduquen; por lo tanto, debería ser su decisión.

Otros usuarios podrían ser esos “nómadas” en cafeterías que usan computadoras compartidas, y querrían que sus sesiones caduquen.

La naturaleza de esta función es la seguridad de la cuenta de usuario, por lo que esta configuración se ha implementado típicamente como una opción o casilla de verificación por usuario al iniciar sesión.

vBulletin, por ejemplo, tenía esta función OOTB hace más de una década, y cuando iniciábamos sesión simplemente marcábamos una casilla si “nosotros, los usuarios”, queríamos que nuestra sesión persistiera.

La “seguridad” es para las cuentas de usuario, por lo que esto ha sido típicamente una configuración por usuario en el pasado, FYI.

Actualización: Cuando el usuario tiene una cuenta privilegiada (administrador, moderador, líder, etc.), también surge el problema más amplio de la seguridad general del sitio.

2 Me gusta

He visto esto implementado en muchos y muchos sitios; la implementación típica es:

Mantenerme conectado durante 30 días

[ INICIAR SESIÓN ]

No estoy seguro de cuándo llegaremos a esto, pero cuando lo hagamos, probablemente requeriremos una configuración del sitio para habilitarla. Hay complicaciones sobre dónde mostrar una casilla de verificación como esta si tienes inicios de sesión con redes sociales habilitados.

5 Me gusta

Gracias a todos. Su ayuda y comprensión son muy apreciadas.

1 me gusta

Gracias.

Sí, los inicios de sesión sociales nunca han sido “nuestra especialidad” debido al seguimiento de comportamiento; por lo tanto, mi perspectiva es mucho más estrecha que tu requisito mucho más amplio y complejo de dar soporte a los inicios de sesión sociales.

Gracias por todo el buen trabajo de tu equipo. Bien hecho.

4 Me gusta

En primer lugar: Muchas gracias por la solución rápida. Sin embargo, tengo una pregunta: ¿Sería posible convertir esto en una configuración por usuario con un valor predeterminado específico, para que los usuarios puedan optar por no participar a través de sus preferencias?

1 me gusta

Eso es exactamente lo que se discutió anteriormente como trabajo futuro posible, debido a que ambos requieren más esfuerzo y presentan algunos problemas molestos de diseño de la interfaz de usuario.

Además, queremos dejar la función disponible por un tiempo para ver si alguien encuentra algún problema técnico con la forma en que lo estamos haciendo.

3 Me gusta