Paywall, or protected pages with Sitecore

Photo by Max Titov on Unsplash

In a previous blog post, I described how I have managed to implement Okta as Federated Authentication for public web site visitors. One popular use case, is to create paywalled pages, where only web site users who have authenticated with a certain role can read the page. Some great examples are news publication web sites where articles are only accessible by paid subscribers.

Wall Street Journal articles can only be read by subscribers

Short Comings using Security Editor in Sitecore

A lot of seasoned Sitecore developers may gravitate towards the Security Editor immediately.

Security field in Sitecore Raw values

Whilst this will work, and will immediately redirect the user to login via configured Federated Authentication Provider, there are many disadvantages, to a point where the Security Editor is no longer a viable implementation.

1. Any Navigation components in the traditional MVC, or Headless Layout Service without Experience Edge may immediately hide the paywalled page, as the user does not have the correct permission to “READ” the Sitecore item
2. Paywalled pages may need to be indexed in normal site wide search, or Search Engines crawlers. Security field prevents this, and also complicates Sitemap XML generation
3. Less opportunities to target specific people to upgrade their memberships. A person may be interested in a particular paid article, but the Security field complicates implementation to lead the user to the article.
4. Just take a look at the raw values of the Security field. This is way too complicated to translate. Chances are inheritance is not even required when just dealing with a simple Paywalled scenario (Is the current user supposed to have access reading the article ? Yes / No)

In short, the Security field is best left to be used for Content Authoring Workflow arrangements, and preventing content authors to edit various sections of the Content Tree.

Alternative Implementation without using Security Editor

Just use a simple Multilist, Droplist, or whatever list type is desired to control which user roles will have full read access to the content page. Following is an example using Multilist.

Using Multilist to control which user roles can read the page

In the HEAD of the web application implementation, it can be decided on what to do with such information.

I have added something to bypass check on authentication if a request has specific Request Header(s) in place. This is required when implementing Federated Search (e.g. Coveo, Sitecore Search, both using web crawler functions). Furthermore, a CDN like Akamai or CloudFlare can be configured to pass add the headers if the bots are Verified, or known bots / processes for automated testing.

For the good old traditional MVC implementation (or Serverless Integrated Mode), the pipeline to use is httpRequestProcessed.