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:
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.
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.
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.
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).
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
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.
cc 
Thought I missed something myself. All clear.