Controlling AdminCentral access

AdminCentral is a Magnolia CMS user interface where administrators and editors work. In this post I show how to configure menu permissions for a custom user role.

AdminCentral provides menus for common tasks. When you click a menu, workable items are displayed on the right.


You can hide menus and move them around to promote often-used items or deny permission to items that users should not be able to access. Magnolia CMS ships with typical roles such as superuser, editor and publisher. While a superuser can see everything, editors only see items that are relevant to their job.

Permissions for custom roles

Suppose your organization has a very specialized editor role, Category Editor, who is responsible for maintaining a taxonomy of categories. Categories are tags that help site visitors find related, interesting content.

Categories are managed in a custom data type under the Data menu. The demo-project website has an example taxonomy consisting of categories such as Culture, Family and Finance. The Category Editor needs access to the Data > Category menu only.


You can approach setting permissions for this role in two ways:
  • Top down: Start with a more powerful editor role and remove permissions until only the ability to edit categories is left.
  • Bottom up: Start with zero permissions and keep adding until the Category Editor can do their job. 

Magnolia CMS ships with a demo-project-base role that provides many basic permissions common to all users. It's a good starting point so let's choose the first option: top down.

Create category-editor role

Create new role category-editor and new user jsmith. Assign roles demo-project-base and category-editor to user jsmith.

Now open another browser instance and sign in as jsmith. You should see three menus: Website, Documents and Data.


The Category Editor doesn't need the first two menus or the Contact submenu so let's remove them.

Hide menus

Edit the access control lists (ACL) attached to the category-editor role. Deny access to the following nodes in the config workspace:
  • /modules/adminInterface/config/menu/website$
  • /modules/adminInterface/config/menu/dms$
  • /modules/adminInterface/config/menu/data/Contact$
The demo-project-base role already grants access to the same nodes so you need to make the deny rules "win". If a user has multiple ACLs through role and group assignment that specifically list the requested resource, the ACL with the longest pattern determines the permission. The order of the rules is not considered. This is a critical point. Use the dollar sign ($) to mark the end of the path, which makes the deny rule longer.

Here's what the Category Editor sees after the ACLs have been applied. Menus are now perfect but the editor cannot edit the data items. Categories have a crossed-out pen icon to indicate this.


Grant access to data

Add an ACL in the data workspace that grants Read/Write permission to /categorization node. Now the items are editable.


Lock the backdoor!

Menus are not the only way to access content in AdminCentral. They just provide convenient access to often-used items. If you are restricting access per security, not just for convenience, make sure you lock down the content too:
  • Workspaces store the actual content. Make sure that any role you choose as a basis does not grant access to a workspace that users should not be able to access. In our example the demo-project-base role does not grant any unnecessary workspace permissions. You can control workspace access with an ACL. Select the workspace from the controlled space dropdown.
  • Trees are customized views into specific data. Users can view trees with a direct URL if they know the name of the tree, for example http://[host]/[instance]/.magnolia/trees/website. Each module can register its own trees. Look in /modules/adminInterface/trees to get an idea. As long as you restrict permissions to workspaces correctly, trees will honor the permissions.  
  • Pages provide specialized tools such as exporting, importing and querying. Users can access pages with a direct URL too: http://[host]/[instance]/.magnolia/pages/jcrUtils. Like in trees, content cannot be accessed through pages as long as the workspace is locked down.

Popular posts from this blog

Vanity URLs with Magnolia CMS

Image
Vanity URLs are short, easy to remember Web addresses used for campaigns, microsites and landing pages. They are a key Internet marketing tool. In this post I whip out my vanity cane, clip on my grill and show you how to get vain with Magnolia CMS. A vanity URL typically contains a word or phrase that describes a specific target such as a campaign slogan. When a user visits the vanity URL they are redirected to the actual target site. The URL can be constructed using a: trailing path: www.shell.com/ eco-marathon domain prefix: experience .virgin-atlantic.com domain suffix: www.amazon. de entirely unique domain name: mynavyfuture.com The URL is often reproduced in print ads, hoping that the short and snappy look makes it easier to remember. Magnolia CMS provides two approaches to creating vanity URLs: 1) Virtual URI mapping is used to create path-based vanity URLs. In this mechanism a trailing path is mapped to an actual page. In the configuration example below, www.example.com/winter
Read more

Keyboard shortcuts that look like keys

Image
I spotted this CSS class being used in Chrome keyboard shortcut help. I applied the style to our  keyboard shortcut documentation  at Magnolia. Now the shortcuts look like actual keys. That was a quick way to add a bit of polish. .kbd { background-color: #f7f7f7; border: 1px solid #ccc; color: #333; font-size: 13px; line-height: 1.4; text-shadow: 0 1px 0 #fff; font-family: Arial,Helvetica,sans-serif; display: inline-block; padding: 0.1em 0.6em; margin: 0 0.1em; white-space: nowrap; -webkit-box-shadow: 0 1px 0px rgba(0, 0, 0, 0.2), 0 0 0 2px #ffffff inset; -moz-box-shadow: 0 1px 0px rgba(0, 0, 0, 0.2), 0 0 0 2px #ffffff inset; box-shadow: 0 1px 0px rgba(0, 0, 0, 0.2), 0 0 0 2px #ffffff inset; -webkit-border-radius: 3px; -moz-border-radius: 3px; border-radius: 3px; } Here's the result:
Read more

Keywords in page titles and meta elements

Image
This post belongs to a series about  search engine optimization  (SEO) with Magnolia CMS. Today we look at inserting keywords in page titles and meta elements. Page titles are an extremely important SEO factor. Search engines give titles considerable algorithmic weight and use them as headings on search results. Titles should include keywords and, where appropriate, your company name for branding purposes: <title>Magnolia - Finance, Insurance & Banking</title> Description meta elements on the other hand do not add much to page relevance, but should not be neglected: <meta name="description" content="Magnolia's largest group of Enterprise Edition customers is from the..."> Their content often appears below the title in search results: The relevance of keywords stipulated in the keyword tag once had great impact, but this is no longer true. Actual page content is now far more relevant. Still, a keyword tag should be included:
Read more