Skip to content
This repository has been archived by the owner on Sep 3, 2021. It is now read-only.

Groups

Jump to bottom
Alice Zoë Bevan–McGregor edited this page Aug 20, 2014 · 4 revisions

Groups are the fundamental access control mechanism exported by the Core service to applications. They are identified by their tag, a short, lower-case, dot-notation string, and contain ACL rules which are evaluated to determine membership.

Using combinations of the ACL rules you can have Groups whose membership is carefully, and automatically, controlled based on their public character information. ACL rules are evaluated and may pass, fail, or skip; return values of True, False, and None respectively. They are evaluated from top to bottom, and if no rules match (all return None) access is denied by default.

Each rule instance will either grant or deny access, if matching, or be skipped. Additionally, each rule may be inverted so as to treat skipping as a match and vice-versa. I.e. grant or deny access if the character isn’t in a given list.

Most rules follow a specific pattern best shown in code

if a_winner_is_you:
    return None if self.inverse else self.grant
    
return self.grant if self.inverse else None

This allows for consistent application of the grant and inverse attributes:

  • grant — if the rule evaluates successfully do we authorize access (True) or deny it?
  • inverse — if the rule evaluates, do we keep processing rules (True) or stop? If the rule doesn’t evaluate, do the opposite of this.
grant inverse Description
True False Stop processing if the rule evaluates truthy and grant access, otherwise keep processing.
True True Keep processing if the rule evaluates truthy, otherwise grant access.
False False Stop processing if the rule evaluates truthy and deny access, otherwise keep processing.
False True Keep processing if the rule evaluates truthy, otherwise deny access.

Consider the following arbitrarily complex requirement:

  • The BDFL must always have access.
    1. ACLList(Character, [bdfl], grant=True, inverse=False)
  • Everyone else must have an account-wide API key and basic mask.
    1. ACLKey(Account, grant=False, inverse=True)
    2. ACLMask(Basic, grant=False, inverse=True)
  • But! If you are a member and have a POS management role you need a full API mask.
    1. ACLList(Alliance, [BRAVE], grant=True, inverse=True)
    2. ACLRole(POSMgr, grant=True, inverse=True)
    3. ACLMask(Full, grant=True, inverse=False)

Bada bing, you have your ACLRule chain. Any time you have a series of questions that need answering you will probably be using a chain of grant=False, inverse=True rules.

ACL Rules

List

This rule matches against a list of characters, corporations, or alliances. Each ACL List rule will only match against one of these, so if you want to allow access to a list of characters and corporations you will need two ACL List instances.

Key Type

Match based on the type of API key provided for the character. As multiple API keys may be registered and cover the same character, this rule will match if any of the valid EVE API keys is of the type indicated. Type may be one of:

  • Account
  • Character
  • Corporation

Title

Match if the character has the given title amongst all of their titles. Ignores HTML-like tags, i.e. the colour definitions Brave Newbies Inc. uses. For example, match characters whose title is Fleet Commander.

Role

Match based on the character having a set of roles. This uses CCP’s internal terminology for these roles.

Roles include: roleAccountCanTake1-7, roleAccountant, roleAuditor, roleCanRentFactorySlot, roleCanRentOffice, roleCanRentResearchSlot, roleChatManager, roleContractManager, roleDiplomat, roleDirector, roleEquipmentConfig, roleFactoryManager, roleFittingManager, roleInfrastructureTacticalOfficer, roleJuniorAccountant, rolePersonnelManager, roleSecurityOfficer, roleStarbaseCaretaker, roleStarbaseConfig, roleStationManager, roleTrader

Mask

Matched based on having an EVE API key capable of servicing the EVE API calls defined by the given mask.

“Very Secure”

Proposed ACLRule to check if the account is configured to require an OTP token and has at least one registered.

Sample Rules

Alliance Diplomats

  • ACLList(corporation, “Brave Newbies Inc.”, grant=False, inverse=True) # deny anyone outside BNI
  • ACLRole(roleDiplomat, grant=True)

Fleet Commanders

  • ACLList(alliance, “BRAVE”, grant=False, inverse=True) # deny anyone outside alliance
  • ACLTitle(“Fleet Commander”, grant=True)

Leadership

  • ACLList(alliance, “BRAVE”, grant=False, inverse=True) # deny anyone outside alliance
  • ACLKey(account, grant=False, inverse=True) # require an account key to continue
  • ACLMask(268435455, grant=False, inverse=True) # require a full key to continue
  • ACLRole(roleDirector, grant=True)

Council

  • ACLList(alliance, “BRAVE”, grant=False, inverse=True) # deny anyone outside alliance
  • ACLKey(account, grant=False, inverse=True) # require an account key to continue
  • ACLMask(268435455, grant=False, inverse=True) # require a full key to continue
  • ACLTitle(“CNM Member”, grant=True)
  • ACLTitle(“Council Member”, grant=True)

Member

  • ACLList(alliance, “BRAVE”, grant=True)
Clone this wiki locally