I really need a way for users to add sensitive data to a post without using private messages. I have this in a plugin: require_dependency "plugin/filter" Plugin::Filter.register(:after_post_cook) do |post, cooked| index=0 cooked.gsub(/\[secret\].*?\[\/secret\]/) { |a| index+=1; " #{I18n.t('secret_replies.cooked_message')} " } end Effectively, it takes this content: Anyone can see this. [secret]but not this[/secret] [secret]and DEFINITELY not this[/secret] and cooks down to: Anyone can see this. This content has been marked as secret. It is visible to staff and the original poster. This content has been marked as secret. It is visible to staff and the original poster. Assuming this is safe to do, the rest of the plugin can be built around this concept. For example, there can be a protected endpoint for retrieving the raw content, and client modifications to add it back to the cooked content. I do understand that if a user is given the ability to edit a post they will get raw content. I’m ok with this since those users are already staff, or are otherwise trustworthy with these secrets. Main question: Is there any unguarded context where Discourse outputs raw post content instead of cooked content? Any other security concerns? Thanks!

Perhaps if you describe the bigger picture of what you’re trying to achieve, you’ll avoid falling foul of the XY problem.

Thanks, @mpalmer! That’s awesome. I’ve been aware of the XY Problem for at least 30 years, but never knew what to call it.

@mpalmer Sure! I’m using a Discourse category for handling product support, and other categories for discussion. Sometimes users need to share their site URL or even login information with us in a way that keeps the topic itself readable to others, but our staff can still see that info.

Maybe you want to do something that puts the information in a PM and inserts a link to the PM (perhaps semi-hidden as you’ve attempted previously)

It would be really great if the information was just inline somehow. It’s a bit more involved, but the next concept I’m currently exploring involves using add_to_serializer to supply a custom field when viewed by the post owner or admin/moderator. Instead of the shortcode style method I originally wanted, I’ll probably need to make a custom UI in the composer.

The fact that you sent a PM to someone in reference to a post is noted below the post, but this might be a staff-only thing.

Let me know what you guys think of this method. It will need a custom UI put together, but the idea is that a custom post field is used to store the private information. It’s added to the serializer if the user is staff or the OP, and can be piped down into the post stream. Does this look secure? Is there a way people could otherwise find the custom field contents? https://gist.github.com/rohmann/4572181f5a84b1dfcf789c224076be63

For me, personally, I’d just say “PM me the ”, and save writing a custom plugin…

@mpalmer That works, but really slows down the process. It isn’t very scalable. For example, with inline private data the user can attach a private URL before the topic even gets a response. The next person able to work on the ticket may not have been the one requesting the login credentials. If the ticket needs escalation to another user they’d have to coordinate to get that information (more potential exposure) or annoyingly request the user to PM someone else. And if the user needs to change any of the information along the way, they need to resend it to any of the involved parties. For me it is definitely worth a custom plugin if I can get private data per post accessible by the OP and staff. The plugin in the gist above gets custom field content into the post stream, and only when the user should be able to see it. It also accepts a PUT to /secure-note/update allowing permissible users to set the note content. It seems to be working minus the UI. Being new to Rails and Discourse plugin development, I’m just concerned about that custom field somehow being exposed to users who shouldn’t see it somehow. Is it ok to store sensitive info in custom fields?

You need to make these people staff and use whispers. That is exactly what whispers are for – if staff are the ones with the secret. Granted with customer secrets you can’t but in this case use incoming email to trigger a group PM. That is how team@discourse.org works for example. Then the topic, instantiated by an email, is private and visible only to the team group and that one customer.. who can either log in to reply (with the same email address), or rely via email.

Is this secure? Concept for private info in replies

Development

Falco (Falco) December 9, 2021, 2:02pm 21

Discourse Private Replies is kinda close

Topic		Replies	Views
Ways to post confidential info for moderator eyes only? Feature	43	11604	September 24, 2015
Secret Text Plugin Development	7	1420	August 25, 2018
Discourse Private Replies Plugin	60	9601	April 20, 2026
Way to make part of the post visible to author and staff only? Feature	26	2573	November 17, 2025
Hide part of post Feature	1	1280	June 13, 2016

Is this secure? Concept for private info in replies

Related topics