Complex Front-End View Permissions

Question

This is as much a philosophical as a technical question. We are using EE 2.11.1 for this project.

We have relatively complex front-end permission requirements. They are all need-to-know permissions, i.e. views not edits. I have researched the topic and found the hooblong and hookan add-ons. However, based on my dev experience, I believe I can create a custom system for our permissions requirements. But as I am new to EE, I am not sure if I should. So this is mostly a question of 'best practice' and if you can see issues down the road.

Permission Requirements

Member Groups:

• Super Admins
• Editor Type A
• Editor Type B, etc.
• B2B User
• B2C User

The difference between B2B and B2C user can be nicley solved through EE's internal template permissions. However, the B2B Users will have a very granular and mix-and-match permissions requirement:

• View Country 1
• View country 2, etc.
• Application View 1
• Application View 2, etc.

There are nine countries and the applications list will be extended post-publication. A B2B User can have a very individual combination of these permissions, i.e. it's not feasible to solve this through member groups. (Additionally there will be permissions synchronization from our CRM system.)

User Setup

Using Solspace's User Add-On, we are implementing a system where a user is always associated (as Associated Author) with a company channel entry. The permissions illustrated above will always be company-wide, i.e. all users associated with a company will have the same permissions.

Considered Approach

The solution that I am currently considering is:

• Store permissions as fields in company channel entry
• On member login use member_member_login_single hook to load the user's asociated company profile including permissions (will have to do this anyway, as the company profile holds information which will be needed to connect to 3rd party tools)
• In the template, check permissions in the company profile and display content accordingly. (Often it will be a show / don't show case.)

So, is this a terrible approach? Are there any issues experienced EE devs see on the horizon? Are there preformance issues to be considered? Any other input I need to consider?

Answer 1

Yes, your plan is a reasonable one. The only change I'd make is to use sessions_end rather than member_member_login_single. The latter only fires upon login, but presumably you'll need to know the member's permissions throughout their session. The former fires on every page load.

Inside of that hook you could simply set some global variables based on the permissions data you fetched for the logged-in member.

ee()->config->_global_vars['can_access_usa'] = true;
ee()->config->_global_vars['can_access_canada'] = false;

(As a very simple example.)

Alternately, skip the extension altogether and write a module with a tag pair which uses conditionals to process your permissions.

$vars = array(
    'can_access_canada' => false,
    'can_access_usa' => true
);
return ee()->TMPL->parse_variables_row(ee()->TMPL->tagdata, $vars);

Then in your template you can use:

{exp:my_addon:permissions}
    {if can_access_canada}
        // Do stuff
    {/if}
{/exp:my_addon:permissions}

Answer 2

Ultimately, "best practice" will come down to balancing the following factors: - Your channel structure, the containers for all data. - Your group structure which controls access - Your template structure which gives, as you have stated, a certain amount of intersection between groups and data - Finding some way to limit the number of different access/data combinations - A way to overcome the limitation of One Member, One Group

Mixing and matching access using pure native EE is, as you have realised, not feasible, and Derek has given excellent advice on how to get around that limitation within the boundaries of the information you have provided.

However, you are no longer in "Native EE" territory whatever you do.

What is not entirely clear to me, is how dynamic are your access-control needs? Assuming that each user belongs to only one company at a time, your access control combinations come down to Company/Country/Application. I can't tell how many combinations you have to consider without knowing how many companies and applications as well as countries, but it really does not matter unless access will be static once set up, which seems unlikely.

Once you get over a few (ten to twenty) combinations, the job of visualising the security consequences of making any change becomes an impossible challenge, so you need a way to lock in how your access control works so that it cannot be bypassed by combinations that may not have been anticipated during the design phase.

I have wrestled with this extensively for a number of clients with similarly dynamic "need-to-know" content access needs, which is why I developed HooKan and HooBlong. While they in no way make your data and access-control design job any easier, they do simplify the post-deployment admin job.

View HooBlong Features