Authentication- and level system

Registered by Chris Ortner on 2008-03-25

Using a keyword requires a user to have a certain level, which is expressed in integers from 0 to 100. Not authenticated users have a default level and can use keywords with levels <= the user's level. The keyword's default level is defined directly inside the plug-in and can be overridden by level definitions in a seperate file.

Blueprint information

Needs approval
Michael Otteneder
Series goal:
Accepted for 0.1
Beta Available
Milestone target:
milestone icon beta
Started by
Michael Otteneder on 2008-03-31

Related branches



I _really_ had a look at the code this evening, understood it, and have following points to say:
* passwords should be encrypted (I heard this will happen soon)
* specifying the superadmin should be rather done in one of the following ways than with hardcoding inside the plug-in:
  - Give the first one who registers the highest level
  - Specify a master password or the nick of the superadmin in the config file
* In lib.core, are the lines 201-203 really necessary? Through them, msg.user inside the plug-ins gets a new meaning and has to be handled differently.
I also wanted to have a help for that, which is really important for such plug-ins, so I added it myself in revision 67.
That's it for now. If one more thing comes to my mind I'll check back later.

I dont see why the meaning of msg.user changes? May you explain that to me in more detail?
  - Give the first one who registers the highest level
That is a good idea. +1
Encryption will be ready soon.

In plugins.factoids, line 13/14 is as follows:[msg.chan].write('<%s> %s' %
                        (str(msg.user).split(' ')[0].split(':')[1], msg.msg))
With the old meaning of msg.user, it would contain the hostmask. Now it contains what is specified in __str__ - a string containing nick, hostmask, password, and trusted.
The old meaning of msg.user made it much easier for plug-in coders to extract the nickname. Now you need two splits for different chars and it looks ugly.

In the past msg.user was just a String. Today it is a user defined class. Without the __str__() method the string you'd get were the object id or something. You can access the name very easily with

...which is quite a sausage, to translate it directly from Austrian, but I could live with it. +0

Well if you really want to you can overwrite __str__() so that it returns only the username. But that would be very unintentional IMHO. The username string simply had to be replaced by a full blown class. sorry.


Work Items

This blueprint contains Public information 
Everyone can see this information.


No subscribers.