How to Enforce Login on Editing Pages in MS Power Pages – Part 1

Note: This approach works when standard login identity provider is used. Please look at the Part 2 for a custom identity provider approach.

One of the clients I was working with just had a security assessment done by a security specialist. One of the items that was raised was the importance of enforcing re-login on pages which users were required to input their personal details. An example of this would be an Update Profile page, or any other pages which users were required to input details in relation to “privacy” i.e. any information that can identify such person.

As you know, Power Pages was very heavy on client-side interaction and with very little server-side interaction. All server-side interactions had to be done through calling a REST API or some sort. While something like PHP or ASP.NET application would allow you to do code-behind programming to reinforce the login. Updating the “Submit” code behind of a basic or multi-step form would not be possible.

So, the best options I could come up with were as follows:

Option 1. A Dedicated Portal for Profile Editing

We could create a 2nd portal just to do profile editing. What this meant was, you could have https://publicportal.powerappsportals.com as your main portal which general users access, then you would have something like https://editprofile.powerappsportals.com.

Within Public Portal you would hide/remove all pages that were required for login reinforcement. And you would then redirect all the links to the Edit Profile portal. You could use the below URL to redirect user to the Edit Profile portal:

https://editprofile.powerappsportals.com/account/login/logoff?ReturnUrl=%2FEdit-Profile-Page

What it’s going to do was to redirect user to a “logout” page of the Edit Profile portal, thus then redirecting user to the login page on the Edit Profile portal while still logged in to the Public Portal.

On the “Edit Profile” portal page you could also enforce the user to logout after clicking “Submit” or “Update” button after they updated their profile/information. Example is as follows:

$(document).ready(function(){

$('#ContentContainer_MainContent_MainContent_ContentBottom_SubmitButton').click(function(e){

WebForm_DoPostBackWithOptions(new WebForm_PostBackOptions("ctl00$ctl00$ctl00$ContentContainer$MainContent$MainContent$ContentBottom$SubmitButton", "", true, "Profile", "", false, true));

e.preventDefault();
});

var confirmationMessage = $('#ContentContainer_MainContent_MainContent_ContentBottom_ConfirmationMessage');

if(confirmationMessage.length)
{
    var confirmationMessageContent = $('#ContentContainer_MainContent_MainContent_ContentBottom_ConfirmationMessage .xrm-attribute-value');

    if(confirmationMessageContent.text() == "Your profile has been updated successfully.")
    {
        console.log("LOGOUT");
        location.href = '/account/login/logoff';
        //window.close();

    }
}


});

What the code above allowed you to do was to perform the form postback operation, then redirect user to the logout page. In the example above, a message of “Your profile has been updated successfully.” was shown by Power Pages after user clicked on Submit button. The Javascript then recognised this message appeared on the screen and redirect user to the logout page.

Option 2. Enforce Logout on Same Portal

The second option did not require you to create the 2nd portal. Rather, using just the 1st portal, you can use the following Javascript code:

$(document).ready(function(){


var confirmationMessage = $('#ContentContainer_MainContent_MainContent_ContentBottom_ConfirmationMessage');

if(document.referrer.indexOf("ciamlogin.com") == -1 && !confirmationMessage.length)
{
console.log(document.referrer);
location.href = "/account/login/logoff?ReturnUrl=%2FProfile";
}

});

What happened above was, if user was redirected to the Profile editing page without postback AND not coming from “ciamlogin.com” – which was the domain which MS Identity Provider was using – then user would be redirected to the logout page. This was to enforce the user to re-login to the portal every time he/she hit the “important” pages. You would need to use the above code on every “important” page.

Conclusion

Each option had strength and weakness. The 1st option was more complex, more maintenance in the long run bit it offered flexibility. The user did not have to be logged-out of the main public portal.

The second option however was a lot simpler but it meant the user would be logged-out completely every time he/she accessed the “important” pages.

I hope this helps. If you have better ideas or approach please let me know. Thanks heaps for your time.