Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

talk:bot:install URL argument syntax and purpose unclear in documentation. #10560

Closed
Magicrafter13 opened this issue Sep 21, 2023 · 11 comments
Closed

Comments

@Magicrafter13
Copy link

How to use GitHub

  • Please use the 👍 reaction to show that you are affected by the same issue.
  • Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
  • Subscribe to receive notifications on status change and new comments.

I'm trying to follow this documentation to create a webhook for sending messages only.
Here is most of the command I'm trying to run: occ talk:bot:install --output=json --no-setup --feature=none -vvv -- "Server Alerts" "$(cat talk-pass)" but I can't figure out the URL argument (or what it's even for).

This page shows that it is a required argument - which confuses me as the first page I linked shows (as best I can tell) to send a message I will send data to <website>/ocs/v2.php/apps/spreed/api/v1/bot/<secret_key>/message. That is clearly a URL, and a unique one at that, so what more I would need I'm not sure. The second issue is that it doesn't elaborate on how this should look. I tried passing "alert" and "/alert" but both result in the same message "The provided URL is not a valid URL". The only text given on the webpage is "Webhook endpoint to post messages to (max. 4000 chars)" which tells me nothing honestly.

Server configuration

Nextcloud Version: 27.1.0

@Magicrafter13
Copy link
Author

Magicrafter13 commented Sep 21, 2023

Cloned the source and searched for the file that gave me that output, and it seems the only criteria it looks for is that the string starts with http:// or https://, which at least tells me it's looking for a fully qualified URL, but the purpose still eludes me, so I don't know what I ought to pass. Surely it's not asking for my domain right? Since that's saved in my Nextcloud configuration to begin with...

Edit: thinking about it more, I realized this is for outgoing messages - for the bot to receive. I still think the documentation could be worded more clearly on that (especially since it should probably be optional 🤔) but I'll close this since it seems less likely to be needed than I originally thought...

@nickvergessen
Copy link
Member

Hi there,

so the bots were designed to always be bi-directional based on "webhooks" and similar to bots in all kind of other software you would reach them by sending them messages. The url argument is basically the "input" channel for the bot, where it will receive requests with every message that is posted into a room.
Only later on the --feature flags were introduced to allow bots that can only send messages to the room, without ever receiving input. But the way bots are identified is by this URL, so we couldn't make it optional anymore.

Surely it's not asking for my domain right? Since that's saved in my Nextcloud configuration to begin with...

It is, the cases where the bot will run on the same server as the Nextcloud might be rather limited (mostly for home instances, but not for bigger installations).

If your bot is local and doesn't need input --feature=response (only), you can "cheat" and use an invalid URL like http://localhost/inbound-bot-1

@Magicrafter13
Copy link
Author

Magicrafter13 commented Sep 21, 2023

Hi @nickvergessen , thanks for your response.

I was able to get to this point doing essentially what you said (I had the idea to "cheat" already, and wanted to see if it would work out - seems it was the right way to go):

+----+---------------+-------------+-------------+-------+-------------------+
| id | name          | description | error_count | state | features          |
+----+---------------+-------------+-------------+-------+-------------------+
| 1  | Server Alerts |             | 0           | 2     | webhook, response |
+----+---------------+-------------+-------------+-------+-------------------+

Admittedly this is no longer part of my "issue" with the documentation, I think this part really is just me not completely understanding, but what would be the full URL I send messages to. Let's say I have a chat located at {website}/call/XXXXXXXX. The docs show /bot/{token}/message which doesn't have a fill-in ({..}) for a chat ID. I've already added the bot to the chat using talk:bot:setup, that was easy enough to figure out. Doesn't seem to be a whole lot of talk (pardon the pun) about this stuff online right now - though to be fair, this does seem like a fairly new feature.

Edit: And I just realized you made this pull request LOL - cool stuff.

@basskitty
Copy link

Hey, have you managed to set up the bot eventually? I'm trying to create one with the same purpose but I also don't understand what URL I need to send messages to.

@nickvergessen
Copy link
Member

@basskitty
Copy link

Well I've been staring at this for the past 2 hours with no success. I'm trying to configure a Webhook in GitLab that should just post the received message from GitLab in a chat.
According to the doc the endpoint should be /bot/{token}/message, but what is the token here? The secret I set it up with, the chat id, the bot id? It's not stated and no matter what I try, I always get this in GitLab:

Hook executed successfully but returned HTTP 404 failure 404 Invalid query, please check the syntax. API specifications are here: http://www.freedesktop.org/wiki/Specifications/open-collaboration-services.

However, after just inspecting the sent test requests.. I believe it's has something to do with the headers, because there sure is no X-Nextcloud-.. data contained and custom headers are not available. Not sure how to further approach this.

@nickvergessen
Copy link
Member

I'm trying to configure a Webhook in GitLab that should just post the received message from GitLab in a chat.

You will need to have a script inbetween that verifies GitLab and then signs the request with your secret and sends it to the Nextcloud.

According to the doc the endpoint should be /bot/{token}/message, but what is the token here?

It's the "conversation token", so the part of the URL after /call/ when you open the chat in your browser.

However, after just inspecting the sent test requests.. I believe it's has something to do with the headers, because there sure is no X-Nextcloud-.. data contained and custom headers are not available.

That is correct.

See the code block inside if ($config['server']) { from #9458 for more help and sample code

@basskitty
Copy link

I see.. so assuming I have the script, what do I do with it? It sounds like I'd need some 3rd party listening-signing-forwarding service inbetween. Is there some solution that is "usually" used for this?
Very sorry if these might be stupid questions, but I'm not a dev and with RocketChat this was set up quickly without any tinkering (we're evaluating a migration to Talk).

@nickvergessen
Copy link
Member

It sounds like I'd need some 3rd party listening-signing-forwarding service inbetween. Is there some solution that is "usually" used for this?

You can also have that on the same server.

I will try to publish one of my bots that connects our hackerone program https://hackerone.com/nextcloud/ with a talk room later this week

@nickvergessen
Copy link
Member

I published it at https://github.com/nextcloud/hackerone_bot
Check the hackerone.php file there for a simple "forwarding" mechanism from HackerOne's webhooks into a Talk chat room.

@basskitty
Copy link

I published it at https://github.com/nextcloud/hackerone_bot Check the hackerone.php file there for a simple "forwarding" mechanism from HackerOne's webhooks into a Talk chat room.

Perfect, thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants