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 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:
|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.
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.
|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.
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
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
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
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:
|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|
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.
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.
Relations are a feature of AppStax that lets you define a relation between two objects. When you create a relation from object
O2, AppStax verifies that you have
update permission on
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).
create permission on
messages collection to
authenticated users. Set
read permission to
all users. Set
update permission to
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
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.
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:
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:
|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:
Check out these guides and tutorials to learn more about how to use object level permissions in your favourite SDK: