Service - Account Limits

Overview

Controls a user's limits for actions based on their roles set in Service - RBAC

• Works out each user’s site limits according to the user’s app_level RBAC roles
• Records user’s usage for counted limit types

Repository

https://bitbucket.org/izara-core-user-accounts/izara-core-user-accounts-account-limits/src/master/

DynamoDB tables

Standard Config Table Per Service

Configuration tags

{
	configKey: "RbacServiceName"
	configTag: "RbacServiceName"
	configValue: xxx // eg: "RBAC"
}

RoleLimit

Sets the limits applied to each role

{
	roleLimitId: xxx
	limitType: xxx
	limitValue: xxx
}

• partition key: roleLimitId
• sort key: limitType
• roleLimitId: roleId + "_" + "limitTag"
• limitType is "static"|"timeBasedDynamic"|"runningTotal", if timeBasedDynamic also concatenate "_" + limitUnit
• limitUnit: for timeBased limitType, eg: "days"|"hours"|...

TimeBasedDynamicUsage

{
	dynamicUsageId: xxx
	usedTimestampId: xxx
	usageCount: xxx // integer
	decreaseUsage: true // if increase not add this attribute
	timeBasedUsageStatus: reserved|confirmed|cancelled
}

• partition key: dynamicUsageId
• sortKey: usedTimestampId
• dynamicUsageId: userId + "_" + limitTag
• usedTimestampId: {timestamp reserved use}_{uniqueRequestId}, add uniqueRequestId to ensure each request is unique
• count allows more than 1 usage to be applied per request

RunningTotalUsage

{
	userId: xxx
	limitTag: xxx
	totalCount: xxx // integer
	updateUuid: xxx // random number, used in conditional when updating count to protect against race conditions
}

• Partition key could possibly be userId + "_" + limitTag with no sort key

RunningTotalReservedUsage

{
	runningTotalReservedId: xxx
	usedTimestampId: xxx
	usageCount: xxx // integer
	decreaseUsage: true // if increase not add this attribute
	runningTotalUsageStatus: reserved|confirmed|cancelled
}

• partition key: runningTotalReservedId
• sortKey: usedTimestampId
• runningTotalReservedId: userId + "_" + limitTag
• usedTimestampId: {timestamp sent with request}_{uniqueRequestId}, this allows us to check idempotence and not reserve same request multiple times
• count allows more than 1 usage to be applied per request
• records are not deleted once they are confirmed or cancelled, so a record is kept of changes

Limit types

static limits

• limits that are fixed
• eg size limit for an uploaded photo or video.
• static limits do not need to record usage by each user

time based limits

• eg number of products can list per day.
• have a record of usage
• when the user attempts to perform action it is checked first to not exceed their limit, then the use is reserved, once the client service completes the action the use is confirmed
• timeBasedDynamic: counts usage over the last period, counted from the time the request to perform the use is made
• Might need a cleanup process to remove really old records as not used after period passes

running total limits

• Maximum number of times an action can be performed
• eg maximum number of products a user can list.
• usage is counted but not time based
• can be added to or subtracted from
• eg: storage_space_used
• has process to reserve usage

FindData in RBAC

Use FindData in RBAC to find a users current limits, this will allow for cacheing and can add to tables/SearchResults etc..

Ideas

• Currently thinking cannot have per user overwrites, can create roles to affect limits
• Could have per user/catalog limits too, probably as separate Account Limit services
• another possible time based limit: (can add later) time_based_period: has a set time when the count is reset, eg: per day, count resetting at midnight

Working documents

Account Limits