Speck CMS - A simple content management system for ColdFusion

you are here: home > documentation > users and security > access control

• Getting Started
  • Speck Concepts
  • System Requirements
  • Installing
  • Upgrading
  • Hello Speck!
  • Articles
  • Caching
• Sample Application
  • Installing
  • Displaying Content
  • Managing Content
• Application Configuration
  • Settings
  • Keywords
  • Globalization
  • UI Customisation
• Building Applications
  • Application Initialisation
  • Creating Content Pages
  • Creating Content Types
  • Built-in Content Types
  • Built-in Property Types
  • Event Handlers
  • Context Sensitive Help
• Users and Security
  • Security Files
  • User Sessions
  • Access Control
  • Password Encryption
  • Reserved Roles
• Optimising Performance
  • Output Caching
  • Query Caching
  • Unnecessary Processing
  • Database Performance

Access Control

Access to manage content and do other tasks in Speck is granted using roles. Roles are different to groups in Speck - users with a role are considered to have some role in the management of the system, whereas groups of users are, well, just groups of users. Speck allows both users and groups of users to be granted roles in the management of the system.

Note that once a user has a role in the system, they will be able to see the toolbar when they log in (though they might not be able to see or access any of the management features). Do not grant roles to any users or groups who do not have a role in the management of a site / application!

Super users have the spSuper role and they can do anything. This includes managing content, but also managing application keywords etc.

Non-super users need the spEdit role to edit content and the spLive role to put the content live. On a site with promotion enabled, this allows you to restrict who can approve content to appear on the live site to a superset of those who can edit content. If promotion is disabled, and it is by default, non-super users need both spEdit and spLive to edit and save content because Speck automatically promotes content to the live site whenever it is saved (that's a bit of a silly legacy thing, we'll sort it out sometime).

Granting access to edit content with specific keywords

Speck also allows you to create your own roles and, if you are using the application keywords, to grant permission to edit content saved with certain keywords to users with those roles. Each application keyword can be saved with an associated list of roles that are to be granted access to edit content items with that keyword. The portal framework uses this feature to allow users who don't have general edit access to edit certain sections of a site. What actually happens under the hood is Speck grants spEdit and, if necessary, spLive roles to a user temporarily, just while they are adding, editing or deleting a particular content item.

Restricting access to use application keywords - NO LONGER SUPPORTED

When adding application keywords, you can also restrict access to save content with each keyword based on role membership. One reason for doing this would be to limit users access to manage content items in a certain location on your web site. For example, say you have a news content type, and have two news related application keywords, "news.local" and "news.global". You also have a web page for local news and another for global news, and the correct content for each page is retrieved based on keyword. If you want to allow all users edit the local news, but only allow certain users edit the global news, you could add a list of roles for the "news.global" keyword. If you try this, you'll notice that Speck even hides the admin links from view where content is retrieved based on a keyword and the current user does not have access to save content with that keyword.

Restricting access to edit properties, labels and keywords - SUBJECT TO CHANGE

There are circumstances where it may be useful to restrict access to edit the properties, and/or the label and keywords fields, of a content type to certain users. For example, if you are retrieving content for display on particular pages based on the value of the label field, you may not want users to be allowed to edit this value.

There are two cf_spType attributes, labelRoles and keywordsRoles, and one cf_spProperty attribute, roles, that allow you to specify a list of roles which should have access to edit the label, keywords and properties fields in the edit content form. If these attributes are not used or are empty, all users who have access to edit the content type will have access to edit the fields. Once a role attribute is used, only users with one of the roles specified in the value for the attribute, or any user with spSuper role, can edit the corresponding field in the edit content form. For example, setting the value of the labelRoles attribute of cf_spType to "siteAdmins" will restrict access to edit the label of any content item of that type to users with either the spSuper or siteAdmins role. By default, each listed role is granted both read and write permission to the corresponding field, but you can also specify the exact permissions to be granted. In the example above where content is retrieved based on the value of the label field and you do not want users to be allowed to edit this value, you may still want the users who cannot edit the value to be able to read the value in the edit content form. You can do this by specifying that the role should only be given read permission to the field. This is done using syntax similar to the chmod command on UNIX based systems. For example, setting the labelRoles attribute of cf_spType to "spEdit=r" or "spEdit-w" allow users with the spEdit role read, but not edit, the label value.

Restricting access to edit or put live content of a certain type - NO LONGER SUPPORTED

Speck allows you to refine access to edit or promote to live content of a certain type by creating a new role following a simple naming convention, spEdit_<contentType> and spLive_<contentType>. So, to restrict access to edit a content type "news" to a subset of the accessors with spEdit role, you would create a new role called spEdit_news and add accessors to the role. The accessors must also have the spEdit role, as this is required before you can edit anything.