IRC bot standards - Printable Version +- Forums - Open Redstone Engineers (https://forum.openredstone.org) +-- Forum: Off-Topic (https://forum.openredstone.org/forum-4.html) +--- Forum: Programming (https://forum.openredstone.org/forum-8.html) +--- Thread: IRC bot standards (/thread-11967.html)

IRC bot standards - qwerasd205 - 03-20-2017 This is a brief thread to read if you're thinking of making an IRC bot. To get started follow the rules laid out in https://forum.openredstone.org/rules.php -- specifically: Bots: Bots should only speak to the user who would like for it to be spoken to. Be it either a command-based bot or an updater bot that notifies, it should receive the explicit consent of the recipient to receive the message. Bots should only speak in private messages so as to avoid clogging public communication. Additionally -- and this part is just my opinion -- I think it's better to only respond to commands given in private messages to the bot, as people using commands can get quite spammy in pub chat. Now the standards: Help dialog: ALWAYS include a help dialog which can be accessed by messaging the bot "help". Make a forum post containing the help dialog, and make the bot's help command a link to that thread. Give example commands in order for the bot's user to understand what each command does. Ping command: I strongly recommend a "ping" command as it's very useful to see if the bot is responding, and is pretty standard. Keeping your box safe: It's more important when running an IRC bot, for your box(computer) to remain safe while running it, than for the IRC bot to have cool commands, so here's a list of common security issues to avoid: •Never ever ever use eval() or exec() within your code, if you want a "calc" command then use a library for the language you're writing the bot in that is designed for mathematical expression evaluation. •Don't include any commands that could potentially damage your system, even if they're restricted to *only your use*, perfect security on IRC is nearly impossible, and you're bound to eff up somewhere. •If you have a command that does any sort of web access make sure to sanitize the user input before passing it, and rate limit the command, you don't want someone able to make calls to a website from your box at will with no rate limit. •When sanitizing user input to make it safe for a command NEVER use a blacklist, ALWAYS use a whitelist. With a blacklist you're bound to miss something somewhere and when you do someone will find it and down goes your box. •Straight up though, just rate limit like, every command, it makes it so people can't stall your bot by spamming it. If you have any other things you think I should add to this reply to this thread and I'll consider adding them. RE: IRC bot standards - Nickster258 - 03-21-2017 Well, the rules for bots will only really be constricted to "Don't let your bot become a nuisance". These are more of recommendations, which should definitely be used. You suggested timeouts for web stuff but a timeout for literally anything would be good so people don't spam your bot (Our IRC setup throttles spammed requests so if you send TONS of requests the bot could get held up, kinda like how varBot was held up when I spammed it) . I always did regex and forced alphanumeric standards on my inputs. RE: IRC bot standards - Apuly - 03-21-2017 I will now proceed to develop a bot that will break all of these rules RE: IRC bot standards - Nickster258 - 03-21-2017 Well, these are more of recommendations but yea RE: IRC bot standards - Apuly - 03-21-2017 Eh close enough RE: IRC bot standards - jxu - 03-23-2017 jxubot transcends standards !lottery !lottery !lottery !lottery !lottery !lottery RE: IRC bot standards - Apuly - 03-23-2017 shit you've beaten me by like a couple of years I guess Idunnow RE: IRC bot standards - slugdude - 03-26-2017 I'm still gonna make a shell bot when I get the chance in the summer holidays. RE: IRC bot standards - LambdaPI - 03-26-2017 Lets all exploit it Yea slug thats a great idea. RE: IRC bot standards - Apuly - 03-27-2017 Protip: don't try to auth shit over IRC based on username. So easy to break it's almost sad. RE: IRC bot standards - tokumei - 06-09-2017 *shameless bump* ^ Look into IRC user/host masking, it's a great tool that IRC server ops and mods use to manage bans and other things. Here's a quick rundown: With every message that a user sends, its full identity is sent. This is the part at the beginning of the message, and it looks like this: :nonemu!adam@shinobi.nonemu.ninja It consists of 3 parts: - The "nickname," which is after a : . This is what most clients display as your name when you join a channel and is guaranteed by the server to be unique at any given point in time. However, it may change during a session. - The "username," which is after a ! . This is another string provided by the user when it sends USER at the beginning of initialization. Some bots won't let you change it easily - mine uses the username of the system user that ran the command. This can _not_ change after you have connected, but is not guaranteed to be unique between simultaneous users. - The "hostname," which is after a @ . This is a string assigned to the user by the server which is based on the IP address / reverse DNS hostname of the machine connecting to the server. Some servers attempt to conceal the hostnames of their clients by "host masking," which is an unrelated term that just means hashing or otherwise cryptographically obfuscating their hostname and sending that string in place of their actual hostname. Either way, it functions as a reliable method of identifying users, as it is guaranteed to be consistent as long as the user does not change their originating IP. How to apply this? The IRC protocol allows you to place wildcards in the mask, like *!*@98.25.36.192 will match with all users whose hostname is 98.25.36.192 (ie, that is where they connected from). You can also combine wildcards with text, for example: *!*@*.cn will match hostnames ending in .cn (Chinese TLD). This is a fantastic way to identify users, at least for whitelisting, because it's very difficult for someone to spoof your IP unless you give them access to a machine with that IP. If you want to see an implementation, here's mine for Samurai. I substituted regular expression phrases for the wildcards so I could use Java's built-in regex utilities. It works well for me; though I could probably find a few bugs like unescaped characters now.