Login if you already have an account



Create a new account. join us!



Need some help? Check out our forum.

August 5, 2012 vprakash@miegoapps.com


At the API level, NoServer provides the developer with granular control of data security. Every attempt to read or write (i.e. create, update or delete) an object is subject to a permissions check. Every object has an Object Access Policy (OAP) associated with it, effectively determining permissions for each user, on every object in the application.

We use “Object Access Policy (OAP)” rather than “Access Control List (ACL)” because ACLs are traditionally associated with file systems access as opposed to application-level access of collections, objects and members.  OAPs are dynamically determined at runtime based on a hierarchy of rules. For most purposes, you can think of them as equivalent.

The NoServer framework sets OAPs in three ways:
1. By default, the platform sets an OAP for every object.
2. You can write a declarative default OAP on the collection containing the object to change the platform default that will be applied to all new objects in the collection.
3. You can use clientside or serverside code to change an object’s OAP at runtime, effectively overriding the default permissions.

When you create an API, you take care to set up the permissions the way that you want. Most times, Declarative Permissions are sufficient, but in case you need more – you can also change permissions on the fly whenever you need to.

Default Permissions

The NoServer framework sets the default OAP for every object on the system as follows:
1. The creator of an object has read and write permissions for that object.
2. All other users are granted read permission only for that object.

Declarative Permissions

You can define the default read and write permissions for any Collection using Declarative Permissions. These are specified in your application’s configuration file, application.ffdl TODO, using the PERMIT command. See the FFDL Reference PERMIT command. The PERMIT command allows you to specify one or more groups of users (FFUserGroups) to which you grant the read, write and create permissions. The collection must exist and the groups themselves can be identified in a number of powerful, flexible ways. Note that permissions can be set for multiple FFUserGroups by separating multiple groups with commas. As FFUsers are added to and removed from these groups at runtime, their permissions change appropriately.

Global Parameters

There are some global parameters that you can use to control permissions. These can be used to set read and write permission defaults on any Collection:

Specifies that everyone has access, (write operations require a logged-in/active user).
PERMIT read:public write:public ON /Photos

Specifies that only logged-in users (and active for write operations).
PERMIT read:loggedin write:none ON /Photos

Specifies that no users, except the creator of that object has access.
PERMIT read:none write:none ON /Photos

creator.<FFUserGroup name>
An FFUserGroup that is owned by an FFUser be used my name.
PERMIT read:system.administrators write:system.administrators ON /Codes

system.<FFUserGroup name>
An FFUserGroup can be used my name from the system maintained collection.
PERMIT read:system.administrators write:system.administrators ON /Codes

always <FFUserGroup name>
The named FFUserGroup permission will apply even when explicit runtime permission are used.
PERMIT read:always system.administrators write:always system.administrators ON /Codes

Object Level Permissions

In your object definition, you can include groups of users as part of your data model, either by reference or by value and use them to control permissions. Some examples:

Grab Bag of FFUser objects
PERMIT read:object.family write:object.family ON /People

Referenced FFUser object
PERMIT read:object.sentTo write:none ON /PrivateMessage

Referenced FFUserGroup object
PERMIT read:creator.bestFriends write:creator.bestFriends ON /Photos

Permission Inheritance

You can also “inherit” permissions from a referenced object by specifying one or more FFUserGroup groups that it has. For example, you could specify that a “Joke” object that has a reference to a “JokeBook” object will inherit the permissions from the “JokeBook” object instance.
PERMIT read:object.jokeBook.readers write:object.jokeBook.writers ON /Jokes

Dynamically Changing Permission

Users (via client application code) may also explicitly set or change OAPs on objects for which they have modify permissions. OAPs can also be set by extensions and event handlers. Unlike Default OAPs, setting or changing an OAP at runtime may only be done on an object-by-object basis. The FatFractal SDKs allow the developer to programmatically set or change read and write permissions on an object by group, by specific user or by a combination of the two. Methods are also provided to reset the default permission.

For More Information

Working with permissions using the Android SDK

Working with permissions using the iOS SDK

Working with permissions using the Client-Side HTML5/JS SDK TODO

Working with permissions using the Server-Side JS SDK

Working with permissions using the REST API