Hubot-slack: Sending a message that includes a pipe inside of two angle brackets adds message as wrong bot user.

[kallanreed]

• [x] I've read and understood the Contributing guidelines and have done my best effort to follow them.
• [x] I've read and agree to the Code of Conduct.
• [x] I've searched for any related issues and avoided creating a duplicate issue.
  

  Description

calling robot.send with a message like <foo|bar> causes the message to be added by user "bot" in Slack instead of the configured bot. Because it's a different user than the configured bot user (let's say "my_bot_name") the messages written by "bot" are heard by the hubot.

I noticed the behavior when the hubot started responding to the help text from @my_bot_name help which rendered <foo|bar> as part of a command help string.

Reproducible in:

"hubot": "^2.19.0",
"hubot-diagnostics": "0.0.1",
"hubot-google-images": "^0.2.6",
"hubot-google-translate": "^0.2.0",
"hubot-help": "^0.2.0",
"hubot-heroku-keepalive": "^1.0.2",
"hubot-maps": "0.0.2",
"hubot-pugme": "^0.1.0",
"hubot-redis-brain": "0.0.3",
"hubot-rules": "^0.1.1",
"hubot-scripts": "^2.17.2",
"hubot-shipit": "^0.2.0",
"hubot-slack": "^4.0.2",
"node-whois": "^2.1.3"

Steps to reproduce:

1. send "<foo|bar>" from within a hubot script
   

   Expected result:

"" to be added to the channel as "my_bot_name"

Actual result:

"" is added as a user called "bot" which is not even configured in the team settings.

Attachments:

In the screenshot above, I have two response scripts. The first is a simple echo that calls toLowerCase() before sending and the second responds to "test". In the example you can see that the "test" script is responding the bugged message added by the "bot" caused by this issue.

[kallanreed]

Here you can see that the message is sent and then the hubot receives a message from itself as "hubot".

[Sun Aug 21 2016 16:47:52 GMT+0000 (Coordinated Universal Time)] DEBUG Received message: '@whatisbot bad' in channel: protect-bot-funland, from: kylereed
[Sun Aug 21 2016 16:47:52 GMT+0000 (Coordinated Universal Time)] DEBUG Message '@whatisbot bad' matched regex //^\s*[@]?whatisbot[:,]?\s*(?:bad)//; listener.options = { id: null }
[Sun Aug 21 2016 16:47:52 GMT+0000 (Coordinated Universal Time)] DEBUG Executing listener callback for Message '@whatisbot bad'
[Sun Aug 21 2016 16:47:52 GMT+0000 (Coordinated Universal Time)] DEBUG Sending to C237Q2NP7:<bad|robot>
[Sun Aug 21 2016 16:47:52 GMT+0000 (Coordinated Universal Time)] DEBUG Received message: '<bad|robot>' in channel: protect-bot-funland, from: hubot
[Sun Aug 21 2016 16:47:52 GMT+0000 (Coordinated Universal Time)] DEBUG No listeners executed; falling back to catch-all

[kallanreed]

After looking at formatter.coffee in the hubot-slack package, it looks like Slack treats <foo|bar> as an ID and a label which may be part of the reason this is getting messed up. Not sure if there's a way to escape the strings so it doesn't get interpreted by Slack.

[DEGoodmanWilson]

Yeah, I think I know how to fix this…which is to hand off parsing of links to the Slack backend. I just have to implement that.

[kallanreed]

That sounds right. I attempted a fix in the formatter, but it was going to need special handling of the @user and !here entities.

Sent from my iPhone

On Aug 24, 2016, at 23:24, Don Goodman-Wilson <[email protected][e-mail]> wrote:

Yeah, I think I know how to fix this...which is to hand off parsing of links to the Slack backend.

You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/slackhq/hubot-slack/issues/344#issuecomment-242291974, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ADljbhHylgt9htap-gtsqxstraPagj5Vks5qjTUPgaJpZM4JpPMl.

[DEGoodmanWilson]

This should now be fixed as of the latest release, 4.0.3, going out momentarily. Can you verify for me?

[iancward]

@DEGoodmanWilson when I ask for help (via the hubot-help script), my bot now has my user ID in angle brackets instead of my user name.

e.g.:

<@U123456>: my_botname: a_fun_command

[DEGoodmanWilson]

:facepalm:

[DEGoodmanWilson]

@iancward can you provide a snippet that reproduces the problem? I can't seem to repro it locally. Indeed, this seems a new issue, can you open a new issue, as the original is now fixed?

[DEGoodmanWilson]

This should be fixed in 4.0.4

[iancward]

@DEGoodmanWilson thanks! it looks good now.
And thanks for the humorous CHANGELOG entries. :-D