My problem is when using SSO, so I really need to be a site setting.
When we detect that the SSO is down we nuke the cookies, but if the user left the pc with a valid SSO session, and other user opens it, he can be logged as someone else.
Setting expires to session may solve this.
Guys, I traced down making the _t cookie having a smaller expires.
The problem is that Discourse doesn’t seen to handle this very well atm.
We get a /login redirect but the it results in a ajax error instead of rendering the /login page properly.
Should I add special code to handle this expiration on the $.ajax function?
Probably best to consult with @sam first before proceeding, but in general, I would like it if people could set their site’s cookies to expire, say, weekly if they want that to happen.
The _t cookie is the wrong spot imo, we should start off by adding a column to user table that specifies when the auth token was created
Then it is trivial to expire cause a site setting can check for stale tokens when doing current user resolution
I do not like the idea of having this logic up to clients, cause clients can cheat
Since a timed cookie is a very bad idea, I have done a switch between Session and Permanent. Permanent still default, so no changes for most people.
My use case is enterprise communities, where sharing computers happen very often. People are used to services not persisting trough a browser restart or a computer restart and are posting on each other account 
.
Keep in mind we have 100k+ non tech employees 
Sure @sam will need to review.
The feature provided by @Falco got removed by commit a9207dafa
It would be great to bring back this feature. Because some users don’t perform an explicit logout by hitting the button. They’ll just close the browser assuming this would terminate their session as well. But the session will be still alive.
Please let the admin decide whether or not to use permanent sessions. It is a valuable feature for specific communities and use cases.
Now that my auth changes are all done a ton of stuff is easily on the table.
Personally I think the best change we can make here is:
We already have “maximum session age” which is set to 1440 hours, by heavily reducing it we can “sort of” approximate a session based cookie, except that unlike a session based cookie, closing and opening tabs will keep you logged on.
These 3 site settings and bits of UI needed for “stay signed in” option are probably doable in 1-2 days of work.
@codinghorror your call if
We only need the 1440 value as a site setting the other stuff can be ignored.
Does anyone know if this was ever implemented? I would like the ability to control when a user’s session times out if possible.
I can’t recall if we added the session duration site setting, do you remember @sam?
Yep, it’s there in admin:
The default is quite generous – around two months. I’m not sure if it supports fractional values, though – I can see that some people would prefer very short sessions (five to fifteen minutes), but the setting itself is in hours.
Yeah we have “maximum session age”: User will remain logged in for n hours since last visit
Set to 1440 by default
No puedo encontrar nada más actualizado sobre esto. La edad máxima de sesión se puede configurar como mínimo en 1 hora.
Esto no es útil cuando el ordenador se utiliza en un entorno compartido.
¿Ha habido algo reciente al respecto que resuelva el problema? En esencia, necesito que el usuario sea olvidado cuando se cierra el navegador y el usuario ha iniciado sesión con SSO.
Gracias
Eso es exactamente lo que hacía mi parche, pero fue revertido 
Puedes revisar el código y adaptarlo a un plugin.
Pregunta totalmente ajen a Discourse:
¿Cómo puede ocurrir esto siquiera? Presumiblemente:
OK, esto es una amenaza de seguridad: comenzaré un nuevo hilo.
Luke, el mundo entero no vive en entornos de oficina estrictamente controlados.
Piense en sitios de acceso abierto dentro de una institución académica y en máquinas dentro de bibliotecas, etc. Muchos no consideran que proporcionar una interfaz de navegador sea un riesgo de seguridad.
Estoy totalmente de acuerdo en que las personas pueden configurar su hardware y software para evitar este problema, pero no todos realizan esa configuración. Por lo tanto, al proporcionar un foro a nuestros usuarios donde sabemos que existen vulnerabilidades de seguridad si el hardware y el software no están configurados de cierta manera, en mi opinión, nos hacemos responsables.
Esa es una pregunta muy válida. Los entornos que suelen utilizar una experiencia de escritorio compartida incluyen bibliotecas, escuelas y hospitales, aunque hay otros. Como puedes imaginar, los factores determinantes incluyen un enfoque en la facilidad de uso (pedir a niños de primer grado que recuerden su nombre de usuario ya es difícil, pero ahora añadir una contraseña que no incluya su nombre de usuario ni su nombre personal, y que además contenga números y caracteres especiales… ¡ja!), la falta de usuarios únicos (las bibliotecas suelen carecer de nombres de usuario porque eso podría convertirse en una forma de rastreo de usuarios, algo que a muchos en entornos bibliotecarios les resulta incómodo), y la necesidad de respuestas muy rápidas por parte del sistema (los hospitales no tienen tiempo para que las ventanas de inicio de sesión se abran cuando alguien está muriendo en la sala de emergencias, por lo que, según mi experiencia, nunca tienen inicios de sesión únicos para cada médico, enfermera o asistente).
Como resultado, la responsabilidad de la seguridad recae en las aplicaciones (la defensa en profundidad debería aplicarse de todos modos), y cuando una aplicación no ofrece dicha seguridad, simplemente no se utiliza, ya que la seguridad sigue siendo un requisito indispensable.
Algunos de estos entornos pueden no ser el objetivo principal de algo como Discourse, pero podría utilizarse fácilmente para facilitar las operaciones en cualquiera de ellos si se configura correctamente. Niños y adultos pueden compartir información en un curso dentro de un grupo específico para ese curso. Aunque las personas en las bibliotecas puedan no tener credenciales de biblioteca, aún utilizan esas computadoras para iniciar sesión en sistemas de todo el mundo con sus propios nombres de usuario y contraseñas (aunque yo nunca haría algo así). Los hospitales podrían utilizarlo para comunicaciones intrahospitalarias o interhospitalarias, compartir ideas sobre temas específicos, procedimientos, etc., y en todos esos casos, Discourse presumiblemente tendría un inicio de sesión completo para los usuarios que publican.
En muchos de estos casos, el inicio de sesión único (SSO) también podría aplicarse, ofreciendo tanto mayor seguridad como comodidad si se configura adecuadamente. El problema aquí es que una cookie persistente configurada por defecto para dos (2) meses (!!) significa que cualquier persona que acceda a esa computadora en los próximos meses podrá entrar mágicamente como el usuario que estuvo allí la última vez. La configuración puede reducirse hasta una (1) hora, pero eso sigue siendo suficiente tiempo para problemas accidentales o maliciosos. ¿Qué se puede hacer en un par de meses?
Prestar tu computadora a un amigo.
Donarla a alguien que la necesite cuando ya no la uses.
Cansarte de tu computadora, apagarla, venderla en eBay, enviarla alrededor del mundo y que alguien más la utilice.
Sufrir un robo en tu hogar o lugar de trabajo.
Que un compañero de trabajo comprometa tu computadora durante la noche, iniciando desde medios externos y extrayendo cookies persistentes útiles.
Ser objetivo de alguien con una agenda, en Craigslist, redes sociales, etc., que te ofrezca comprar tu computadora por una cantidad insana para obtener lo que hay en ella con tu permiso.
Algunas de estas situaciones pueden sonar exageradas, pero también son fáciles y relativamente económicas. Algunas personas que deberían saber mejor podrían estar dispuestas a “perder” su computadora de trabajo de tres (3) años y obtener una nueva a cambio de 1.000 dólares de alguien en línea. Muchos en estos foros podrían ver a través de esto, pero no todo el mundo es honesto o tiene seguridad financiera.
Es un poco alarmista calificar esto como una amenaza de seguridad. Los entornos con computadoras compartidas ya cuentan con opciones para garantizar que un usuario no pueda acceder a la sesión de otro mientras se desplaza entre equipos:
Solo conozco un entorno de cliente en las últimas dos décadas donde la opción principal no habría sido posible.