A question popped up a couple weeks ago about the best way to force everyone to have to login to your Power Apps Portals before getting access to anything. At first, I gave a very wrong answer – thankfully MVP Nick Doelman corrected me and, in the process, we all learned another thing about licensing.

The Question, My Wrong Answer, and the Correct Answer

The question has come up a few times over the years – how can you make it so when a person visits a Portal, the first page they see is the Sign In page?

In this specific instance, they were already aware of this proposed solution, which involves using a combination of Liquid (to determine if the user is logged in), and JavaScript (to redirect them to the Sign In page if they are not), but they were wondering if that solution was supported, or if there was a better way.

My response was to say that while using that combination of Liquid and JavaScript is a bit ugly (mostly because having JavaScript that immediately forces a redirection isn’t ideal), I didn’t know of a better way to do it.

Thankfully MVP Nick Doelman (@readyxrm) was quick to respond saying that you can use Web Page Access Control Rules to restrict access to the home page, forcing all initial requests to go over to the Sign In page. This was followed up by a note from MVP Andre Margono (https://andz88.wordpress.com/) where he mentioned that he had a blog post on that specific topic.

So, long story short, if you want to force everyone to log into your Portal, simply create a Web Page Access Control Rule of type Restrict Read on the Home page of your Portal – and be sure to set the scope to “Exclude direct child web files” (more on that in the next section).

In My Defense

So why had I overlooked this seemingly straight-forward solution? Because it used to be explicitly not allowed to add Web Page Access Control Rules to the Home page of your Portal.

See this screenshot, which is still live on the legacy Adxstudio Community Site:

However, now it is supported. Why? My guess is in part because of that Scope

The Scope setting did not exist in Adxstudio Portals version 7 – it was introduced after the Microsoft acquisition in version 8. And I suspect it was introduced to make this exact setup possible.

There are child files of the Home page that are needed to render the site – think of elements like the Bootstrap theme. If those resources were restricted, then your Sign In page wouldn’t look very good.

I think other work was probably also involved to allow for this configuration. For example, even with the Restrict Read applied on the Home page, users can still access the Page Not Found web page, which is technically a child of the Home page. So I’m guessing other exceptions had to be made in the code.

How Does This Tie Into Licensing?

So what does this mean for licensing? If you recall, there are three main categories of users: internal, external authenticated and external anonymous – each with their own licensing requirements. If you have a Portal that is meant only for authentication users, what can you do to ensure that anonymous people aren’t browsing it, and thus incurring licensing costs? You can add a Restrict Read permission to the Home page of your Portal!

Note that there are still a few pages being access by anonymous users, like the Sign In pages, or Registration pages, or the Invitation Code Redemption pages. However Microsoft has indicated that those “special” pages are not counted towards Anonymous Page Views.

So, with a Restrict Read permission on your Home page, you eliminate the need to purchase Anonymous Page Views for that Portal.

Giving Credit Where Credit is Due

Finally, a shout-out to MVP Elaiza Benitez (@benitezhere) – the question was first asked on one of her great videos, and she graciously allowed me to steal the idea for the blog post.