The AppStax Data Access Security Model


Data access is secured through multiple layers in the AppStax platform. Obviously, all communications between the clients and the AppStax platform is done through SSL. In addition, you as app developer have several fixtures available to make sure your endusers' data are secure.

Collection Level Permissions

Collection permissions are access permissions you set on a collection. They can be thought of as a form of default permissions for every object stored in the collection. Every collection comes with a default set of permissions, which can be changed in the admin UI.

Collection level permissions are managed in the AppStax Admin UI.

There are five types of collection permissions:

Permission Explanation
create Create object in collection
read Retrieve/read object in collection
update Update object in collection
delete Delete object in collection
grant Grant a named user create, read, update, delete or grant permissions at the collection level

Collection permissions are set in two different ways. First, they can be set for a particular group of users, as explained in a moment. Second, they can be set for a specifically named user.

Setting collection permissions for groups of users

Collection permissions can be set for the following groups of users. Note that the group in each row of the table below includes the group of users of the row above.

Group Explanation
Admin The app owner, and any other developers the app owner has invited to collaborate.
Object owner The owner (initial creator) of the object
Authenticated users Any app enduser who exists in the users collection in the app.
All users Not only app developers and authenticated users, but also unauthenticated users.

Because the group in each row of the table includes the group in the row above, setting e.g., a create permission to authenticated users also allows admin users (app developers) and object ownersthe same permission. Unauthenticated (public) users can not access the object.

Setting collection permissions for named users

While setting collection permissions for groups of users is very useful in order to provide a basic access control scheme for your collection, you will often experience the need to grant specific users special permissions that other users do not have. For example, in order to allow a superuser to create other regular users, you need to grant that special user a create permission on the users collection.

Example: Managing the countries users come from

In many situations you will need to add static metadata to your app. One common example in any online store is the need to register which country a user comes from. Say you model this using a countries collection, with one object for each country. Because you do not want just anybody to manipulate this collection, you want to grant a superuser create, update and delete permission.

However, you also want to make sure all users can actually read objects in this collection, for example somewhere in your app you provide the user the ability to choose which country they come from. Therefore you make sure you grant read permission for the role all users.

Object Level Permissions

Object level permissions are access permissions you set on a specific object.

The following permissions can be granted to a named user for a specific object:

Permission Explanation
read Retrieve/read the specific object in collection
update Update the specific object in collection
delete Delete the specific object in collection
grant read Grant a named user the permission to grant read on the specific object to other users
grant update Grant a named user the permission to grant update on the specific object to other users
grant delete Grant a named user the permission to grant delete on the specific object to other users

Anonymous users (public access)

In addition to named users, object level permissions can be granted to all users. This is achieved by specifying the username * instead of a username.

Revoking access

All the object level permissions above can be revoked by any user who has the corresponding grant permission. For example, a user who has been granted grant read, can then revoke read from a different user.

The owner of an object always retains all permissions on that object.

Permissions across relations

Relations are a feature of AppStax that lets you define a relation between two objects. When you create a relation from object O1 to O2, AppStax verifies that you have update permission on O1 and read permission on O2. When you attempt to retrieve objects through relations by expanding the relation, AppStax verifies that you also have permission to read the objects on the other side of the relation. This ensures that you do not see or do anything you have not been granted permission to do.


The following use cases show how the security of three different apps can be modeled using the features described here.


Assume there is a messages collection for twitter-style messages. Assume some users are registered (authenticated), while other users are unatheunticated (public).

  • Authenticated users can create messages.
  • All users can read messages.
  • Message owner can update message.

Set create permission on messages collection to authenticated users. Set read permission to all users. Set update permission to object owner.

HelpDesk app

A help desk app lets any authenticated user create a support case. Only certain named superusers can read or update those cases. Only the initial creator of the support case (as well as superusers) can add comments to the case. The relation between a support case and its comments is defined as a one-to-many relation from support case to comments.

  • Authenticated users can create support cases.
  • Owners of support cases can read their own cases.
  • Superusers can read and update support cases.
  • Authenticated users (including superusers) can create comments

About that last bullet point: what that means is that any authenticated user can create an object in the comments collection. But wait! Doesn't this mean any user can create a comment to any support case? No, and here is why: note that, because of the way AppStax verifies permissions across relations (see above), a particular user can not create a comment related to a support case he or she does not already have permission to read. Because only the superusers and the owner of the support case can read the case, only they can create comments related to the case as well. AppStax' built-in relationship security features automatically enforce this.

TimeKeeper app

A TimeKeeper app lets workers register how much time they have spent on which projects/activities on a weekly basis. Assume the basic model is that each user can register a timesheet for a certain week, and that each timesheetbelongs to a certain project. In other words, every timesheethas a relation to the corresponding week and another relation to the corresponding projectthat this timesheet is for. Each project has a project manager who can see all registered timesheets for her project, and each project has a number of team members. The project manager and the team members are all registered users.

Let's start with the basic collection level permissions:

  • Admin users can create, update or delete weeks (assume this is done once during the development of the app)
  • Authenticated users can create projects and timesheets
  • Authenticated users can read weeks

Note again that, because of the way permissions are enforced across relations, the second bullet point above allows any user to create any timesheet, but a user can only create a timesheet for a project he already has read permission to.

Now let us consider the following questions:

Question Answer
How do we grant a user read access to a given project, and who does it? The project manager can grant read access to the specific object representing the project. For example, there may be a place in the app where a project manager creates a project and then adds team members. As each team member is added, the project manager also grants read access to the project.
How do we make sure a timesheet is readable by both the worker who created it, and the project manager? Every time a worker creates a timesheet, execute code that also grants read permission to the project manager. This way, each project manager has read access to every timesheet belonging to the project she is manager for.

This leads us to the following two strategies for object level permissions:

  • When a project manager adds a team member to the project, grant read access on the project to the team member
  • When a worker creates a timesheet, also grant read permission to the project manager

Explore further

Check out these guides and tutorials to learn more about how to use object level permissions in your favourite SDK: