Hey there… I’m looking for some extra pairs of eyes on the plugin I’ve implemented for this feature: Allow Slack to unfurl/expand links to “login-required” Discourse instance Slack posts a request to yourdomain.com/slackdoor over https (assuming your site has it enabled) with an x-www-form-urlencoded body that includes a token, which is generated on their side when you set up the outgoing webook. token=XXXXXXXXXXXXXXXXXX team_id=T0001 team_domain=example channel_id=C2147483705 channel_name=test timestamp=1355517523.000005 user_id=U2147483697 user_name=Steve text=googlebot: What is the air-speed velocity of an unladen swallow? trigger_word=googlebot: The request can’t include an API Key or username, but a required SiteSetting for username determines which user is used to access the topic. These are all checked before_filter methods in the Controller class: plugin.rb master def slackdoor_enabled? raise Discourse::NotFound unless SiteSetting.discourse_slackdoor_enabled end def slackdoor_token_valid? raise Discourse::InvalidAccess.new unless SiteSetting.discourse_slackdoor_token raise Discourse::InvalidAccess.new unless SiteSetting.discourse_slackdoor_token == params[:token] end def slackdoor_username_present? raise Discourse::InvalidAccess.new unless SiteSetting.discourse_slackdoor_username end In order to bypass the default authentication logic, I have overridden these methods in the plugin’s controller: plugin.rb master # Override ApplicationController access control methods def handle_unverified_request end def is_api? true end def redirect_to_login_if_required end Check out this file for the full plugin: discourse-slackdoor/plugin.rb at master · mcwumbly/discourse-slackdoor · GitHub Please let me know if you see any issues with this approach… Thanks!

Hey there, I’m taking a look at your code now! Good work so far. I’ll have some feedback up tonight. As a heads-up, I’ll be working on an official Slack plugin (official as in sponsored by Discourse, not by Slack). It’s intended to be very fully-featured and go a bit deep. I don’t want to undermine the great work you’ve done so far, so getting you involved would be great if you’d like.

Cool, thanks Nick. If this functionality is supported by the plugin you’re working on, I would be happy to switch over to something officially supported by the team. In the mean time, this is working well, but my main concern right now is whether I’m inadvertently introducing some risk security-wise that isn’t obvious, so if you see anything along those lines that you’d recommend changing or taking a closer look at, please let me know.

Accepting incoming webhooks, that’s something I am interested. But it’ll be general. Pre-defined actions, some policy to process the webhooks. I probably will use that for testing webhooks among several Discourse instances. [图片] mcwumbly: The request can’t include an API Key or username, but a required SiteSetting for username determines which user is used to access the topic. plugin.rb master # Override ApplicationController access control methods def handle_unverified_request end def is_api? true end def redirect_to_login_if_required end It’s better to use skip_before_{filter,action}, both simple and clear. The risk comes from you don’t know how to authenticate an incoming request. If one Discourse instance is private, this endpoint would open a door for the world by guessing possible url patterns. plugin.rb master def slackdoor_enabled? raise Discourse::NotFound unless SiteSetting.discourse_slackdoor_enabled end def slackdoor_token_valid? raise Discourse::InvalidAccess.new unless SiteSetting.discourse_slackdoor_token raise Discourse::InvalidAccess.new unless SiteSetting.discourse_slackdoor_token == params[:token] end def slackdoor_username_present? raise Discourse::InvalidAccess.new unless SiteSetting.discourse_slackdoor_username end If checking SiteSetting is needed, batching all of them in one function could be enough

I don’t see any major security problems I don’t think - but I am only looking at the obvious, myself. @fantasticfears covered some things I didn’t know myself. As long as the token they give is nice and cryptographically strong and HTTPS is being used, I think the bases are covered. It’d be nice to have a separate namespace for external services / webhooks in the future and a manager for these, as @fantasticfears seems to be saying (if I am understanding you correctly).

Me is saying developing web application should consider authentication/authorization by all means. Rails.application.routes.recognize_path("/t/whatever/1234/56" The entry point in this case is a url. By forging a pair of topic_id/post_id, I could query any post where I want to see. I could know post excerpt, topic title, poster username. And even more, private message and staff category is also on my palm. HTTPS can only help to transmit the data safely. It can’t prevent information spreading out if you intend to do so

The user configured in the SiteSettings can limit the exposure to private messages and staff categories. And the token configured in the SiteSetting had to match the one posted in the body. Does that address your concerns? Or do you think there is a gap somewhere still that I’m missing?

Sorry I missed the TopicView! :astonished: cc @Nick Sure that would do the authorization. And token configured on Slack end can be used as a certificate. HTTPS would prevent all kinds of passive attack.

Cool… Thanks so much for taking the time to go through this and give your feedback @fantasticfears. I’ll put some time into addressing your other code-cleanliness feedback and get a README together. That should put it in a state where others can use it while development gets underway for a more fully-featured Slack plugin. @Nick, please feel free to use anything in here that you find useful, or reach out to me if you want feedback on the work you’re doing as you get into it.

[图片] fantasticfears: Sorry I missed the TopicView! :astonished: cc @Nick Hah. Glad :smile: Thought I missed something myself. All clear. [图片] mcwumbly: @Nick, please feel free to use anything in here that you find useful, or reach out to me if you want feedback on the work you’re doing as you get into it. Great to hear! I will. Thank you for the work you’ve put in. When I have the ground-floor set up I’ll link it in this thread.

Code review request for `slackdoor` plugin

Development

mcwumbly (Dave McClure) 2016 年5 月 22 日 20:33 11

The canonical plugin topic is now here: Discourse Slackdoor Plugin

话题		回复	浏览量
Allow Slack to unfurl/expand links to "login-required" Discourse instance Feature	5	5663	2016 年5 月 22 日
Slack command integration broken in official discourse slack plugin Product Support chat-integration	7	2859	2017 年4 月 10 日
Prevent Slack from unfurling anything for login-required sites Product Support	5	4135	2017 年12 月 2 日
Help configuring Slack Discourse plugin Product Support	18	5173	2019 年9 月 30 日
Webhook Secret issue Product Support webhooks	12	1452	2023 年8 月 21 日

Code review request for `slackdoor` plugin

相关话题