-
-
Notifications
You must be signed in to change notification settings - Fork 8
Add Bot #82
base: node
Are you sure you want to change the base?
Add Bot #82
Conversation
Nice thing. Perhaps to help simplify things for bot devs could the bot invite field have an option to either select the required perms or input the raw perm number and the site would auto-generate a valid oauth URL for the bot to use. Next should you perhaps include |
I appreciate the feedback and suggestions. I now plan on adding a toggle for applications.commands toggle for bots that use slash commands. Also, I do like the mentioned auto generated OAuth url and will look into implementing that. |
Something like this @Andre601? |
I guess so, yeah. Can't honestly recall what I was talking about here... |
Any update on when this can be reviewed? This could be a major breakthrough for BotBlock and users. |
Regarding this, would it be possible to use POST api/users/{user_id}/bots/{bot_id} as a endpoint for add bot as this is also what fates list officially uses. It is also similar to what discord does too… also, would it be possible to customise how access token is sent, say as a header instead of in request body |
Kinda pointless imo. The bot ID is unique so there is never a real issue with a possible duplicate. Also, not everything has to follow a specific format. |
The official API to add bots which the fates list site uses (and is stable now) is /api/users/{user_id}/bots/{bot_id} (once I deploy the latest update to it, that is). Using this format makes it far easier to use stuff like fastapi dep injection so it would be nice if botblock could support this sort of customisation somehow |
The only way for fates to support botblock add bot then, is to make a whole new api and since this won’t be used by the official client, it may break since it won’t be as well tested and stable as the official api |
With all due respect, oh well, that is quite the shame. Moving on... |
Yeah, the only real issue actually is that the add bot api in fates needs bot id and user id in the url and not request body while botblock uses request body for this. Other than that and the bot_details thing, most other things are trivial fixes tbh |
This is at most an issue on how botblock sends the info or handles bot list URLs, but not how its own URL needs to look like. I assume there is some basic verification for the bot ID on botblock to make sure the user is the actual owner of it? Because then could we most likely get the ID from the logged in user and provide it to your list's URL to make it work. But again: Your List isn't that important or special that botblock should adabt its own URL pattern for it. |
Yeah, botblocks own url def does not need to look like that. I was mainly talking about how botblock handles URLs and request bodies when sending to lists
The way fates does it is similar to many discord API endpoints itself (https://discord.com/developers/docs/resources/guild#add-guild-member as a example) but I agree that fates is def not a role model other lists should use
I don’t really need basic verification since that’s something that’s handled in bot reviews (as some ppl like using alts to post their bots). The only thing I care about is that user id and bot id as path parameters and the botblock key or user token in Authorization header
True, I could likely make a PR to add support for this if you wanted… |
@Andre601 another option would be to make a separate gunicorn+fastapi proxy server to take requests from botblock, convert it to a format that works with fates list, make the api request to add bot and then return the result. Would that work with you? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
90% of it looks pretty decent, good job. I've made a few reccomendations
…Moved some logic around to get this to work. Body sent to bot lists will also now no longer have the names of other bot lists in them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The public API endpoints return all data in the table for lists. This results in the add bot endpoint & secret being leaked. This is not acceptable.
I would suggest separating concerns and storing secret data for lists elsewhere.
So I should store them in a separate table or would it work by removing the keys and url from the data returned? Removing they key and url from the data when returned seems like a more simple solution than making a table for only those. Unless this is frowned upon. |
I ended up just deleting the add_bot and add_bot_key from the json returned when fetching from the api. |
This PR adds the ability to add a bot from the BotBlock site, to participating lists. Detailed list of things added:
- Allows to select which lists to submit to
If there is any suggestions please let me know. My code may not be the most efficient so please recommend changes. To my knowledge I followed the specifications stated in the #spec channel of the Add Bot category