스ตี븐, 당신의 논리는 이해하지만, 이는 과장된 경고가 아닙니다.
IT 담당자들은 매일 인지하지 못하는 사용자나 흔히 말하는 '무지한 사용자’를 상대합니다. 우리는 모든 상황을 감당할 수 있는 시스템을 구축하려 노력하지만, 쉬운 일은 아닙니다. 요즘에는 신원 확인이 매우 중요한 문제이며, 이 문제가 발견된 것은 테스트를 통해서였습니다. 특히 이 문제는 2016년부터 논의되어 왔고(한 번은 수정되었었습니다) 사전에 알려주었더라면 좋았을 텐데 싶습니다.
저희는 제가 무언가를 놓쳤거나 구성이 잘못되었다고 희망했지만, 이제 이것이 의도된 대로 작동하고 있다는 것을 알게 되었습니다. 우리는 이 문제를 우회할 수 있는 외부적인 방법을 모색하고 사용자를 위해 문서화할 것이며, 미래에 다른 사람들이 디스커스(Discourse) 내에서 이 문제를 해결하도록 압박을 가해주기를 희망합니다.
하지만 사용자가 브라우저를 닫는 것을 잊으면 어떻게 되나요? 어떻게 작동하나요?
@falco 님, 2016년 패치가 왜 되돌려졌는지 궁금합니다. 안전하지 않은 변경 사항이었나요?
일부 공정한 지적이긴 합니다.
다만 몇 가지 예시에는 꽤 충격을 받았습니다:
병원: 최근 몇 년간 제가 이용한 병원들은 확실히 고유한 세션 차단(lockout) 정책을 시행하고 있었습니다. 혈액 검사를 담당하는 간호사가 불과 몇 초간 자리를 비웠다가 돌아와도 다시 로그인해야 할 정도였죠.
응급실: 응급실에는 응급 관련 데이터에 접근할 수 있는 특수화된 시스템이 있을 수 있지만, PII(개인 식별 정보)나 부서 내 채팅 포럼에는 접근할 수 없어야 합니다.
도서관:
제가 사는 지역의 모든 공공 도서관(매우 작은 마을이나 IT에 익숙하지 않은 직원이 있는 곳도 포함)은 일반 로그인 ID를 사용하고 있습니다. (모든 이용자가 동일한 ID를 사용하며, 모니터에 바로 게시되어 있습니다.) 또한 자리를 비울 때 재시작하는 정책을 시행하고 있으며, 아이들을 포함한 모든 사람이 이를 준수할 것으로 기대합니다. 재시작 과정에는 브라우저 히스토리/캐시/쿠키를 자동으로 지우는 단계도 포함됩니다.
디스코르스(Discourse) 측에서 더 세심한 정책을 마련하는 것이 나쁘다는 말은 아닙니다. 다만 이 주제에서 언급된 몇 가지 “분쟁을 유발하는” 상황들이 걱정되는 이유는, 잘못된 포스트 게시자 귀속 문제가 해당 문제들 중 가장 경미한 수준이기 때문입니다.
타임라인은 다음과 같습니다:
2012년 ~ 2016년 5월: Discourse 세션 쿠키가 항상 영구적으로 설정됨
2016년 5월 ~ 2016년 7월: Discourse 세션 쿠키가 기본적으로 영구적으로 설정되며, 사이트 설정을 통해 브라우저 종료 시 삭제하도록 변경 가능
2016년 7월 ~ 현재: Discourse 세션 쿠키가 1440시간으로 설정되며, 사용 시 갱신됨. 사이트 설정으로 최대 수명 제어 가능. 브라우저 세션 쿠키 설정 제거됨
대부분 다음과 같은 이유로 제거되었습니다:
일부 지역에서는 낯선 사람과 컴퓨터를 공유하는 개념이 매우 낯설 수 있고, 모바일 개인 기기와 최근 코로나19로 인해 더욱 그럴 수 있다는 점은 이해합니다. 하지만 학교 도서관, 직장 등 일부 장소에서는 여전히 매우 흔한 일입니다.
대부분의 경우 사용자는 사용 후 컴퓨터를 끕니다. 컴퓨터를 끄면 브라우저도 닫히므로, 컴퓨터를 끄는 행위는 웹 앱의 로그인된 세션을 간접적으로 종료시킵니다.
다음 교대조 직원이 컴퓨터를 켜면 브라우저에는 더 이상 세션 기반 쿠키가 포함되어 있지 않게 됩니다.
맞습니다. 다만 이 값을 0으로 설정할 경우(지원 이슈가 너무 많거나 기술적으로 너무 어렵지 않다면) "쿠키가 브라우저 세션 동안에만 작동"하도록 하는 것이 좋을 것 같습니다. 그러면 사이트 설정의 설명에 이를 명시할 수 있습니다.
최대 세션 수명 [기본값 1440시간]
사용자는 마지막 방문 이후 n시간 동안 로그인 상태를 유지합니다. 0으로 설정하면 브라우저를 닫을 때 로그아웃됩니다.
병원: 저는 경험을 통해 알게 된 사실만 공유합니다. 화면이 빠르게 잠긴다는 점에는 동의하지만, 이는 브라우저 로그아웃은커녕 OS 사용자 로그아웃도 아닙니다. 누군가가 목숨을 잃고 있는 동안, 의사와 간호사가 업무를 수행하기 위해 특정 애플리케이션을 불러오기 전에 컴퓨터가 로그인하고, 정책을 적용하고, 네트워크 연결을 설정하는 과정을 상상해 보세요. 사람들이 어떤 행동을 할지 생각할 수 있을까요? 비슷한 맥락에서, 로그인 방식은 보통 사용자 이름/비밀번호보다는 같은 이유로 배지(직원증)와 짧은 PIN 번호를 사용하는 경우가 많습니다. 응급실(ER), 수술실(OR) 및 대부분의 다른 병동에서도 여전히 환자 정보를 기록해야 하므로, 제가 업무를 수행했던 곳에서는 어디든 일관성이 있었습니다.
도서관: 로그아웃 시 재시작 정책은 존재하며, 관리자가 해당 컴퓨터의 모든 캐시를 수동으로 정리하는 한 효과적입니다. 하지만 제가 본 곳 중에는 그렇지 않은 곳도 많았습니다(이것이 제 크레덴셜을 사용해 공유 워크스테이션을 단 한 번도, 결코 사용하지 않은 여러 이유 중 하나입니다). 참고로, 호텔과 인터넷 카페(또는 커피숍)에서도 같은 불행한 설정을 정기적으로 볼 수 있었습니다.
모든 설치 환경의 모든 사용자에게 이 설정을 기본값으로 적용하는 것이 어떤 애플리케이션에서든 이상하게 느껴집니다. 컴퓨터를 처음 설정할 때 대부분의 사람들이 보안에 집중하지는 않으며, 일반적으로 충분히 복잡하여 전문 직업으로 삼는 사람들조차 있습니다. 대중을 위해 컴퓨터를 설정하는 사람들은 더 잘 알고 있어야 하지만, 브라우저에는 사용자가 직관적으로 느낄 수 있도록 애플리케이션 개발자가 세션을 쉽게 관리할 수 있게 해 주는 세션 쿠키 개념이 있습니다.
많은 사이트가 세션 타임아웃을 적용하거나 브라우저 종료 시 세션을 종료하는 상황에서, 로그아웃하려면 사이트의 쿠키를 수동으로 지워야 한다는 사실을 사용자가 이해해야 한다는 요구는 사람들에게 너무 많은 것을 요구하고 있는 것 같습니다. 사용자가 특정 Discourse 로그아웃 링크를 기억해야만 하는 대안을 전혀 허용하지 않는 것은, 사용자가 어떤 이유로든 링크를 놓칠 경우 문제가 됩니다. 떠오르는 사례들:
또한, 2개월은 로그인 유지 기간으로 정말로 긴 시간입니다. 요즘 다른 사이트들이 그렇게 하거나 더 길게 설정하는 경우도 알고 있지만, 사용자는 보통 “공용 컴퓨터” 체크박스를 통해 이를 제어할 수 있습니다. 하지만 SSO의 경우 이것이 적용되지 않거나, 아예 적용되지 않을 수도 있습니다(Discourse 전문가가 아니므로 정확히는 모릅니다).
고려해 볼 만한 추가적인 생각들입니다.
저도 같은 문제를 겪고 있는데, 해결 방법이 잘 모르겠습니다.
@codinghorror 감사합니다. 이 건을 검토하고 구현하는 과정과 소요 기간은 어떻게 될까요?
잘 모르겠어요. 변경 사항의 기술적 난이도에 따라 달라질 것 같아요. @sam, 제 위에서 작성한 게시물에 제안된 내용의 난이도에 대해 어떻게 생각하시나요?
이 기능도 꽤 좋을 것 같아요. 실제로 온라인 상태인 사람이 누구이고, 단순히 자리를 비운(afk) 상태인 사람이 누구인지 알 수 있게 되니까요.
여기 새로운 사이트 설정이 정말 필요합니다. 이 기능은 개념적으로 분리되어 있고, 이대로 두면 코드 이해가 어려워지기 때문입니다.
구체적으로, 여기 최소값(minimums)을 추가해야 합니다:
그리고 코드가 계속 정상적으로 작동하도록 몇몇 다른 곳에도 추가해야 합니다.
우리가 원하는 설정은 브라우저가 닫힐 때 사용자를 자동으로 로그아웃하는 기능과 관련된, 다소 이산적인(discreet) 설정입니다.
세션 쿠키를 사용하더라도(즉, expires를 생략하더라도) 세션 길이는 여전히 적용됩니다.
예를 들어 다음과 같은 경우가 있습니다.
이것들은 서로 다른 관심사(concerns)입니다.
persistent_sessions라는 설정을 기본값 true로 추가하는 것은 어떨까요? “true로 설정하면 브라우저가 닫혀도 세션이 유지됩니다.” 이 변경 사항은 20분 정도면 끝납니다.
별도의 사이트 설정이 더 나은 선택이고, 20분이면 쉽게 바꿀 수 있다면, 그렇게 해보자고 말하고 싶다.
미래에 사이트별 설정만이 아니라 사용자별 설정으로 확장될 수 있는 좋은 아이디어가 아닐까요?
이제 사이트별 설정으로 처리됩니다.
https://review.discourse.org/t/feature-add-support-for-not-persistent-sessions/15171
개인적으로 이것은 관리자 선택 사항이라고 생각합니다. 보안 기능이기 때문입니다. 장기적으로는 제한을 우회할 IP 주소 허용 목록을 고려할 수 있습니다(예를 들어, 기업 네트워크 내 컴퓨터는 로그인 상태를 유지하고, 외부 컴퓨터는 자동으로 로그아웃되도록 하는 것).
이 요청의 성격상 사용자별(per user) 기능이라고 생각합니다.
일부 사용자는 집이나 사무실에서 자신의 컴퓨터를 사용하며, 쿠키가 만료될 필요가 없습니다. 따라서 이는 사용자의 선택에 맡겨야 합니다.
다른 사용자는 카페 등에서 공용 컴퓨터를 사용하는 '노마드(nomads)'일 수 있으며, 이들은 세션이 만료되기를 원할 것입니다.
이 기능의 본질은 사용자 계정의 보안이므로, 일반적으로 로그인 시 사용자 설정이나 사용자 체크박스 형태로 구현되어 왔습니다.
예를 들어 vBulletin은 10년 이상 전부터 기본(OOTB)으로 이 기능을 갖추고 있었고, 로그인 시 '사용자’가 세션을 유지하기를 원하면 단순히 상자를 체크하면 되었습니다.
참고로 '보안’은 사용자 계정을 위한 것이므로, 과거에는 일반적으로 사용자별 설정으로 구현되어 왔습니다.
업데이트: 사용자가 특권 계정(관리자, модератор, 리더 등)을 가지고 있다면, 전체 사이트 보안이라는 더 큰 문제도 함께 고려해야 합니다.
많은 사이트에서 이렇게 구현된 것을 본 적이 있습니다. 일반적인 구현 방식은 다음과 같습니다:
30일간 로그인 상태 유지
[ 로그인 ]
언제 이 기능을 추가할지는 아직 알 수 없지만, 해당 작업을 진행할 때 사이트 설정을 통해 이를 활성화할 수 있도록 할 가능성이 높습니다. 소셜 로그인을 활성화한 경우, 이러한 체크박스를 어디에 표시해야 하는지에 대한 복잡한 문제가 발생할 수 있습니다.
모두의 도움과 이해에 진심으로 감사드립니다.
감사합니다.
네, 소셜 로그인은 행동 추적 문제로 인해 저희와는 맞지 않는 부분이었습니다. 따라서 소셜 기능을 지원해야 하는 여러분의 훨씬 더 크고 복잡한 요구 사항에 비해 제 관점은 훨씬 좁습니다.
팀 여러분의 훌륭한 작업에 감사드립니다. 잘하셨습니다.
우선 빠른 수정에 진심으로 감사드립니다. 다만 한 가지 질문이 있습니다. 이 기능을 사용자별 설정으로 만들어 기본값을 지정하고, 사용자가 설정 화면에서 비활성화할 수 있도록 하는 것이 가능할까요?
위에서 논의한 대로, 이는 둘 다 더 많은 노력이 필요하고 일부 까다로운 UI 디자인 문제가 있기 때문에 향후 가능한 작업으로 언급된 내용입니다.
또한, 우리가 이 기능을 어떻게 구현하고 있는지 기술적인 문제가 있는지 확인해 볼 수 있도록, 이 기능을 잠시 동안 사용 가능하게 두려고 합니다.