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
Я не могу найти ничего более актуального по этому вопросу. Максимальный возраст сеанса можно установить минимум на 1 час.
Это бесполезно, когда компьютер используется в общей среде.
Было ли что-то на эту тему недавно, что решает проблему? По сути, мне нужно, чтобы пользователь забывался при закрытии браузера, если пользователь вошел через SSO.
Спасибо
Именно это и делал мой патч, но его откатили 
Вы можете изучить код и перенести его в плагин.
Совершенно не вопрос по Discourse:
Как вообще это происходит? Предположительно:
Хорошо, это угроза безопасности — я создам новую тему.
Люк, весь мир не живет в строго контролируемых офисных средах.
Возьмите, к примеру, сайты с открытым доступом в рамках академических учреждений и компьютеры в библиотеках и т. д. Многие не считают предоставление браузерного интерфейса угрозой безопасности.
Я полностью согласен с тем, что пользователи могут настроить своё оборудование и программное обеспечение так, чтобы избежать этой проблемы, но не все выполняют такую настройку. Поэтому, предоставляя пользователям форум, на котором мы знаем о наличии уязвимостей, если оборудование и программное обеспечение не настроены определённым образом, мы, по-моему, берём на себя ответственность.
Это справедливый вопрос. Среда, в которой часто используется общий рабочий стол, включает библиотеки, школы и больницы, хотя есть и другие. Как вы можете представить, ключевыми факторами являются: акцент на простоте использования (заставить первоклассников запомнить своё имя пользователя уже сложно, а теперь ещё и пароль, который не содержит их имя пользователя или личное имя, да ещё и с цифрами и специальными символами? ха!), отсутствие уникальных пользователей (в библиотеках часто нет имён пользователей, поскольку это может стать формой отслеживания пользователей, что многих в библиотечной среде не устраивает), а также требование очень быстрого отклика системы (в больницах нет времени на вход в систему через окна, когда кто-то умирает в приёмном отделении, поэтому они (по моему опыту) никогда не используют уникальные логины для каждого врача/медсестры/помощника).
В результате безопасность должна обеспечиваться самими приложениями (принцип эшелонированной обороны должен применяться в любом случае), и если какое-то приложение не обеспечивает эту безопасность, его просто не используют, так как безопасность всё ещё необходима.
Некоторые из таких сред могут не быть основной целью чего-то вроде Discourse, но при правильной настройке его можно легко использовать для облегчения работы в любой из этих сред. Дети и взрослые могут обмениваться информацией в рамках класса в группе, специфичной для этого класса. Хотя люди в библиотеках могут не иметь библиотечных логинов, они всё равно используют эти компьютеры для входа в системы по всему миру со своими собственными именами пользователей и паролями (хотя я бы никогда так не поступил). Больницы могли бы использовать его для внутрибольничной или межбольничной коммуникации, обмена идеями по определённым темам, процедурам и т. д., и во всех этих случаях, вероятно, у Discourse был бы полный вход для пользователей, публикующих сообщения.
Во многих таких случаях также может применяться единый вход (SSO), что при правильной настройке обеспечивает как повышенную безопасность, так и удобство. Проблема здесь в том, что постоянный cookie по умолчанию устанавливается на два (2) месяца (!!), что означает, что любой, кто подойдёт к этому компьютеру в ближайшие несколько месяцев, волшебным образом войдёт в систему как последний пользователь. Настройки можно изменить до минимума — одного (1) часа, но этого всё равно достаточно для случайных или злонамеренных проблем. Что можно сделать за пару месяцев?
Некоторые из этих сценариев могут показаться маловероятными, но они также просты и относительно дешевы. Некоторые люди, которые должны знать лучше, могут быть готовы «потерять» свой трёхлетний рабочий компьютер и получить новый взамен за $1000 от кого-то онлайн. Многие на этих форумах могут распознать такую схему, но не все честны или финансово обеспечены.
Называть это угрозой безопасности — это немного преувеличение. В средах с общими компьютерами уже есть варианты, гарантирующие, что один пользователь не сможет получить доступ к сеансу другого при переключении между компьютерами:
За последние два десятилетия я знаю только одну клиентскую среду, где реализация первого варианта была бы невозможна.