BeBot - An Anarchy Online and Age Of Conan chat automaton
Archive => Anarchy Online Archive => 0.3.x Custom/Unofficial Modules => Topic started by: Ebag333 on May 25, 2007, 08:11:34 pm
-
This module is now included in SVN. Please download from there to ensure that you have the latest version and it is compatible with your Bebot version (this is not 0.2.X or 0.3.3 compatible).
The idea for this plugin came from http://bebot.link/index.php?topic=780.msg5998;topicseen#new
Previously we had two plugins GuildRelay_GUILD.php and Relay_GUILD.php. Now, many orgs have a setup something like:
privgrp <-> org chat <-> org chat <-> privgrp
Previously Relay_GUILD handed the private group to org chat, and GuildRelay_GUILD handled both the private group and org chat to the other org's bot.
This module replaces both the GuildRelay_GUILD.php and Relay_GUILD.php modules with a unified module that is configurable through !settings.
Known bugs:
None at this time.
Todo items:
None at this time.
Changelog:
- Configure an option for backwards compatibility (send !gcr in tells instead of only allowing for the relay bot).
- Confirm that the exterior private group is the one we've set in the Relay option, currently all exterior private groups can use !gcr as long as the person using it has access to the command.
- Customizable names included for private group and guild chat for relaying (IE: shorten Conquistador Coffee Inc. to CCI). Now allows for any name to be used. Defaults to the organizations name.
- Configurable colors!
To setup and use:
Step 1
Create a new bot to use as the relay. Add the bots that will be using the relay as members. Configure the relaybot to autoinvite the bots that will be using it. (It is highly recommended to disable nearly all plugins on the relaybot. As you are only using it for relaying purposes, there should be no reason why anyone needs access to it other than the bots and yourself.)
Step 2
Install the Relay.php plugin onto the bots that will be using the relay. Make sure to disable GuildRelay_GUILD.php and Relay_GUILD.php as this will conflict with them.
Step 3
Give the bots that will be relaying the correct access level and permissions to use !gcr. (So if Bot1 is relaying to Bot2 via Relay1, Bot1 needs access to !gcr on Bot2 via pgmsg, and vice versa.)
Step 4
Restart the bots if you haven't already, and configure your settings to your specifications.
Step 5
Enjoy lightning quick relay messages, and less bot lag (due to no longer queueing the relay messages via /tell).
-
smells nice. Gonna test it
-
Todo items:
Configure an option for backwards compatibility (send !gcr in tells instead of only allowing for the relay bot).
If you add this, please clearly state that it is a discouraged way of doing relays, and should only be used between two bots, not more.
-
Does this relay prevent persons banned or blacklisted from the one org to take part in chat via relay? Would such a filter be fesable to impliment?
How does the relay bot work? Is it possible for anyone to join a relay channel? Are one notified as new bots attach to the relay?
I haven't looked at the module yet, but the ide is very nice and if done right security wise it would be a major improvement over the old way.
Good job!
-
We actually need a central ignore feature that covers all relays, including IRC.
This should probably be simply string based, although it is feasible to take into account the blacklist/banlist as well for the ingame relays.
-
Well, back from the long weekend. Glad to see some people are at least interested in this a bit. :)
If you add this, please clearly state that it is a discouraged way of doing relays, and should only be used between two bots, not more.
Since I just use a !setting, it's really only designed for 1 bot.
The way I figure it, if you're using a relay bot you can have as many bots as you want, but you still only need 1 relay bot. If you just have a simple 2 org setup, then you still only need 1 bot to relay to, just it's not a central bot.
If you need multiple relay bots, then you're looking to do something out of the norm anyway.
Does this relay prevent persons banned or blacklisted from the one org to take part in chat via relay? Would such a filter be fesable to impliment?
We actually need a central ignore feature that covers all relays, including IRC.
Agreed, this should be a central rather than relay specific feature.
Though you may want to ban someone from using the bots commands, but not from having their text relayed. Hmm, and the tricky part will be that even if you ban someone from your bot, if the person is getting relayed you'll still see their chat no matter what.
Maybe I'll throw in an option "Relay banned users text" or something.
How does the relay bot work? Is it possible for anyone to join a relay channel? Are one notified as new bots attach to the relay?
All I did for the relay channel was take a normal Bebot, rip out all the plugins I could, lock down all the remaining commands to Owner only, then setup the bots I wanted to join as members with autoinvite for them on.
This way no one can join the bot, even if they're a member of it (that shouldn't ever happen, but...).
Since the relay module autoaccepts invites, the bots will join the relay chan when they get the invite (on log), and the relay connection is made.
So all in all *VERY* simple, really.
As I mentioned before I do need to fix it to confirm that the invite is from the bot set as the relay....
Anyway, there's currently no notification on joining the relay. I've always found those to be quite annoying myself. :D
One of my future goals is to bring in everything relay related into one unified plugin. Still need to bring member join/parts into that, which would be easier if the formatting done was a core plugin rather than the customized one in the logon plugin.
/me edits
Updated to make it more coherent. Writing at 2:30 in the morning after driving for 13 hours over the weekend FTL.
-
Updated the original post, and new Relay.php is zipped and attached.
Changes:
- Added an option for backwards compatibility (send !gcr in tells instead of only allowing for the relay bot). This uses the same bot referenced in the Relay setting, so we only allow for one bot. A warning is put in about using tells, and this defaults to a private group. (Note: this makes no use of $guild_relay_target in Bot.conf. In fact, $guild_relay_target is not used at all as I find it much easier to handle it ingame than in the .conf file. :) )
- We now confirm that the exterior private group is the one we've set in the Relay option for the purposes of commands used as well as invites to the group. Now we can only use !gcr from the private group that we've configured in the settings. !gcr is usable from any source in /tell, this is left this way to allow for multiple bots to be sending into a single source (sort of a one-way messaging or notification system).
At this point the plugin is just about as locked down as I can make it. Not only does the bot that's trying to send a relay message (whether via /tell or pgroup) have to have access to it, but we validate that the exterior private group is the one we want (for accepting the invite and handling !gcr commands).
I can't think of any ways to abuse this, at least (assuming you configured your setup properly!). :)
Unless anyone else has any suggestions or ideas, I'll consider this finished. :)
-
Unless anyone else has any suggestions or ideas, I'll consider this finished. :)
Looks like nice work, I do have two suggestions though:- add color schemes for the channel name, user and chat string, so people that want to change them can do so during runtime.
- add settings for guest channel name (priv group) and org name on sending side, so if people want to use shortcuts they can do that
Both are mostly for convenienve :)
-
Looks like nice work, I do have two suggestions though:- add color schemes for the channel name, user and chat string, so people that want to change them can do so during runtime.
Well, I'm currently using the default colors for it, which uses ##highlight## and ##normal## for it (which I assume are configurable somewhere?).
- add settings for guest channel name (priv group) and org name on sending side, so if people want to use shortcuts they can do that
Excellent suggestion!
/me runs off to implement this
-
Looks like nice work, I do have two suggestions though:- add color schemes for the channel name, user and chat string, so people that want to change them can do so during runtime.
Well, I'm currently using the default colors for it, which uses ##highlight## and ##normal## for it (which I assume are configurable somewhere?).
Yes, they can be configured as they are part of the theme in use. But any changes there are global changes for all modules using the theme colors.
If you use schemes that default to the theme colors you are using it will work the same as now if people like the colors or are happy with the global theme colors. But if people want to use specific colors for their relay they can change them easy, without influencing other modules.
-
Updated again with Alreadythere's suggestions (both the channel names and color config).
So can we get this in SVN now? :D
-
Nice work.
I fear if we put it into SVN we'll have to move to tells as default (as that's the expected and easiest setup, needing only the two bots that are in the relay).
-
Nice work.
I fear if we put it into SVN we'll have to move to tells as default (as that's the expected and easiest setup, needing only the two bots that are in the relay).
Well, from everything I've heard tells aren't the recommended way of doing relays anyway. :)
And it is only one setting. And they need to change the settings for it to work properly anyway (add the bot they want to relay to). And I *HAVE* included instructions in !help gcr on how to use the private group relay.
But I do understand your point, and of course it's quite simple to change the default from Pgroup to Tells.
-
Commited to SVN.
Did some slight changes to a few settings (type), and added some additional safety conditions where I felt they are needed, as well as using normal as default for all schemes.
I added a relay_to_bot($string) function too, which relays $string without any further changes to the relay bot except adding "<pre>gcr ". This can be used in other modules to relay text too.
Adapted the other modules using the relay too.
-
Couple of things.
Around line 31:
<?php
$this -> bot -> accesscontrol -> create('pgmsg', 'gcr', 'SUPERADMIN');
?>
Why remove this? Seems to me this creates a security hole.
Around line 79:
<?php
function tell($name, $msg)
{
if (preg_match("/^" . $this -> bot -> commpre . "gcr (.+)$/im", $msg, $info) &&
strtolower($this -> bot -> botname) != strtolower($name) &&
$this -> bot -> settings['Relay']['Status'] &&
strtolower($this -> bot -> settings["Relay"]["Relay"]) == strtolower($name))
?>
Couple of things. First off, if someone's trying to use !gcr in tells, they have to have access for it to work, so locking the $name to the relay bot seems redundant. Especially since it's a single channel that's explicitly to the bot, as opposed to the bot being able to join many pgroups and picking up the wrong !gcr's.
Secondly, many people (including myself) use !gcr as a relay for other purposes (such as recieving tells from global bots and being able to post it to org chat). So locking !gcr to the relay bot only eliminates that "feature".
Personally I think that particular check should be removed (and will for my bots :D ).
Those are the only two problems I see with this. Other than that, all the changes made look fine. :)
-
Around line 31:
<?php
$this -> bot -> accesscontrol -> create('pgmsg', 'gcr', 'SUPERADMIN');
?>
Why remove this? Seems to me this creates a security hole.
It would create a security whole if gcr was a command in private group. It isn't though, it's in extpgmsg. Due to the way access control is implemented there are some problems with trying to set rights for commands that aren't there.
So I removed the access control check for extpgmsg (and only that) completly. So modules that use the channel have to implement some kind of access control itself. If modules with more then just one command start to use extpgmsg too it will be time to think about a solution for this issue, right now I feel just the checks in the extpgmsg() function are enough.
Around line 79:
<?php
function tell($name, $msg)
{
if (preg_match("/^" . $this -> bot -> commpre . "gcr (.+)$/im", $msg, $info) &&
strtolower($this -> bot -> botname) != strtolower($name) &&
$this -> bot -> settings['Relay']['Status'] &&
strtolower($this -> bot -> settings["Relay"]["Relay"]) == strtolower($name))
?>
Couple of things. First off, if someone's trying to use !gcr in tells, they have to have access for it to work, so locking the $name to the relay bot seems redundant. Especially since it's a single channel that's explicitly to the bot, as opposed to the bot being able to join many pgroups and picking up the wrong !gcr's.
Secondly, many people (including myself) use !gcr as a relay for other purposes (such as recieving tells from global bots and being able to post it to org chat). So locking !gcr to the relay bot only eliminates that "feature".
Personally I think that particular check should be removed (and will for my bots :D ).
There are reasons for both ways. If no exact check is implemented anyone with the access rights can spam org chat in tells.
With it you can't abuse it for other things.
Guess I'll just add another setting to enable and disable the check as wished.
Edit: check added, will commit as soon as I can reach svn again.
-
It would create a security whole if gcr was a command in private group. It isn't though, it's in extpgmsg. Due to the way access control is implemented there are some problems with trying to set rights for commands that aren't there.
So I removed the access control check for extpgmsg (and only that) completly. So modules that use the channel have to implement some kind of access control itself. If modules with more then just one command start to use extpgmsg too it will be time to think about a solution for this issue, right now I feel just the checks in the extpgmsg() function are enough.
But here's the "problem":
<?php
if (!empty($this -> commands["extpgmsg"]))
{
$comms = array_keys($this -> commands["extpgmsg"]);
for ($i = 0; $i < count($comms); $i++)
{
if ($this -> is_command($comms[$i], $args[2])
&& $this -> accesscontrol -> check_rights($user, $comms[$i], "pgmsg"))
{
$this -> commands["extpgmsg"][$comms[$i]] -> extpgmsg ($pgname, $user, $args[2]);
$i = count($comms);
$found = true;
}
}
}
?>
Now, if I understand this correctly we consider extpgmsg part of pgmsg for security purposes. So checking the access level makes sense in that situation.
I personally think that the checks we do outside of security make it quite good (especially since my relay bot is completely locked down). But it's less of a security measure and more of a functionality measure.
Hmm, to give an example.
Org A wants to relay to B. Org C wants to relay to D. Org E wants to see everything.
Using the same relay channel, Org A gives access to Org B (and vice versa). Org C gives access to D (and vice versa). Org E gives access to everyone.
Now Org A/B can chat with each other without C/D seeing anything. C/D can chat without A/B seeing anything. E can see everything, but can't reply (since A/B/C/D didn't give them access).
All using a single relay channel. :)
Anyway, I think it gives it more flexabilty and doesn't really hurt anything.
There are reasons for both ways. If no exact check is implemented anyone with the access rights can spam org chat in tells.
With it you can't abuse it for other things.
Guess I'll just add another setting to enable and disable the check as wished.
Edit: check added, will commit as soon as I can reach svn again.
It still seems redundant to me, we're basically checking that we allow them to use !gcr in tells (security), then checking that we allow them to use !gcr in tells (setting in bot).
If they shouldn't be using !gcr then they shouldn't have access to it in the first place.
-
Now, if I understand this correctly we consider extpgmsg part of pgmsg for security purposes. So checking the access level makes sense in that situation.
I personally think that the checks we do outside of security make it quite good (especially since my relay bot is completely locked down). But it's less of a security measure and more of a functionality measure.
Made extpgmsg a seperate channel for access control, cleanest way I think.
Solves all problems I think.
It still seems redundant to me, we're basically checking that we allow them to use !gcr in tells (security), then checking that we allow them to use !gcr in tells (setting in bot).
If they shouldn't be using !gcr then they shouldn't have access to it in the first place.
I don't like handing out higher access rights then needed, which means the relaying bot got member access for me (GUEST would work too). Considering what members may be up to I prefer the additional check inside.
-
Made extpgmsg a seperate channel for access control, cleanest way I think.
Solves all problems I think.
Does this mean you've added back in the security check? :)
-
Yes, checking access rights in Bot.php again, and setting default in Relay module.
-
has this been fully put in.. all I am seeing is Relay_GUILD.php I dont see anywhere in snv where relay.php is.
NVM I figured it out.. it is fully implemented.. just had to add all the bots as guest and member to every other bot.. and let me say this much.. it works seamlessly.. and defently faster then IRC is..:) thanks for the nice way of doing this.
One things.. I would like to see added is this "relay" bot able to access IRC in the same way that we could relay bots though IRC before.. Where people can be on IRC and still talk to the orgs with out being in game.. and the org can talk back.. Now this is partially in there since people in the orgs can see people talking in org chat in the IRC but it will not go both ways with things being relayed for some reason.
IRC - Metanyt: Hello
org - Metanyt : Hello
Org - Nytridra : hiya
IRC - (nothing comes back)
but if we could have it where the relay bot would connect and things coming from IRC would already have the !gcr being sent out, I think it would work awesome.
Hopefully this is making since.. I have been up way to long atm.
Metanyt
-
Which kind of chat isn't relayed?
Normal org chat in the org that got the IRC relay? Or is chat that went over the bot relay not relayed to IRC after being shown in org chat?
The first case shouldn't happen, the code for that hasn't changed.
The second case has to be rewritten though, as the IRC modules still checks for chat produced by the bot, but the bot always ignores output created by the bot now. Sane change would be to add a check for IRC to the relay functions.
-
Which kind of chat isn't relayed?
Normal org chat in the org that got the IRC relay? Or is chat that went over the bot relay not relayed to IRC after being shown in org chat?
The first case shouldn't happen, the code for that hasn't changed.
The second case has to be rewritten though, as the IRC modules still checks for chat produced by the bot, but the bot always ignores output created by the bot now. Sane change would be to add a check for IRC to the relay functions.
its your second part. right now I have to run another bot just for IRC access which isnt a big deal. But I was thinking if the RELAY bot could relay it over to the IRC it would work, but for some reason being set up as a raid bot, it will not connect to the IRC server, so IDK. I will look at it in more detail this weekend, as I set this all up and changed over pretty late lastnight.
See would couldnt have all of them connecting.. only need one, and I think if a bot is being used as a relay it should be able to do that also.
-
Should work again in SVN version.
-
Should work again in SVN version.
which way did u go? raidbot (relay bot) relaying back and forth to irc or the org bots relaying back n forth
btw, i have a suggestion..
in bot.conf have an option
bot_type = ORG // posible answers ORG, RAID, Relay
everything would remain the same except if it is set to relay then thing coming in from irc would then be relayed back and forth from the other bots AND being set as relay would automatically disable the models that are not needed.
-
I modified relay and irc modules so that if an irc connection exists in one of the org bots (not the relaying bot) the incoming relayed chat gets send to IRC too.
-
k. sounds good... just wanted to make sure I knew what way to go with it