Author Topic: Relay.php (Replaces GuildRelay_GUILD.php and Relay_GUILD.php) (Read 37385 times)

Alreadythere · « **Reply #15 on:** May 30, 2007, 07:22:49 pm »

Quote from: Ebag333 on May 30, 2007, 07:12:03 pm

Around line 31:
Code: [Select]
<?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.

Quote from: Ebag333 on May 30, 2007, 07:12:03 pm

Around line 79:
Code: [Select]
<?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 ).

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.

Ebag333 · « **Reply #16 on:** May 30, 2007, 08:33:14 pm »

Quote from: Alreadythere on May 30, 2007, 07:22:49 pm

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":

Code: [Select]

<?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.

Quote from: Alreadythere on May 30, 2007, 07:22:49 pm

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.

Alreadythere · « **Reply #17 on:** May 30, 2007, 09:02:43 pm »

Quote from: Ebag333 on May 30, 2007, 08:33:14 pm

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.

Quote from: Ebag333 on May 30, 2007, 08:33:14 pm

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.

Ebag333 · « **Reply #18 on:** May 30, 2007, 09:09:10 pm »

Quote from: Alreadythere on May 30, 2007, 09:02:43 pm

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?

Alreadythere · « **Reply #19 on:** May 30, 2007, 09:11:47 pm »

Yes, checking access rights in Bot.php again, and setting default in Relay module.

Nytridr · « **Reply #20 on:** July 05, 2007, 07:42:46 am »

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

Alreadythere · « **Reply #21 on:** July 05, 2007, 11:58:00 am »

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.

Nytridr · « **Reply #22 on:** July 05, 2007, 05:28:42 pm »

Quote from: Alreadythere on July 05, 2007, 11:58:00 am

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.

Alreadythere · « **Reply #23 on:** July 05, 2007, 06:08:10 pm »

Should work again in SVN version.

Nytridr · « **Reply #24 on:** July 05, 2007, 08:36:13 pm »

Quote from: Alreadythere on July 05, 2007, 06:08:10 pm

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.

Alreadythere · « **Reply #25 on:** July 06, 2007, 12:16:03 am »

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.