SSO credentials validity / forced logout

[markwill (Mark Williams)]

What expectation should I have for how long a user can stay logged on before being prompted again?

I have implemented my own check in functions.php, integrating with the SSO plugin for WordPress. My logic seems pretty simple but I just noticed that a member who had a declined credit card (hence removing the user tag that my logic checks) was able to access my forum today. On further checking she last logged on a couple of days ago and, I guess, still seems to be. Her last logon date for WordPress is also a few days back.

Is it expected that her cached credentials should still be working. If so, is there any way to control the validity of the token and/or respond to a webhook to force a logout?

Thank you.

[simon]

@markwill

What expectation should I have for how long a user can stay logged on before being prompted again?

This is controlled by the Discourse maximum session age site setting. It sets the number of hours that users will remail logged into your site for. It defaults to 1440 hours (60 days.) You could try setting this to a lower value. If you set it too low it will seem like a bug to your users.

@markwill

I just noticed that a member who had a declined credit card (hence removing the user tag that my logic checks) was able to access my forum today. On further checking she last logged on a couple of days ago and, I guess, still seems to be.

This makes sense. You can log users out manually by going to their Discourse Admin page and clicking the ‘Log Out’ button that you’ll see near the top-right of the page. Another option for controlling this would be to add some code to your WordPress site that logs users out of Discourse when a membership expires.

[markwill (Mark Williams)]

Much appreciated, Simon. While I think 60 days is a too long for my scenarios (these are paying members and so they have an expectation we’d check they are still valid members), I do agree that reducing it too much can be a pain.

The final suggestion (find a way to log them out of Discourse when membership ends) is what I will research. I had seen the manual logout option but looking to totally automate all of this, so that seems like the right path.

Thanks again.

[mcwumbly (Dave McClure)]

@simon

This is controlled by the Discourse maximum session age site setting. It sets the number of hours that users will remail logged into your site for.

Hmm… the description of the site setting says (emphasis mine):

User will remain logged in for n hours since last visit

If I understand correctly, could remain logged in forever if they continue to visit the site periodically even after they lose their SSO credentials. For example, if the setting were set to 72 hours, as long as they continued to visit the site every day or two, they’d remain logged in. Am I interpreting that correctly?

[codinghorror (Jeff Atwood)]

Yes, that is true in my experience. There is no absolute timeout that forcefully logs someone out after a fixed period of time.

[markwill (Mark Williams)]

So is the implication of this that if someone cancels my membership and I want to be sure they can’t access my forum I will need to forcefully log them off (manually or via an API call)?

[sam (Sam Saffron)]

네, 그것이 권장 사항입니다

[markwill (Mark Williams)]

감사합니다. 페이스북 그룹(구독을 취소한 멤버를 수동으로 삭제해야 하는 구조)에서 전환해 온 입장에서, Discourse를 사용해도 구독을 취소한 멤버가 포럼에 접근하지 못하도록 수동으로 처리해야 한다는 점은 아쉬운 부분입니다. 이로 인해 질문이 하나 생겼습니다.

사용자가 더 이상 유효한 계정을 보유하지 않는 경우, 즉 로그인할 수 없는 경우, 해당 사용자가 Discourse에서 강제로 로그아웃되도록 보장할 수 있는 비수동(자동) 방식이 있을까요? 아무리 창의적인 방법이든 괜찮습니다.

SSO 메커니즘이 유효한 계정이 아님을 인식하여 로그인을 차단하는 것은 논리적으로 타당해 보이지만, 사용자가 단순히 포럼에 정기적으로(타임아웃 시간보다 짧은 간격으로) 접근하는 경우, 제가 수동으로 로그아웃 처리할 때까지 원할 만큼 오래 포럼에 접근할 수 있는 상황이 됩니다.

결국 마지막 선택지로, 사용자가 구독을 취소할 때 Discourse API를 호출하여 로그아웃 처리하는 플러그인을 직접 작성하는 것이 될 수도 있겠네요.

여기에 어떤 아이디어든 환영합니다. 알 수 있듯이, 이 작업을 수동으로 처리하는 것을 정말로 피하고 싶습니다

감사합니다.

[simon]

@markwill

최종 옵션으로, 사용자가 취소할 때 로그아웃을 수행하도록 Discourse API를 호출하는 플러그인을 작성하는 것이 될 것 같습니다.

/admin/users/<discourse_user_id>/log_out으로 API 요청을 보낼 수 있습니다. WP Discourse 플러그인은 이 라우트를 사용하여 WordPress 로그아웃을 Discourse와 동기화합니다. 다음 함수의 대부분 코드를 복사해서 사용할 수 있을 것입니다: wp-discourse/lib/sso-provider/discourse-sso.php at main · discourse/wp-discourse · GitHub.

[markwill (Mark Williams)]

심온님, 정말 감사드립니다. 확인해 보겠습니다.

다만 한 걸음 물러서서 생각해보면, 이건 일종의 문제가 아닌가요? 이 사안의 중요성에 대해서는 논쟁이 있을 수 있겠지만, 더 이상 유효한 계정이 없음에도 불구하고 사용자가 끝없이 포럼에 접근할 수 있는 플랫폼을 다른 곳에서 본 적이 없습니다.

여기서 권한 있는 출처가 Discourse가 아니라 WordPress라고 보는 관점이라면, 어느 정도 이해가 갑니다. 그렇다면 그 논리를 구현할 가장 적합한 곳은 SSO 플러그인일 가능성이 높습니다.

이 부분에 대한 전반적인 고찰이 궁금합니다. 특정 기간이 지나거나 WordPress 계정이 “유효하지 않은” 상태가 되었을 때 로그아웃을 강제하는 시나리오는 유효한 경우라고 생각하는데, 맞나요?

수동 단계를 피하고 싶고, 가능하면 코드를 작성하는 것도 피하고 싶어서 여기서는 그저 아이디어를 나누어 보고 있습니다

[simon]

@markwill

여기서 권위 있는 소스가 Discourse가 아니라 WordPress라는 주장을 받아들일 수 있을 것 같습니다. 그렇다면 논리를 추가할 최적의 위치는 SSO 플러그인일 가능성이 높다는 뜻이 되겠네요.

네, 이 문제는 WordPress에서 처리해야 합니다. WordPress에서 사용자가 _삭제_되면 WP Discourse 플러그인이 해당 사용자를 Discourse에서 로그아웃시키는 것이 합리적이라고 생각하지만, 이것이 당신의 문제를 해결할지는 확신할 수 없습니다. 제 추측에 따르면, 사이트에서 회원 자격이 만료되면 해당 사용자가 WordPress 사이트에서 삭제되지 않습니다. 회원 자격이 만료될 때 사용자를 Discourse에서 로그아웃시키려면, 회원 플러그인이 회원 자격 만료 시 트리거하는 액션에 연결되는 코드를 사이트에 추가해야 할 것입니다.

[markwill (Mark Williams)]

다시 한번 감사드립니다, @simon. 말씀하신 내용이 타당하지만, 한 번 더 의견을 말씀드려도 될까요

여기에는 두 가지 요인이 작용하는 것 같습니다. 하나는 계정의 유효성(즉, 활성 회원인지 여부)이고, 다른 하나는 Discourse에서 토큰의 유효성입니다.

전자의 경우, 이 부분은 WordPress가 관리해야 한다는 데 전적으로 동의하며, 시간이 허락하는 대로 조사해 보겠습니다.

그러나 Discourse 측에서 활성/유효한 토큰에 대한 문제도 있습니다. 이것이 최우선 순위가 아닐 수 있다는 점은 이해하지만, “강제 로그인” 기간을 설정할 수 있는 옵션(기본값은 꺼짐)에 대해선 일리가 있다고 봅니다. 즉, 사용자가 최근 로그인했는지 여부와 무관하게 x일 후 사용자 로그인 토큰이 만료되도록 하는 방식입니다.

다시 말씀드리지만, 여기서는 단순히 아이디어를 정리해 보는 중이지만, 사용자가 유효한 계정을 보유하고 있든 아니든 관계없이 로그아웃을 강제하는 옵션이 가치가 있다고 생각합니다.

[Cardinalflyer (Keith Peterson)]

@simon

/admin/users/<discourse_user_id>/log_out

WordPress를 사용하지 않고 있으므로 웹 링크를 통해 이 작업을 수행하려고 합니다. 다음과 같은 방식으로 수행할 수 있을까요?

https://community.mysite.com/admin/users/100004/log_out

제 경우 404 오류가 발생하고 있으며, 사용자는 로그아웃되지 않습니다.

URL이 작동하도록 만들 수 있다면 PHP에서 curl 또는 file_get_contents 명령을 사용하여 강제 로그아웃을 시도해 보려 합니다…

[simon]

@Cardinalflyer

나에게는 404 오류가 발생하고, 사용자는 로그아웃되지 않습니다.

라우트로 인증된 POST 요청을 보내야 합니다. 사용자가 링크를 클릭할 때 로그아웃되도록 설정할 수 있지만, 서버에서 요청을 처리해야 합니다.

[Cardinalflyer (Keith Peterson)]

감사합니다! 인증이 된 건가요? 이 부분을 조사해보니 PHP에서 인증된 게시물을 보내면 헤더에 다음과 같은 내용을 전송하는 것 같습니다:

'Authorization: OAuth '.$accesstoken;

여기저기서 몇 가지 힌트를 찾아볼 수 있을 것 같아서 계속 조사해볼 예정입니다.

하지만 PHP로 동작하는 코드 스니펫을 누군가가 가지고 있다면 정말 좋겠습니다! https://docs.discourse.org/ 의 인증 섹션에 있는 예제가 제게는 구문 오류를 반환하는데… 아, 그게 유닉스 명령어였군요!

PHP에 도움이 될 만한 힌트는 무엇이든 환영합니다!

[simon]

@Cardinalflyer

하지만 누군가 작동하는 PHP 코드 조각을 가지고 있다면 정말 좋겠어요!

이전 게시글의 링크가 시작하기에 충분할 것입니다: wp-discourse/lib/sso-provider/discourse-sso.php at main · discourse/wp-discourse · GitHub. WordPress 사이트에서 요청을 보내지 않는 경우, wp_remote_post 요청을 보내는 다른 방법을 찾아야 합니다.

[Cardinalflyer (Keith Peterson)]

단순한 PHP 명령어를 사용해서 거의 성공한 것 같습니다. 코드는 아래와 같습니다. 사용자 이름 선택은 이 게시글에서 가져왔습니다.

이 응답을 받고 있는데… 이게 무슨 의미인가요? SSL 프로토콜 버전 문제인 것 같네요?

error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version

제 코드는 다음과 같습니다:

    $url = "https://community.mysite.com/admin/users/100004/log_out";
    $headers = array( 'Api-Key' => 'd412mylongadminkeyaadcd',
    				  'Api-Username' => 'system',
    				  );

	$ch = curl_init();
	curl_setopt($ch, CURLOPT_URL, $url);

[편집: 아래 줄들도 추가했는데, 변화 없음:]
	curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
	curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
[/편집]

	curl_setopt($ch, CURLOPT_POST, true);
	curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);
    $data = curl_exec($ch);
    if (curl_errno($ch)) {
        echo curl_error($ch);
    }
    curl_close($ch);

[simon]

@Cardinalflyer

이 응답을 받고 있습니다… 이게 무슨 의미인가요? SSL 프로토콜 버전 문제인 것 같은데?

WordPress를 사용하고 계시므로 wp_remote_post 함수로 요청을 보내 보실 수 있습니다. 그러면 curl 옵션을 직접 다룰 필요가 없습니다.

[Cardinalflyer (Keith Peterson)]

감사합니다만, 저는 워드프레스를 사용하지 않습니다. 지난 10년간 직접 개발한 멤버십 관리 시스템에서 PHP로 이 작업을 수행하려고 하고 있습니다.

[pfaffman (Jay Pfaffman)]

PHP 라이브러리가 Discourse의 HTTPS 인증서를 인식하지 못한 것 같습니다. 해당 오류를 검색해 보시는 것이 좋습니다.