이 플러그인은 카테고리에 추가 보안 설정을 적용하여 사용자가 자신의 토픽에만 접근할 수 있도록 합니다. 또한, 해당 카테고리의 모든 토픽을 볼 수 있는 하나 이상의 그룹을 지정할 수도 있습니다. 이는 일반적으로 공개 커뮤니티 내에서 비공개 지원을 제공하는 데 사용됩니다.
배경
우리는 수천 개의 카테고리를 생성하지 않고도 Communiteq의 클라이언트에게 지원을 제공할 수 있는 더 통합된 방식을 찾고 있었습니다. 또한, 그룹 인박스(Group Inboxes)는 너무 부수적으로 느껴지고 기본적으로 누군가가 그룹 인박스에 메시지를 남길 때마다 “새로운 DM” 배지가 표시되므로 이를 피하고 싶었습니다.
"EVERYONE"이(가) 접근할 수 없도록 확인하세요.
광범위한 접근이 필요해야 한다면, 이 값을 trust_level_0으로 설정하세요.
설정값
전역 사이트 설정도 몇 가지 있습니다:
private topics permitted groups : 멤버의 게시물이 일관되게 접근 가능하도록 할 그룹을 지정합니다. 이를 사용하면 스태프나 지원 스태프의 게시물이 비공개 카테고리에 있더라도 접근 불가능해지는 것을 방지할 수 있습니다. 기본 시스템 사용자의 게시물도 항상 표시됩니다. 이러한 게시물이 표시되기를 원한다면, 카테고리 소개 게시물이 기본 시스템 사용자 또는 이 그룹의 사용자로부터 작성되었는지 확인해야 합니다.
private topics admin sees all: 활성화되면 관리자 사용자는 비공개 카테고리에 있더라도 모든 토픽에 접근할 수 있습니다. 기밀 데이터가 우연히 노출되는 것을 방지하려면 이 설정을 비활성화하세요.
주의사항
이 플러그인은 토픽 목록, 게시물 스트림, 검색, 사용자 요약, 사용자 활동, 찾을 수 없는 페이지, 팔로우 알림 및 원문(raw)에서 토픽을 필터링합니다.
토픽은 배지에 포함되지만, 비공개 카테고리에 대해서는 배지가 부여되지 않으므로, 카테고리 보안 그룹에서 everyone을(를) 제거하고 대신 trust_level_1을(를) 추가해야 합니다.
이 플러그인은 매우 새로우며 아직 광범위하게 테스트되지 않았습니다.
가능한 "누수"는 다음과 같습니다:
One small observation - it appears that even admins can’t see these responses if staff or admins aren’t specified in the groups. Is this intentional?
I just created two test categories, one where admin was specified in the groups, the other where it wasn’t. Moving the topic from one category to the other means I lost visibility on said topic. The topic name is leaked by the Delete Category button though, which shows and names the topic still present which blocks deletion.
Yes, I did intentionally put not any effort in treating admin in any special way (in the spirit of this and this), since it’s trivial to add the group and it’s really helpful in testing when admin is subject to the regular security rules.
On the other hand I did not put any effort into closing any “leaks” for admin users either, especially because it could cause problems when administering the forum.
It’s a good remark though and I’ll make it explicit in the start post of this topic.
It’s rather unprecedented for content to be present which admins can’t see by default.
If you don’t want to display those topics to admins unless their group is explicitly named, can we at least include something in the topic view letting them know that there are private topics present which they won’t be able to see? It could be anything from showing the topic names in the topic listing but preventing the topics themselves from being opened (the latter is the case now, links just don’t work), to including a notice at the top of a category to tell the admin that private topics are enabled, but they don’t currently have permissions to view them.
I have added a private topics permitted groups setting to designate groups whose members’ posts are consistently visible. You can use this so posts from staff or support staff are not subject to being inaccessible, even when they’re in a private category. Posts from the default system user are also always being shown. You should make sure that the category introductory posts are either from the default system user or from a user in this group.
I have also made the functionality that admins can see everything the default. To revert to the old behavior, you can turn off private topics admin sees all. @stephen
It is designed to deliver the same level of confidentiality as a group inbox, i.e. only the topic author and a defined group will be able to access the topics under its regime, plus admins and anyone who has (gained) access to the database.
Please note that the plugin is 4 days old and is still labeled ‘beta’ so it’s not extensively field tested yet.
Maybe I should put a bounty on it so we can get it to battle-tested level more quickly: whoever finds a way to bypass it and can access a topic as an unauthorized regular user gets 2 months of free Communiteq hosting. One month for partial leakage like a topic title.
The only thing I’ve seen so far (and it’s very mild) is on the user profile summary, where you can see the user has created a topic in one of those categories via Top Categories. Neither link (to category or count) exposes the topics though.
Edit: I did find one actually, but it’s through an official plugin rather than core. discourse-follow will leak the title and URL to private topics.
I found two more title/URL leaks, one is related to the other.
Steps were:
Topic is created by user 1 in a different category and interacted with by user 2, which sets that topic as watched.
Topic is moved to private topics category
Topic sees further activity which triggers notification of topic to user 2 despite them being unable to access it. (leak a, minor)
Notification leads to usual " Oops! That page doesn’t exist or is private." showing several protected topic titles in the Recent block to user 2. (leak b, slightly more severe)
The Discourse was indeed in dire need of this. The Create/Reply feature, inherent in most forum platforms, was truly requisite in its integral framework. I extend my gratitude for your diligent efforts in this matter.
I was trying this plugin out for my community, and when me and a few other members tried to test it, it didn’t seem to work as intended. The posts created by normal members show for everyone else and not only the private groups selected. Is this plugin possibly not up to date, or have I done something wrong?