i think i found 2 bugs in 0.3.4
New install no changed

1st is !admin del name
it crashed the bot

next is !blacklist rem name
wouldnt remove some 1, had to do it manualy

Fixed the !admin del bug, and added help for the security module.

It's a general problem with the way alts are defined. Only way would be to enforce a two-way alt adding, meaning the main and the alt have to invoke some command.

This of course would create more some complexity.

I was discussing this with Blue earlier and we agreed that we have two choices on this. And i think we need to address this before 0.4 as it's a critical issue.

1: A challenge system. Player A adds Player B as an alt. A random AUTH string (md5?) is generated and stored in a new databse table, lets name it auth. There we store the requesting playername, time of the request, an integer to designate the request type (to allow the table to be used for more auth related stuff in the future) and the target name.

Player B will then be sent a blob containing a brief explanation with a link to click which will then when clicked send say a /tell botname alts auth <auth string>

This should probably be coupled with a new setting which allows you to restrict adding alts to alts that are also members of the bot (to prevent abuse by doing for example !alts add Sirillion over and over. This would also go well with the second way outlined below. On a side note, to prevent spamming and abuse, you should not be able to rerequest an alt which you have an active auth pending for. And one might in addition consider having a settable enforced delay between alt add's.

2: We have a password table, put it to use. Allow setting a password, and then allowing that password to be used when adding an alt, bypassing the auth requirement.

These two options are the best i've come up with so far, and combined they make for a nice system allowing security and flexibility (i've been thinking of this for a while since it would be nice for a raidbot)

Additionally you could add another layer to the auth mechanism (optional via setting) to require admin approval as well in addition to being confirmed by the target player, or maybe just admin approved (think forum registration options).

Thoughts?

Option 1 sounds cool, but *WAY* too complex.  Most of my users wouldn't be able to figure that out.

Option 2 sounds more feasible, but also increases the complexity quite a bit.


This problem only occurs with people who do not have alts set.  So there is no need for any of these measures if the person has alts set.

It seems to me that the person with the highest access on the bot should be the main.  So as Chris suggested a simple check to see if the person has a higher access level than the person trying to add them as their alt should fix the problem.  This closes the hole, and doesn't really increase complexity all that much (not nearly as much as option 1 or 2 would).  A slightly clearer message than what Chris has should be added ("Admin level" is ambiguous and implies it has something to do with the specific access level of Admin, rather than admin in a general sense).

i got another bug with !help

[Leetboss2]: /tell Leetboss2 !help !irc
To [Leetboss2]: !help !irc
[Leetboss2]: No help found for !irc
To [Leetboss2]: !help irc
[Leetboss2]: help on irc

The bot is telling me to put a ! before the help subject but its no longer used

Indeed, ever since post the release of 0.3.3 (when we started on 0.3.4) !help expects command, and not <pre>command.

That's something that should be allowed either way...

#1 is easiest to use I think, at least from the user point of view. Just clicking a link shouldn't be too hard.

#2 is more comfortable as we could allow adding of mains then using the password.

Your fix is ok Chris, just the way you implemented it now makes every adding of a character with higher access rights as alt to you impossible, even using altadmin. I'd move the check out of the add_alt() function.