CERN Accélérateur de science

WebAccess Table Structure

Explanation of the WebAccess table structure and how to create authorizations.

-- accROLE --

roles are collections of authorizations within specified areas. these should
have a clear connection, for example within a module or for a special type of
person, e.g a library administator.

              id - specify the id of the role

            name - unique name for the role

     description - describe the authorization tasks the role will cover

firerole_def_ser - precompiled serialized firewall like role definition (firerole)

firerole_def_src - definition text source for repairing after Python upgrades


-- user_accROLE --

give users access to the authorizations/actions provided by the given role.

   id_user - id of user in the database, usually just the CFG_SITE_SUPPORT_EMAIL and/or CFG_SITE_ADMIN_EMAIL

id_accROLE - id of role from accROLE


-- accACTION --

the actions specify what information is needed to create an authorization.
an action can take any number of arguments, and you also have the possibility to
make these arguments optional.

             id - specify the id of the action

           name - unique name for the action

    description - describe authorization area

allowedkeywords - the keywords for the wanted arguments

       optional - enum to define wether arguments can be optional
                  value: ['yes', 'no']

                  'no'  - action without arguments or not optional arguments
                  'yes' - only actions with arguments


-- accARGUMENT --

arguments for the authorizations. one entry might be shared by several authorizations,
so it is important to not change these but simply add new ones when a change is needed.

     id - id of the argument

keyword - the one listed in an action's allowedkeywords

  value - the value connected to the keyword in an keyword=value argument pair


-- accROLE_accACTION_accARGUMENT --

ternary connection to create authorizations. when an authorization has more than
one argument they need to be connected somehow. the same id for role, action and
argumentlist does this. there must be at least as many entries as allowedkeywords
for the action. with more entries all authorizations are found using a cross product.

id_accARGUMENT and argumentlistid are both set to 0 when the action have no arguments.
with optional arguments they are both set to -1.

    id_accROLE - reference to argument in table accROLE

  id_accACTION - reference to argument in table accACTION

id_accARGUMENT - reference to argument in table accARGUMENT

argumentlistid - glue to bind entries into authorizations.