Onlinebase

Mura CMS - Member groups and content restriction

For a while now we've been making use of Mura CMS for larger customers with extensive functionality needs. But as the documentation for Mura at times is quite spotty or non-existant on several subjects I have been wrestling with, and having taken part in some discussions on the Mura Google Groups (https://groups.google.com/forum/#!topic/mura-cms-developers/j1VPAt3xTE8) I have decided to share some of my insights here. To start off I have chosen the subject I spent most time getting to grips with, content for member groups. That is content that is only visible to certain visitors of your website after they have logged into the website and are member of specific content groups. Below is how I have set up a website recently to accomodate just this scenario.

Here's my setup:

  • The entire site is behind a login, so I created a number of member groups first.
  • Then I setup the document root of the sitemanager as follows:
    • under Publish tab I checked the "Restrict access to specific groups" checkbox and selected all the member groups
    • that restriction is then inherited down thru the document tree to all pages, folders, content
  • For all the global pages in the website that were available for all groups, I selected each separate page and under Publish tab I checked the "Restrict access to specific groups" checkbox and selected "Global settings > Allow all groups".
    • Hence all pages directly under the document root that are globally available have this setting and are visible to all logged-in users.
    • This setting overrides the document root restriction.
    • Furthermore under "Layouts and objects" I started a new cascade because I wanted to show more/less objects than in the document root.
  • Then came the member group specific sections of the website. I had created a couple of member groups, and now I created the corresponding member group sections.
    • I bundled all sections under a common FOLDER, so I could have a splashpage if necessary, and because (I only found out later) this whole setup only works if the root where all section specific documents are to be kept and maintained are under a FOLDER. I started out with a page, but that just went apeshit and didn't work...
    • The FOLDER also has restrictions set to allow only the available member groups. All groups could also have worked here I think, but at this point I was just happy to have it all working at this level.
    • Under the tab "Layouts and objects"I added the following components:
      • Go-To-First-Child (Select Content Object > System)
      • Mutli-Level Navigation (Select Content Object > Navigation)
        I tried many other navigation content objects, but none really worked with multi-level navigation. Even the folder navigation only showed me two levels, but when I got to the third level, the top-most layer of the navigation just disappeared. Not very good - the chosen navigation object just works in this setup.
  • Now comes the real important part. Under the section FOLDER I created PAGES for all sections.
    • Each member group got it's own page, with restrictions set to that specific member group. Section 1 page was restricted to only member group 1, and so forth. This restriction is supposed to flow down that specific document tree as well, but still I confirmed that restriction to FOLDERS underneath that specific section page as well.
    • This section page I could now also use as a splashpage for the member group with it's own look-and-feel and content placement via a separate template.
    • Also I started a new cascade, again not really necessary I think, but it worked this way, with the same content objects as mentioned above.
  • Under each of these PAGES I created FOLDERS for the content to be put in. Each member group had a set number of the same folders, but for any other setup this may vary.
    • Each FOLDER inherited the content objects cascade from the PAGE above, but again I set specifically set restrictions to only the member group in question.
    • CONTENT underneath each of these FOLDERS does NOT have the restrictions specifically set. I've tested this thoroughly and this also just works. It inherits its restrictions fromt he FOLDER above. I may try and see how far the restriction inheritance actually goes in this setup, but for now I leave it as it is - namely working as intended ;-)

The above setup accomplishes my wish to force login of all website users. Furthermore it solves the wish to restrict access to all content the logged-in user is not supposed to see - he/she sees only the content that is intended for that particular member group he/she is a member of. The PRIMARY navigation and the MULTI-LEVEL navigation completely adher to these authorization rules and only display those sector PAGES and member group FOLDER that are intended for the user. If a user tries to go to content that does not exist a 404 is shown - if he/she guesses the correct URL to other content of a group he/she is not a member of (or gets the URL from someone else), the user gets a RESTRICTED page with a login. Now I still need to figure out if that is bad and redirect to a common 404-ish "Big No-No" page, but for now I leave it as it is.

If you have any questions please let me know. I'll create follow-up posts of this blog post to share my experiences and challenges with Mura.

Geplaatst op 25 juli 2014 om 20:03 u.

Alles in 'Ontwikkeling'

10 bericht(en)