BlogNifty

Cognifty release 15 brings a new concept of "Sharing Modes" to the table. A sharing mode is a default implementation of row level security.

Traditionally, many PHP applications completely lack any concept of groups or roles. This was one of the major road blocks which kept me from adopting applications like "DotProject". In DotProject, if you wanted a user to be able to view tickets, for example, this user would then be able to view all tickets in the system, regardless of which group a certain user belonged to. If you were to expose parts of DotProject to your external clients, they would be able to see all tickets submitted from all of your clients.

In a system such as this, we can see that there is some level of security, the ability - or ROLE - to view tickets can be restricted to certain users. But each record of data in the domain of tickets were not able to be restricted further, beyond the ability to view them. We call this type of security role based security, or an access control list.

Merely specifying the access to an entire domain of data, as you can see, is not a complete solution to making an application usable by different parties. People who work in one organization should be able to see different information from people in another organization.

To have the most complete security model we need both access control lists and row level security. In Cognifty, the access control lists define global access to services, and the row level security restrict the viewing, editing, and deleting of individual data items down the the user or group level.

I said before that a "Sharing Mode" is an implementation of row level security, but what does that mean? Specifically, a "Sharing Mode" is a label that tells the system which fields in a database table define the specific row-level access. The labels are completely configurable by the developer, but the system comes with some defaults that should satisfy 80% of the use cases out there.

• sharingModeRead: same-owner, same-group, parent-group, parent-owner, registered, none
• sharingModeCreate: same-owner, same-group, parent-group, parent-owner registered, none
• sharingModeUpdate: same-owner, same-group, parent-group, parent-owner registered, none
• sharingModeDelete: same-owner, same-group, parent-group, parent-owner registered, none

With these defaults, any CRUD operation is compared against a configurable field, either owner or group, before the operation is run against the database. Let's take an example of a forum system, where viewing some forums are restricted to certain groups, and only the original poster can edit his or her own posts.

The forum itself would have sharingModeRead = "same-group". In this way, if a group_id was specified for the forums, any read operation would first be checked against a list of group IDs from the current user. If the group_id column was empty, or zero, the read operation would succeed for anybody.

The forum post table would have sharingModeRead = "parent-group". With this sharing mode, the system joins the parent table (configurable in the code) with the form post table and checks the group before allowing any reads. This ensures the same sharing mode as the parent forum. The create mode would also have "registered" flag set, so that any user can post to any forum they have access to. And, for updating, the forum post table would have sharingModeUpdate = "same-owner" so that any update operation is compared against the current user's ID first.

All these values can be modified at run-time for special administrative privileges if the current user is part of any forum administrators group.

The biggest new feature in release 16 is the API agents feature. Any registered user of the system can enable or disable their API agent from the account settings screen. The API agent brings a consistent way of accessing any configured service of a Cognifty installation to 3rd party scripts.

Sometimes remote API access is hacked on to a Web project after the project is completed, or near the end of the development cycle. If you start your Web projects with Cognifty, you don't have to worry about developing API access from scratch any more.

Having an API per user account instantly brings the same level of groups and permissions to any API modules that you develop. I've seen global API keys (that is, one API key per installation) already in the project Piwik. Not being able to control the access of API agents (scripts that use an API key to interact with the system) is very bad. If somehow your *global* API key gets leaked, the thief now has all the access allowed by the project's API. Having per user API keys allows you to create robot specific users, limit their permission in the system, then generate API keys for each robot or task.

Some ideas for per user API keys include:

• Quickly create per user, authenticated RSS streams (eg. my tasks)
• Remote content publishing to live servers (wink wink, release 17)
• Pull customizable data feeds into flash charts (http://teethgrinder.co.uk/open-flash-chart/)
• Single sign on service (create a session when pinged with the user's API key)
• Create customizable facebook-style embedded apps.