Virtual Happy Hour canceled for Friday May 31st.

Try our conversational search powered by Generative AI!

Erik Norberg
May 30, 2018
  5414
(4 votes)

How to use visitor groups to control access to non-content

This post is intended for developers and is mostly code examples.

How to use visitor groups to control access to content is well documented here at episerver world: https://world.episerver.com/documentation/developer-guides/CMS/personalization/

It also goes in depth on how easy you can create your own custom visitor groups, but I found it lacking when it came to describe a way to use visitor groups for non-content.

Background

A customer with a commerce site came to me and requested a way to limit access to certain shipping methods so that only companies could use them, he also wanted a way to define who should be counted as a company himself. Had shipping methods been content we could have used visitor groups just out of the box but as it is not, but rather a very old part of commerce that doesn't even know visitor groups exist, it proved to be a challenge to figure out how to get it to work.

Solution

To begin with we need a way to define which visitor groups define companies, this was added to a settings page in the cms as a custom property:

[Display(Name = "Visitor groups for companies")]
[UIHint("visitorgroupselector")]
public virtual IList<Guid> CompanyVisitorGroups { get; set; }

Turns out visitor groups are stored with their Guid:s in an IList and the magic is added with a UIHint attribute as so often is the case. Unfortunately it is not present among the EPiServer.Web.UIHint constants, you must know that the selector is named "visitorgroupselector" and enter it as a string manually.

That took care of the problem with letting the customer configure who is a company now we just need a way to check if the current visitor is a member in any of those groups, for that i wrote a little service:

public class VisitorGroupService
{
	private readonly IVisitorGroupRepository _visitorGroupRepository;
	private readonly IVisitorGroupRoleRepository _visitorGroupRoleRepository;

	public VisitorGroupService(IVisitorGroupRepository visitorGroupRepository, IVisitorGroupRoleRepository visitorGroupRoleRepository)
	{
		_visitorGroupRepository = visitorGroupRepository;
		_visitorGroupRoleRepository = visitorGroupRoleRepository;
	}

	public bool IsCurrentUserInAnyVisitorGroup(IList<Guid> visitorGroupIds)
	{
		if (HttpContext.Current == null)
		{
			return false;
		}
		var context = new HttpContextWrapper(HttpContext.Current);
		return IsPrincipalInAnyVistorGroup(context.User, visitorGroupIds, context);
	}

	public bool IsPrincipalInAnyVistorGroup(IPrincipal principal, IList<Guid> visitorGroupIds, HttpContextBase context)
	{
		if (context == null || visitorGroupIds == null)
		{
			return false;
		}

		foreach (var groupId in visitorGroupIds)
		{
			var group = _visitorGroupRepository.Load(groupId);
			if (_visitorGroupRoleRepository.TryGetRole(group.Name, out var groupRole) && groupRole.IsMatch(principal, context))
			{
				return true;
			}
		}

		return false;
	}
}

Fairly easy to follow the code but not much is documented around these classes. Some points of interest here is that we must load the VisitorGroup just because the IVisitorGroupRoleRepository only takes the Name and not the Id, the TryGetRole is also the single function defined on this interface.

All that is left for us is to call the service and pass in the page property:

var isCompany = _visitorGroupService.IsCurrentUserInAnyVisitorGroup(page.CompanyVisitorGroups);

Now we are free to filter whatever we want based on visitor groups. I hope this can provide you with a clear guide to improve personalization on all your sites. :)

Footnote

There is a EPiServer.Personalization.VisitorGroups.VisitorGroupHelper you can use to simplify the code a little bit, it wraps the IVisitorGroupRoleRepository and does the call to VisitorGroupRole.IsMatch, I used the repository directly more for transparency than anything else.

May 30, 2018

Comments

May 31, 2018 04:08 PM

Nice article.

I just want to add that the UI hint constant can be found at EPiServer.Commerce.Catalog.DataAnnotations.SystemUiHint.VisitorGroupSelector. The actual editor for this is in Commerce (it was made for the marketing UI, to select a visitor group for a campaign), hence the placement of the constant.

Patrik
Patrik Jun 7, 2018 09:29 AM

Great advice!

I am not sure, but maybe this problem also could be solved by using Episerver Permissions to functions (https://world.episerver.com/documentation/developer-guides/CMS/security/permissions-to-functions/).

// Patrik Pochill

Erik Norberg
Erik Norberg Jun 7, 2018 04:15 PM

Permissions to functions could indeed be used to solve the same problem provided the administrators would be willing to maintain the permissions.

Visitor groups are far more versatile as they can define more than just group and role membership as well as be used for anonymous users.

In this specific case the customer is already using visitor groups to control other content and the cost of administrators having to learn and maintain a second interface should never be ignored.

Please login to comment.
Latest blogs
Blazor in Optimizely CMS 12 with .NET 8

How to enable support for Blazor components in Optimizely CMS 12 after upgrading to .NET 8.

Ted | May 30, 2024 | Syndicated blog

Build a headless blog with Astro and Optimizely SaaS CMS

I’m a big fan of using the right tool for the right job. I’m also a big fan of Astro , for the right use case. Let's explore Astro to see what it's...

Jacob Pretorius | May 28, 2024

Microsoft announces Natural language to SQL

Finally, Microsoft launches "Natural language to SQL," after it has been available for several months in Optimizely CMS!

Tomas Hensrud Gulla | May 23, 2024 | Syndicated blog

Five easy ways to start personalizing your content right now

If you clicked on this article, you already know that getting the right message to the right person at the right time helps drive conversions and...

Kara Andersen | May 23, 2024