This plugin allows you to add an extra security setting to categories so that users can only access their own topics. You can also designate one or more groups that can see all topics in the category. This is typically used for providing private support within a public community.
Rationale
We were looking for a more integrated way of being able to provide support for Communiteq’s clients without having to create a few thousand categories. We also wanted to stay away from Group Inboxes because they feel too much bolted on and by default you get a “new PM” bubble every time someone posts something in any group inbox.
private topics permitted groups : designates groups whose members’ posts are consistently accessible. 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, if you want these to be shown.
private topics admin sees all: when enabled, admin users can access all topics, even when they’re in a private category. Disable this if you want to hide confidential data from accidental glances.
Caveats
The plugin filters topics from topic lists, post stream, search, user summary, user activity, the not found page, follow notifications and raw.
Topics are included in badges, but badges are not granted for non-public categories, so you should remove everyone from the category security groups and add trust_level_1 instead.
This plugin is brand new and has not been tested extensively yet.
Possible “leaks” are:
digest emails (not tested yet)
message bus (sometimes a “there is one new or updated topic” flashes and then disappears)
Todo / Roadmap
have a category banner that explains that it’s safe to post more or less confidential things in the category.
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.
