Version 1.5 of the DreamFactory Services Platform (DSP) introduces some incredibly powerful new features for mobile enterprise application development including Lookup Keys, Server-Side Filters, Server-Side Events, and Server-Side Scripting. My previous blog covered Lookup Keys, and this post references that information in a few places. We have implemented Server-Side Filters to control record level access to objects in any legacy SQL or NoSQL database. Server-Side Filters also allow any database to be segmented by application, user, role, or field value. Here is a more detailed discussion of this exciting new capability, below.
A DSP Admin has always been able to define roles that contain access permissions for specific database objects. For example, a role might grant access to a particular MongoDB collection or SQL table. But now Server-Side Filters can be used to implement record-level database access. Any number of filters can be added to a role permission. Each filter takes the form of a "field operator value" equation that must be true to enable access. The field can be any field in the database table. The operator can be equals, not equals, greater than, contains, etc. And the value can be any string, date, boolean, number, or Lookup Key.
Server-Side Filters work great with the internal MySQL database installed on every DSP. Let's say you want to limit users to only work with data that they have created. First, add a user reference field named "OwnerID" to a table. You can use any field name. Next, create a role and grant access to the table, then add a Server-Side Filter that looks like this: "OwnerId = {user.id}". In this filter "OwnerId" is the name of the user reference field, and "{user.id}" is a Lookup Key that represents the ID of the current user. This simple filter limits user access to data that they have created!
In my example above, we need to include an OwnerId field set to the current user ID when new records are created. Trying to create a record without this information will return an error because of the filter constraint. To do this, simply use the Lookup Key name as the field value. So when a record is created the OwnerID field would be set to the string "{user.id}". Of course, this little trick does not work with private Lookup Keys. They can only be used for credentials and passwords.
A filter like this will also work for an external database, although there are a few additional issues to consider. In an external database, the "OwnerID" field would not be an actual SQL reference to the user object. Instead, use a numeric field to store the reference value. As records are created they will be tagged with this number. Everything else will work as before. In a NoSQL database the situation is even simpler, because there aren't data types.
But what about a legacy database that already has users and some kind of existing system for referencing them? In this case, you can add Lookup Keys that match the external reference, and use that key in the filter value. The filter would look something like this: "ExternalReferenceID = {userkey}". The "ExternalReferenceID" would be the user reference field, and "{userkey}" would be a Lookup Key associated with a particular user.
All of my examples so far have shown data being partitioned by user ID. But the DSP also has Lookup Keys for each role. This feature allows a database to be partitioned in many interesting ways. For example, let's say you have a sales team in the North, South, East, and West. You could create four roles with these names and then enable access to a table with this filter: "Region = {role.name}". Now each team has access to the same table but with data only from their region. A manager with a different role could see all the data.
Server-Side Filters can use a variety of data types including strings, dates, booleans and numbers. Multiple filters can be added to any role permission and combined with logic. Here are a few examples of what can be accomplished:
Currency: Only Opportunities less than $1000
Date: Only Leads for the second quarter of 2014
Geography: Only Cases in the state of TN or GA
Email: Only Contacts that contain '@dreamfactory'
Numeric: Only Companies with 500 to 1000 employees
Phone: Only Partners inside area code '615'
Boolean: Only Emails that have checked "Opt In"
Picklist: Only Accounts that are 'Hot' or 'Warm'
Server-Side Filters constrain how data can be created, read, updated, or deleted. The client application needs to be sure that when an object is created or updated that the proper fields are included to match the filter. When an object is read, only records with the correct filter pattern are returned. All of the enforcement is done on the server-side, so there is no way to get data that you do not own, or to create data masquerading as another user. Those operations will be rejected by the server.
So there you have it. Server-Side Filters are an important part of the new DSP feature set. You can control data access in many powerful new ways with just a bit of configuration in the Admin Console. But in some cases, you really need to customize the server-side in unique ways. Up next, we present Server-Side Events and Server-Side Scripting which provide deep server-side customization. All in all, these capabilities represent a huge leap forward in enterprise security and data segmentation for our open source platform.
Learn more at: www.dreamfactory.com
Download now at: bitnami.com/stack/dreamfactory
Read more about DreamFactory 1.5:
https://blog.dreamfactory.com/dreamfactory-introduces-lookup-keys/
https://blog.dreamfactory.com/dreamfactory-introduces-server-side-filters/
https://blog.dreamfactory.com/dreamfactory-introduces-server-side-scripting/