Role based ingame rights...?

[FunkyBit]

Hi out there in the wild!

I came up with an idea to modify and improve the ingame rights system.

Currently rights are accumulated with increasing security level.

That's a rather... outdated way of handling rights and their distribution to the staff.

Almost any forum has role based rights management, without it there would be hell ^^

On servers where you want to have a bit more ranks and a more complex permission structure the current system of increasing and accumulating rights is... a pain in the ass.

Suggest you want to have Dev's that have an account to teleport, inspect and test stuff they just developed and check if commits and DB queries were included right. They should teleport and have access to the debug commands but should not modify any character any way. But your GMs should do that but should not have access to debug commands. Then there are some kind of ingame Mods who look after the chats and behaviour. They should be able to mute and maybe kick characters but nothing more but Devs shouldn't be able to do that.

Try to modify that and much more in the current system... i gave up.

So the idea was born the have a role based rights managment like in forum software.

So you have many different possible roles that you can assign individual rights without warping these rights to outer user groups.

I have to admit I have no idea how to start or do that...

But maybe... YOU can and like the idea! ^^

What do you think about a role based system? Is there something better or am I missing something?

[Diablox]

Divide GM commands in groups. Give each group a unique id in this order 1, 2, 4, 8, 16... and then just add sum of all group id's you want to give to one account in account table. You can easily add more command groups and even make commands repeat in some groups.

[Patman128]

That, or use a letter-based system like Ascent-derivatives.

Anyway, I'm content with the way mangos does it right now. I don't see why developers wouldn't need to be able to modify characters for health or items etc. If you don't trust someone, you shouldn't be giving them privileges in the first place.

[darkstalker]

devs usually have write access to database, so limiting them ingame its meaningless

[shauren]

makes a lot of sense, this way is easier to create custom gm ranks for servers (just go for your flags idea, not shit ascent letters which i hate)

[FunkyBit]

I don't see why developers wouldn't need to be able to modify characters for health or items etc. If you don't trust someone, you shouldn't be giving them privileges in the first place.

I learned that it is not wise to give anybody of your team the rights to do anything. They lose focus and start to work in the fields of others after some time. And Dev's can be defined in many ways. Usually I would prefer Dev's do generally work on their own MaNGOS systems and have one or two that can acctually commit (see MaNGOS itself, not everybody can commit to GIT and that is good!).

devs usually have write access to database, so limiting them ingame its meaningless

See bevor. I would not give any Dev complete write access to DB and server. Why should I? Dev's should deliver patches and bundles that are reviews by one or two lead Dev's who in the end activate changes. That's almost normal in larger developing processes, you need core review and approvement by others until your changes get accepted (again see MaNGOS).

Give it a try and model your own forum structure with a linear rights model like MaNGOS.

You have Mod's for different areas. There are different user groups that have access to different sections of the forum. And so on.

Diablox idea is a start. But there still are problems. In the core there are parts like "what is written to a log", "who can see whom in gm invisible", all the sec_* stuff is still linear in the core even if I start to tune the command table and the accumulation of rights during read in on startup.

[Unkle Nuke]

A good administrator ought to be able to keep control of his helpers. If he can't then he should probably find another hobby. I peruse my logs at the end of each day to make sure nobody is abusing their privileges. I follow a zero-tolerance policy. If you're not mature and responsible enough to follow my rules, you lose your status. No second chances, no reprieves.

On the other hand, juggling security levels to properly assign usable commands can be a huge pain. A role-based system would simplify this, but it would require a rewrite of the security management currently in place. This assumes a server with a large management structure. Servers that are set up with the administrator also being the only developer wouldn't benefit greatly from a role-based management scheme.

[DaViper]

I agree with UnkleNuke, Yes a large server with a large staff yes go for it, but like he stated, I'm a little server with almost no staff...just a couple freinds that test and me trying to fix everything with basicly no help and a system like your proposing would make it a lot harder to do anything. Question are you going to include a manual with this and how many pages because I hate to read.

[FunkyBit]

I don't see much problem...

You have some sort of table structure:

Table: right_role (with general settings)

| id | name | isOnGMList | logToGMLog | logToUserLog | noLogoutDelay | ...

Table: right_options (sets specific rights for each role)

| id (refering to right_role table) | right_id | value | value2

right_id's corespond to the in-code used flags or contants or whatever that identifies an ability to use some command. value/value2 may be true or fale or even an integer value (not currently used) that defines in what range a command can be used.

So setting up a very simple role structure would mean you use the then existing default shipped with the mangos inital db query or slightly modify the initally by the mangos db query installed rights:

You define roles: Mod, GM, Admin

You add a right to these roles just by adding a line or delete a line.

I realy can't understand why this should be difficult or cost more than 10 minutes work...

[Schmoozerd]

so, why don't you do this then?

[FunkyBit]

Because theorie is something different than practice.

I know what I would like to have but I can't perform the changes myself.

That's why I want to discuss it here and maybe someone with the necessary skills finds it worth his time.

If you refer to the subline of this subforum ("Discuss code, review existing code, submit patches, or write implementation drafts for new and missing features.")... no I don't have any draft or anything that can be the start of it.

It's just an idea and I'm searching for fans with skill.

[Diablox]

FunkyBit i can't understand why do you need 2 new tables with so many fields. Can you put some light on that idea if you want?

thx

[Unkle Nuke]

There's also the human factor involved, something IT security specialists like to call "Trustability". (Don't you just love the way professions make up words?)

Role-based security implies a low degree of trust among the administrative staff. In other words, you're not really all that sure what your GMs, devs, or mods might do behind you back. This is based on the truism that power corrupts. Give a guy some freedom to execute commands and he will invariably begin to abuse those commands for his own convenience. In an environment where staff members are not socially close, such as friends might be, this allows a staff member to feel a certain anonymity that can "hide" his misdeeds.

Where you have a small staff that is closely bonded, you can have a high degree of trust. Peer pressure, personal integrity, or even old-fashioned decency will incline one to honor those ties of trust more than the impersonal environment of a large server staff. Here, you're a valued friend or well regarded colleague, not just another cog in the machine. It's a social place where you are more likely to actually care about the consequences of your actions, if not fear being cast out by your peers.

Role-based security is a double-edged sword. On the one hand, it helps to limit the damage a staff member may inflict by tightly defining their role. However, it can also act as a barrier to expanding trustability by insulating people from each other within a hierarchy that can quickly turn into an elitist cult of personality. At that point you again have abuses of power. If you use such a security model, it is still your responsibility, as the administrator and server owner, to foster an esprit de corps among your staff members and encourage the social dynamic of a high-trust environment to avoid some of the pitfalls that can occur with boxing everyone into their specific area.

No matter what security model you adopt, not one single line of code can be an adequate substitute for common sense, sound judgment, and a sensible regard for your server's staff. Be vigilant, but be kind.

[DasBlub]

are we now a group of sociology students? how about NOT talking about the human-factor crap in this and just talk about the technical part?

Diabolix, you need two or three tables because of the 3rd normal form for databases

role (id, name) - role_right (role_id, right_id) - right (id, name)

a role can be "user", "admin", etc.

a right can be "command .server info", "has logout delay", etc.

-- DasBlub

[FunkyBit]

FunkyBit i can't understand why do you need 2 new tables with so many fields. Can you put some light on that idea if you want?

As DasBlub already said, there are design reasons. In theory you can model the whole MaNGOS database in ONE table. But you would never do that because... well it would be hell!

Data is mostly split up to match a normal form of database structure (http://en.wikipedia.org/wiki/Database_normalization). That's said simply to reduce data redundancy.

Role-based security implies a low degree of trust among the administrative staff. In other words, you're not really all that sure what your GMs, devs, or mods might do behind you back. This is based on the truism that power corrupts. Give a guy some freedom to execute commands and he will invariably begin to abuse those commands for his own convenience. In an environment where staff members are not socially close, such as friends might be, this allows a staff member to feel a certain anonymity that can "hide" his misdeeds.

Where you have a small staff that is closely bonded, you can have a high degree of trust. Peer pressure, personal integrity, or even old-fashioned decency will incline one to honor those ties of trust more than the impersonal environment of a large server staff. Here, you're a valued friend or well regarded colleague, not just another cog in the machine. It's a social place where you are more likely to actually care about the consequences of your actions, if not fear being cast out by your peers.

As I said bevor structuring rights and permissions is also used to limit people to their field of tasks. A Dev with access to everything will start to give support or handle things his time is too valuable for.

Imagine Vladimir would start to moderate this forum and loose focus from - we all thank good he is doing it - committing so wonderfull code changes.

And you speak of small staff. And big staff? And what if some of your small staff quit the job or lose interest? Where do you get new ones? How do you test them? Do you give away all rights right from the beginning? Is a trial perido for new members not a totaly normal thing?

If I had the possibility to bring people in my team I don't know perfect and therefor can't trust perfect, but I can integrate them to do some of the tasks I would have to do... and if I could controle their powers without to worry that they do crap... I can give people a chance to prove them who otherwise I could never give a chance because of structure reasons.

And as some of you said "my server is small, I don't need that"... yes, okay, go with it, no problem at all. But that's no reason NOT to do it anyway.

MaNGOS is for learning. I do a lot of that these days. And I believe that a role based permission system is much more advanced and flexible than a linear accumulation system. And reality gives me right.

Forum software and MySQL itself are good candidates where other more primitive systems would be hell to handle.

And also I belive that setting up such a system is just slightly more effort than it is now.

And for the end... the power of a role based model is greater than the current one but you can model the current one in it. So no one loses anything. Some gain something.

[Patman128]

Personally, I think the best system would just be to have the same one as right now, only to allow commands to set individual rights for each level instead of just level X and up. This would mean no new tables or fields.

For example, a command that only supports level 4 right now would just be "4" in the commands table, but a command that supports security >= 1 would be "1 2 3 4", and if you wanted it to be for 1, 2, and 4 only it would be "1 2 4". Simple, easy.

It would also mean it could be done in a simple mangos DB update; i.e.

 -- changes security column to string, then...
UPDATE commands SET security = "0 1" WHERE security = "1";
UPDATE commands SET security = "0 1 2" WHERE security = "2";
etc, etc

No adding up flags, no crazy letter system. If you guys like it, I could make up a patch for it.

[Baileys]

The talk of trust and small servers and so on...thats no argument.

There are many Servers that have more than 10-20 people. Sure, if you have a small server you have probably 3 friends to manage it. You now them from reallife or whatever.

But believe me, trust is not a bad thing, but i see it every day that people for example give there password to their best friends or siblings. For trusting them, they delete chars or use the chars for illegal things. Not everyone does that, but at a high populated server, you don't know everyone from your staff in reallife. And also if you know them, things can be abused like in the example.

You can controll many with logs and so on, but that costs time. Why don't give people just the rights they need? Not more not less. Easier to control and you dont't lead the people into temptation.

A better question: Why should I give people rights they don't need? (like it can be in the actual system)

It is not vitally important but it can be helpful for high pupulated servers (and also for middle populated servers).

If the ingame rights would be role-based you would have the choice to use it role-based or like the actual system, according your preferences.

Now you have no choice.

So, i think its a good idea. If someone likes to do it, i would be delighted.

EDIT: nice idea patman

[FunkyBit]

THAT models exactly what I tried to describe bevor.

It is in a way a role based model where you just flip order of defining.

I thought about defining roles and adding rights.

Your idea defines rights and adds roles to them. Almost the same

Well, that would be a wonderful improvement!

[Mythli]

A role-based right system only have benefits because you can just do "the old thing"

I'm a Web-developper, all things that our company manage or developp have role based right management because it's more flexible, stable and comfortable for us and our customers.

Maybe someone who has the time and skill to implement this very nice feature will read this thread and start developping.

Mythli<3