Flexible - Revision history

B3b0tUzR at 14:41, 3 August 2021

2021-08-03T14:41:22Z

B3b0tUzR at 14:39, 3 August 2021

2021-08-03T14:39:12Z

B3b0tUzR at 14:37, 3 August 2021

2021-08-03T14:37:49Z

B3b0tUzR at 14:32, 3 August 2021

2021-08-03T14:32:26Z

B3b0tUzR at 14:23, 3 August 2021

2021-08-03T14:23:41Z

B3b0tUzR at 14:13, 3 August 2021

2021-08-03T14:13:49Z

B3b0tUzR at 14:12, 3 August 2021

2021-08-03T14:12:52Z

B3b0tUzR: Created page with 'Introduction Flexible security groups allow the definition of group memberships by conditions instead of fixed member lists. So instead of keeping track per hand who all meets s…'

2020-09-16T21:51:34Z

Created page with 'Introduction Flexible security groups allow the definition of group memberships by conditions instead of fixed member lists. So instead of keeping track per hand who all meets s…'

New page

Introduction

Flexible security groups allow the definition of group memberships by conditions instead of fixed member lists. So instead of keeping track per hand who all meets some condition you can just tell the bot all who meet condition A are members of group B. An example would be a raidbot shared among several orgs. Just add a group checking if anyone is a member of one of the orgs to grant access, instead of keeping memberlists update every day via rosters. Or you can grant guest status to everyone of one faction above a selected level. The conditions are compared to the entry in the whois cache for the checked character.
How does a flexible group work?

Each existing security group can be extended with one flexible security group. The classical security group defines the name and the access level for both the normal and the flexible group. The normal security group can still have fixed members.

A flexible security group consists of a set of conditions that either have all to be met (AND-combined flexible groups) or at least one has to be met (OR-combined flexible groups). If you have conditions that only can be written in a combination of AND and OR you'll have to use several AND-combined security groups to split the conditions up.
Fields allowed in conditions

There are six fields allowed in conditions, each with a limited set of compare-operators supported.

level for the level of a character. All numeric compare operators are allowed for this field (<, ⇐, =, >=, !=, >).
profession for the profession of the character. = and != are supported operators.
faction for the faction of the character. = and != are supported operators. In addition to the three factions ingame the pseudo-faction all is supported too, it meets all three factions at once.
rank_id for the organizational rank of the character. All numeric compare operators are allowed (<, ⇐, =, >=, !=, >).
org_id for the ID of the organization the character may be in. IDs don't change, org names may change, that's why this is supported instead of the org name. = and != are the supported operators.
at_id for the alien level of the character. All numeric compare operators are allowed (<, ⇐, =, >=, !=, >).

Internal workings

On a check for the highest access level of a character the security framework queries the flexible extension if installed. First it checks the current cache if the character already got an entry, and returns that if existing. If no cached entry is found it checks all security groups with higher access level then the currently found one for flexible extensions. Those groups are sorted in descending order of access levels, with the highest first. The conditions of the flexible extensions existing are formed into a SQL query in the whois cache. If the query returns a result the player is a member of the currently checked group, and the access level of that group is returned. If not any further existing groups are checked afterwards.
Examples

Grant admin rights to members in the second highest rank in example org (org_id: 12345):

Create a security group granting admin rights (or just use the default ADMIN group)
Create an AND-combined flexible security group extending this group
Add a rule checking for org membership org_id = 12345. All org checks are done with org ids, as those are fixed over the existance of the org. Org names can be changed.
Add a second rule checking for rank_id equal to 1 rank_id = 1

← Older revision		Revision as of 14:41, 3 August 2021
Line 60:		Line 60:

	Important note :		Important note :
−	For the !minlevel and !faction commands to work you have to config a flexible group for guest access and enter the name into the setting Guest_Group of the Flexible_Security module	+	For the !minlevel and !faction commands to work you have to config a flexible group for guest access and enter the name into the setting Guest_Group of the Flexible_Security module, as explained here http://bebot.link/helpful-posts/secured-public-ao-bot/msg20331/

@@ Line 15: / Line 15: @@
      '''level''' for the level of a character. All numeric compare operators are allowed for this field (<, <=, =, >=, !=, >).
      '''profession''' for the profession of the character. = and != are supported operators.
-     '''faction''' for the faction of the character. = and != are supported operators. In addition to the three factions ingame the pseudo-faction all is supported too, it meets all three factions at once.
+     '''faction''' for the faction of the character. = and != are supported operators. In addition to the three factions ingame the pseudo-faction '''all''' is supported too, it meets all three factions at once.
      '''rank_id''' for the organizational rank of the character. All numeric compare operators are allowed (<, <=, =, >=, !=, >).
      '''org_id''' for the ID of the organization the character may be in. IDs don't change, org names may change, that's why this is supported instead of the org name. = and != are the supported operators.

@@ Line 32: / Line 32: @@
      Create a security group granting ADMIN rights (or just use the default ADMIN group)
-     Create an AND-combined !flexible security group extending this group
+     !addgroup admined group to give admin level
      Add a rule checking for org membership org_id = 12345. All org checks are done with org ids, as those are fixed over the existance of the org. Org names can be changed.
-     Add a second rule checking for rank_id equal to 1 rank_id = 1
+     !flexible condition add admined org_id = 12345
 If oppositely you'd want to open your bot at GUEST level to anyone:
@@ Line 44: / Line 50: @@
       !security levels => click on GUEST link in the "guested" group entry below
       !security groups => verify "guested" group is now marked at GUEST access level
-     Create an AND-combined !flexible security group extending this group
+     Create an AND-combined !flexible extension for this group
       !flexible => click on AND-combined link in the "guested" group creation line
      Add a rule checking for player level to be at least 1
@@ Line 52: / Line 58: @@
      Finish by checking the new rank of our player (should now be GUEST as expected)
       !security whois playername

@@ Line 1: / Line 1: @@
 ''Introduction''
-Flexible security groups allow the definition of group memberships by conditions instead of fixed member lists. So instead of keeping track per hand who all meets some condition you can just tell the bot all who meet condition A are members of group B. An example would be a raidbot shared among several orgs. Just add a group checking if anyone is a member of one of the orgs to grant access, instead of keeping memberlists update every day via rosters. Or you can grant guest status to everyone of one faction above a selected level. The conditions are compared to the entry in the whois cache for the checked character.
+!flexible security groups allow the definition of group memberships by conditions instead of fixed member lists. So instead of keeping track per hand who all meets some condition you can just tell the bot all who meet condition A are members of group B. An example would be a raidbot shared among several orgs. Just add a group checking if anyone is a member of one of the orgs to grant access, instead of keeping memberlists update every day via rosters. Or you can grant guest status to everyone of one faction above a selected level. The conditions are compared to the entry in the whois cache for the checked character.
-Each existing security group can be extended with one flexible security group. The classical security group defines the name and the access level for both the normal and the flexible group. The normal security group can still have fixed members.
+''How does a !flexible group work?''
-A flexible security group consists of a set of conditions that either have all to be met (AND-combined flexible groups) or at least one has to be met (OR-combined flexible groups). If you have conditions that only can be written in a combination of AND and OR you'll have to use several AND-combined security groups to split the conditions up.
+Each existing security group can be extended with one !flexible security group. The classical security group defines the name and the access level for both the normal and the !flexible group. The normal security group can still have fixed members.
 Fields allowed in conditions
 There are six fields allowed in conditions, each with a limited set of compare-operators supported.
-     '''level''' for the level of a character. All numeric compare operators are allowed for this field (<, ⇐, =, >=, !=, >).
+     '''level''' for the level of a character. All numeric compare operators are allowed for this field (<, <=, =, >=, !=, >).
      '''profession''' for the profession of the character. = and != are supported operators.
      '''faction''' for the faction of the character. = and != are supported operators. In addition to the three factions ingame the pseudo-faction all is supported too, it meets all three factions at once.
-     '''rank_id''' for the organizational rank of the character. All numeric compare operators are allowed (<, ⇐, =, >=, !=, >).
+     '''rank_id''' for the organizational rank of the character. All numeric compare operators are allowed (<, <=, =, >=, !=, >).
      '''org_id''' for the ID of the organization the character may be in. IDs don't change, org names may change, that's why this is supported instead of the org name. = and != are the supported operators.
-     '''at_id''' for the AO alien level of the character. All numeric compare operators are allowed (<, ⇐, =, >=, !=, >).
+     '''at_id''' for the AO alien level of the character. All numeric compare operators are allowed (<, <=, =, >=, !=, >).
 ''Internal workings''
-On a check for the highest access level of a character the security framework queries the flexible extension if installed. First it checks the current cache if the character already got an entry, and returns that if existing. If no cached entry is found it checks all security groups with higher access level then the currently found one for flexible extensions. Those groups are sorted in descending order of access levels, with the highest first. The conditions of the flexible extensions existing are formed into a SQL query in the whois cache. If the query returns a result the player is a member of the currently checked group, and the access level of that group is returned. If not any further existing groups are checked afterwards.
+On a check for the highest access level of a character the security framework queries the !flexible extension if installed. First it checks the current cache if the character already got an entry, and returns that if existing. If no cached entry is found it checks all security groups with higher access level then the currently found one for !flexible extensions. Those groups are sorted in descending order of access levels, with the highest first. The conditions of the !flexible extensions existing are formed into a SQL query in the whois cache. If the query returns a result the player is a member of the currently checked group, and the access level of that group is returned. If not any further existing groups are checked afterwards.
 ''Examples''
@@ Line 27: / Line 32: @@
      Create a security group granting ADMIN rights (or just use the default ADMIN group)
-     Create an AND-combined flexible security group extending this group
+     Create an AND-combined !flexible security group extending this group
      Add a rule checking for org membership org_id = 12345. All org checks are done with org ids, as those are fixed over the existance of the org. Org names can be changed.
      Add a second rule checking for rank_id equal to 1 rank_id = 1
@@ Line 33: / Line 38: @@
 If oppositely you'd want to open your bot at GUEST level to anyone:
      Create a security group granting GUEST level
       !addgroup guested group to give guest level
       !security levels => click on GUEST link in the "guested" group entry below
       !security groups => verify "guested" group is now marked at GUEST access level
-     Create an AND-combined flexible security group extending this group
+     Create an AND-combined !flexible security group extending this group