Class SystemTablePermissions
java.lang.Object
com.kingsrook.qqq.backend.core.actions.permissions.SystemTablePermissions
Permission rules for QQQ's own system tables: the tables the framework
writes for itself, about every user, rather than an application's data.
Two kinds:
- Readable system tables (the audit trail and query statistics) require an
explicit permission to read directly (table query, get, count, export,
reports and possible values, through every API): audit.read for the audit
tables, queryStat.read for the query statistics tables. Holders see them
as ordinary tables. Everyone else still sees a record's history through
the GetAuditsForRecord process, which checks that they may read the
record instead.
- Internal tables (userSession, redirectState, userSessionRefreshToken) hold
session ids, access tokens, refresh tokens and login state. They are
hidden and require a permission no role is ever granted, so no user,
admins included, can query them; only the authentication modules (as the
system user) read and write them.
The rules are set by the tables' meta-data providers. An application that
sets its own permission rules on one of these tables after defining it
replaces them.
-
Field Summary
FieldsModifier and TypeFieldDescriptionstatic final Stringpermission base name shared by the four audit tablesstatic final Stringthe permission to read the audit tables directlystatic final Stringpermission base name shared by the four query statistics tablesstatic final Stringthe permission to read the query statistics tables directly -
Method Summary
Modifier and TypeMethodDescriptionstatic QPermissionRulesinternalTableRules(String tableName) Rules for an internal table: a dedicated permission that no role should ever be granted (and that, as the table is hidden, is not offered among the instance's available permissions).static booleanisSystemTable(String tableName) Whether a table name is one of QQQ's system tables (see the class comment).static voidlockConfiguredAuthenticationTables(QInstance instance) Called by the enricher: lock the OAuth2 session, redirect-state and refresh-token tables an instance names in its authentication meta-data, for any that the application defined itself (not through QQQ's producers, which lock them already) without permission rules.static QTableMetaDatalockInternalTable(QTableMetaData table) Hide and lock an internal table (see internalTableRules).static StringnoAccessPermissionBaseName(String tableName) The never-granted permission base name of an internal table.static QPermissionRulesreadableSystemTableRules(QInstance instance, String permissionBaseName) Rules for a readable system table: reading it needs [baseName].read.
-
Field Details
-
AUDIT_PERMISSION_BASE_NAME
permission base name shared by the four audit tables- See Also:
-
AUDIT_READ_PERMISSION
the permission to read the audit tables directly -
QUERY_STAT_PERMISSION_BASE_NAME
permission base name shared by the four query statistics tables- See Also:
-
QUERY_STAT_READ_PERMISSION
the permission to read the query statistics tables directly -
AUDIT_TABLE_NAMES
-
QUERY_STAT_TABLE_NAMES
-
INTERNAL_TABLE_NAMES
-
-
Method Details
-
isSystemTable
Whether a table name is one of QQQ's system tables (see the class comment). -
readableSystemTableRules
public static QPermissionRules readableSystemTableRules(QInstance instance, String permissionBaseName) Rules for a readable system table: reading it needs [baseName].read. An instance whose default rules are protected keeps its level (so, e.g., HAS_ACCESS_PERMISSION instances use [baseName].hasAccess); an unprotected default becomes READ_INSERT_EDIT_DELETE_PERMISSIONS. The tables have no insert, edit or delete capabilities, so only read is ever offered. -
internalTableRules
Rules for an internal table: a dedicated permission that no role should ever be granted (and that, as the table is hidden, is not offered among the instance's available permissions). -
noAccessPermissionBaseName
-
lockInternalTable
Hide and lock an internal table (see internalTableRules). -
lockConfiguredAuthenticationTables
Called by the enricher: lock the OAuth2 session, redirect-state and refresh-token tables an instance names in its authentication meta-data, for any that the application defined itself (not through QQQ's producers, which lock them already) without permission rules.
-