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
https://github.com/discourse/discourse/pull/4226
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로 로그인한 상태입니다.
감사합니다.
제 패치가 정확히 그 일을 수행했지만, 되돌려졌습니다 
코드를 확인하고 플러그인으로 이식할 수 있습니다.
완전히 디스코urses와 무관한 질문입니다:
이런 일이 어떻게 발생하는 걸까요? 아마도 다음과 같은 상황일 것입니다:
네, 이건 보안 위협이네요. 새 스레드를 시작하겠습니다.
루크, 전 세계가 엄격히 통제된 사무실 환경에서만 운영되는 것은 아닙니다.
학술 기관 내 오픈 액세스 사이트나 도서관 내 기기 등을 생각해 보세요. 많은 사람들이 브라우저 인터페이스를 제공하는 것을 보안 위험으로 인식하지 않습니다.
사람들이 하드웨어와 소프트웨어를 이 문제가 발생하지 않도록 구성할 수 있다는 데는 전적으로 동의합니다. 하지만 모두가 그렇게 구성하지는 않습니다. 따라서 하드웨어와 소프트웨어가 특정 방식으로 구성되지 않으면 보안 결함이 있다는 것을 알고 있으면서도, 사용자에게 포럼을 제공하는 것은 책임이 있다고 생각합니다.
정당한 질문입니다. 공유 데스크톱 환경을 주로 사용하는 곳에는 도서관, 학교, 병원 등이 있지만, 그 외에도 여러 곳이 있습니다. 짐작할 수 있듯이, 주요 동인에는 사용의 용이성에 대한 초점이 포함됩니다. (1학년 학생들에게 사용자 이름을 기억하라고 하는 것만으로도 충분히 어려운데, 여기에 사용자 이름이나 개인 이름이 포함되지 않고 숫자와 특수 문자가 포함된 비밀번호까지 요구하면? 하!), 고유한 사용자가 없는 문제(도서관은 사용자 이름이 일종의 사용자 추적 수단이 될 수 있기 때문에 사용자 이름을 보통 사용하지 않으며, 이는 도서관 환경에서 많은 사람들에게 불쾌감을 줍니다), 그리고 시스템의 매우 빠른 응답에 대한 요구 사항(누군가가 응급실에서 죽어가고 있을 때 로그인 창을 기다릴 시간이 없으므로, 병원에서는 의사/간호사/보조원별로 고유한 로그인을 거의 사용하지 않습니다) 등이 있습니다.
그 결과, 보안은 애플리케이션의 몫이 됩니다(어쨌든 다층적 방어가 적용되어야 하므로), 그리고 특정 애플리케이션이 이러한 보안을 제공하지 않는다면, 보안이 여전히 요구되므로 해당 애플리케이션은 단순히 사용되지 않습니다.
이러한 환경 중 일부는 Discourse와 같은 것의 주요 대상이 아닐 수 있지만, 올바르게 설정된다면 이러한 환경 중 어디에서든 운영을 촉진하는 데 쉽게 사용될 수 있습니다. 어린이와 성인이 특정 수업에 특화된 그룹 내에서 수업에 관한 정보를 공유할 수 있습니다. 도서관에서 사람들이 도서관 로그인을 가지고 있지 않을지라도, 그들은 여전히 이러한 컴퓨터를 사용하여 자신의 사용자 이름/비밀번호로 온갖 시스템에 로그인합니다(저는 절대 그렇게 하지 않겠지만요). 병원에서는 병원 내 또는 병원 간 통신, 특정 주제, 절차 등에 대한 아이디어 공유에 이를 사용할 수 있으며, 이러한 모든 경우에서 Discourse는 게시하는 사용자를 위해 완전한 로그인을 가질 것으로 예상됩니다.
이러한 많은 경우에서 단일 로그인(SSO)도 적용될 수 있으며, 올바르게 설정되면 보안과 편의성을 모두 높여줍니다. 여기의 문제는 기본값이 두(2)개월(!)로 설정된 영구 쿠키입니다. 이는 향후 몇 달 동안 그 컴퓨터에 오는 누구나 이전에 있던 사용자로 마법처럼 로그인하게 만듭니다. 이 설정은 한(1)시간으로 낮출 수 있지만, 그건 여전히 실수나 악의적인 문제를 일으키기에 충분한 시간입니다. 두 달 동안 무엇을 할 수 있을까요?
컴퓨터를 친구에게 빌려줄 수 있습니다.
필요할 때 필요 없는 사람에게 컴퓨터를 기증할 수 있습니다.
컴퓨터가 싫어져서 전원을 끄고 eBay에서 팔아 전 세계로 배송한 후 누군가 그것을 사용하게 할 수 있습니다.
집이나 직장에서 침입 및 도난을 당할 수 있습니다.
동료가 밤새 여러분의 컴퓨터를 compromiser하여 외부 미디어로 부팅하고 유용한 영구 쿠키를 빼돌릴 수 있습니다.
Craigslist/소셜 미디어 등에서 여러분의 컴퓨터를 터무니없는 금액에 사겠다고 제안하며 여러분의 허락으로 그 안에 있는 것을 얻으려는 의도를 가진 누군가의 표적이 될 수 있습니다.
이 중 일부는 터무니없어 보일 수 있지만, 또한 쉽고 비교적 저렴합니다. 더 잘 알아야 할 몇몇 사람들은 온라인에서 누군가로부터 1,000달러를 받는 대가로 3년 된 업무용 컴퓨터를 “잃어버리고” 새 것을 받는 것에 동의할 수 있습니다. 이 포럼의 많은 사람들이 그 점을 꿰뚫어 볼 수 있지만, 모든 사람이 정직하거나 재정적으로 안정적이지는 않습니다.
이것을 보안 위협이라고 부르는 것은 다소 과장된 표현입니다. 공용 컴퓨터 환경에서는 이미 사용자가 컴퓨터를 이동할 때 다른 사용자의 세션에 접근하지 못하도록 보장하는 여러 옵션이 있습니다:
지난 20년간 제가 알기로는 상위 옵션(시크릿 탭)이 불가능했던 클라이언트 환경은 단 한 곳뿐이었습니다.