Bypass Power Apps Consent Prompts Using PowerShell

Bypass Power Apps Consent Prompts Using PowerShell

When a user opens a Power App for the first time, they are often presented with a consent form asking for permission to access data sources or APIs used by the app. This Canvas API consent form can be disruptive, especially in scenarios where the app is intended for a broad user base or part of an automated deployment. The consent form can create unnecessary friction, requiring every user to individually approve permissions. Fortunately, there’s a way to bypass this pop-up consent form using PowerShell.

In this blog post, I will guide you through automating the process of bypassing the Power Apps consent form using PowerShell. The goal is to either allow users to select an app from a specific environment or use a configuration file to perform actions on multiple environments.

This automation can be particularly useful for initial deployments of a new app or to ensure all apps currently have this applied.

image

Background: Bypassing Power Apps Consent

Before diving into the PowerShell script, it’s important to understand what the Canvas API consent form is and why it might need to be bypassed. The consent form prompts users to confirm that they are comfortable with the application accessing various data sources. While this is an important security measure, it can be a hindrance in some situations. For example, when you have a small embedded app in a Power BI application, it may not be large enough for a user to see the consent form. Similarly, for apps that have been integrated into model-driven apps, users may not even realize that a Canvas App is present.

Matthew Devaney’s article on how to Disable the Power Apps Permissions Pop-Up and Wouter detailed guide on Bypassing Consent When Opening a Power App are excellent resources to get started. They demonstrate how to use PowerShell commands to bypass the consent screen for individual apps. I wanted to take this a step further by making the process more configurable and applicable to multiple environments.

Script Overview

The PowerShell script makes use of the Microsoft.PowerApps.Administration.PowerShell module to interact with Power Apps environments and apps. With the ability to import a configuration file, you can easily define environments and apps that need to have their consent requirements bypassed. Alternatively, the script allows you to select a specific app interactively.

Here’s a high-level overview of how the script works:

  1. Import Required Modules: The script begins by checking if the necessary PowerShell module (Microsoft.PowerApps.Administration.PowerShell) is installed. If not, it installs the module automatically.
  2. Disable Consent for Selected Apps: Depending on how the script is run, it can either take an environment ID and app ID directly or load a configuration file to process multiple apps.
  3. Configuration File Option: The configuration file allows you to define multiple environments and their corresponding apps. This option is useful for automating environments like dev, QA, and production.

The script is documented using PowerShell’s self-documenting features, making it easier to understand and extend. The self-documentation provides details on parameters, descriptions, and usage examples. For more information on how to use these self-documenting features, see Microsoft’s documentation.

PowerShell Script

Below is the complete PowerShell script for automating the process of bypassing the Canvas API consent form. Before diving into the code, here’s a brief explanation: This script can be used to disable the consent prompts for specific Power Apps either interactively or through a predefined configuration. It is useful for simplifying user experience, particularly in deployments where manual consent approvals would be cumbersome.

Getting the Environment ID

To use this script, you will need the environment ID of your Power Platform environment. The easiest way to get this ID is by navigating to the Power Platform Admin Center, selecting the ‘Environments’ area, and viewing the details for your specific environment. Below is a picture that shows where you can find the details for an environment:

image

How to Use the Script Based on Different Examples

  1. Using a Configuration File:

    • Example: ./DisableAppConsent.ps1 -configFilePath "./config.json" -configEnvironmentName "dev"
    • This example uses the configuration file to disable consent for all apps in the “dev” environment. You can define multiple environments and their respective apps within a JSON file. This method is particularly helpful if you want to automate the consent bypass process for multiple environments without any manual intervention.

  2. Direct Environment and App ID:

    • Example: ./DisableAppConsent.ps1 -environmentId "env-id" -appId "app-id"
    • This example disables consent for a specific app using the provided environment ID and app ID. This is ideal when you already know the specific environment and app details you need to process. It allows for a quick and precise update without requiring additional configuration.

  3. Interactive App Selection:

    • Example: ./DisableAppConsent.ps1 -environmentId "env-id"
    • This example allows the user to select an app from the specified environment to disable consent. If you only have an environment ID but do not know the specific app to target, this interactive option is useful. It will present a list of apps within the specified environment, allowing you to choose one interactively.

You can also view the script on GitHub: You can also view the script on GitHub:

<#
.SYNOPSIS
    This script disables the consent prompt for specified Power Apps in an environment.

.DESCRIPTION
    The script provides three ways to disable the consent prompt:
    1. Using a configuration file that contains environment and app details.
    2. Using a provided environment ID and app ID.
    3. Allowing the user to select an app from a given environment.

.AUTHOR
    Rick Wilson

.PARAMETER configFilePath
    The path to the configuration JSON file containing environment and app details.

.PARAMETER configEnvironmentName
    The name of the environment (e.g., dev, prod, qa) as specified in the configuration file.

.PARAMETER environmentId
    The ID of the environment to be used for disabling consent if a configuration file is not provided.

.PARAMETER appId
    The ID of the app to be used for disabling consent if a configuration file is not provided.

.EXAMPLE
    ./DisableAppConsent.ps1 -configFilePath "./config.json" -configEnvironmentName "dev"
    This example uses the configuration file to disable consent for all apps in the "dev" environment.

.EXAMPLE
    ./DisableAppConsent.ps1 -environmentId "env-id" -appId "app-id"
    This example disables consent for a specific app using the provided environment ID and app ID.

.EXAMPLE
    ./DisableAppConsent.ps1 -environmentId "env-id"
    This example allows the user to select an app from the specified environment to disable consent.

#>

# Parameter definitions
param (
    [Parameter(Mandatory=$false, HelpMessage="The path to the configuration JSON file containing environment and app details.")]
    [string]$configFilePath = "",

    [Parameter(Mandatory=$false, HelpMessage="The name of the environment (e.g., dev, prod, qa) as specified in the configuration file.")]
    [string]$configEnvironmentName = "",

    [Parameter(Mandatory=$false, HelpMessage="The ID of the environment to be used for disabling consent if a configuration file is not provided.")]
    [string]$environmentId = "",

    [Parameter(Mandatory=$false, HelpMessage="The ID of the app to be used for disabling consent if a configuration file is not provided.")]
    [string]$appId = ""
)

# Function to check if a module is installed and import it if necessary
function Import-ModuleIfNeeded {
    param (
        [Parameter(Mandatory=$true)] [string]$ModuleName
    )
    if (-not (Get-Module -ListAvailable -Name $ModuleName)) {
        Write-Output "Module $ModuleName not found. Installing..."
        Install-Module -Name $ModuleName -Force -AllowClobber
    }
    Import-Module -Name $ModuleName
}

# Import required module if it is not already installed
Import-ModuleIfNeeded -ModuleName "Microsoft.PowerApps.Administration.PowerShell"

# Function to Disable Consent on a given App
function Disable-ConsentForApp {
    param (
        [Parameter(Mandatory=$true)] [string]$EnvironmentId,
        [Parameter(Mandatory=$true)] [string]$AppId
    )
    
    # Disable consent
    Set-AdminPowerAppApisToBypassConsent -EnvironmentName $EnvironmentId -AppName $AppId
}

# Main logic to determine which flow to execute
if ($configFilePath -ne "" -and $configEnvironmentName -ne "") {
    # Load configuration file
    if (Test-Path $configFilePath) {
        $config = Get-Content -Raw -Path $configFilePath | ConvertFrom-Json
        
        $environment = $config.environments | Where-Object { $_.name -eq $configEnvironmentName }
        if ($null -ne $environment) {
            foreach ($appName in $environment.appNames) {
                Write-Output "Retrieving App ID for app: $appName in environment: $environment.name"
                $app = Get-AdminPowerApp $appName -EnvironmentName $environment.environmentId
                if ($null -ne $app) {
                    Write-Output "Processing app: $appName with App ID: $($app.AppName) in environment: $environment.name"
                    Disable-ConsentForApp -EnvironmentId $environment.environmentId -AppId $app.AppName
                } else {
                    Write-Output "App: $appName not found in environment: $environment.name"
                }
            }
        } else {
            Write-Output "Environment: $configEnvironmentName not found in configuration file."
            exit
        }
    } else {
        Write-Output "Configuration file not found at path: $configFilePath"
        exit
    }
} elseif ($environmentId -ne "" -and $appId -ne "") {
    # Use provided environment and app ID
    Write-Output "Processing app: $appId in environment: $environmentId"
    Disable-ConsentForApp -EnvironmentId $environmentId -AppId $appId
} elseif ($environmentId -ne "") {
    # Prompt user to select an app from the provided environment
    Write-Output "Loading Power Apps from environment: $environmentId..."
    $apps = Get-AdminPowerApp -EnvironmentName $environmentId
    $appChoices = $apps | ForEach-Object { "$_.DisplayName ($_.AppName)" }

    $selectedAppIndex = $appChoices | Out-GridView -Title "Select a Power App to disable consent" -OutputMode Single
    $selectedApp = $apps[$selectedAppIndex]

    if ($null -ne $selectedApp) {
        Disable-ConsentForApp -EnvironmentId $environmentId -AppId $selectedApp.AppId
    } else {
        Write-Output "No app selected. Exiting."
    }
} else {
    Write-Output "Please provide either a configuration file path and config file environment name, or an environment ID."
    exit
}

Write-Output "Operation completed."

Sample Configuration File

Below is a sample configuration file (config.json) that you can use with the script. This file defines multiple environments and the corresponding apps that need to have their consent bypassed. You can also view this sample configuration file on GitHub.

{
    "environments": [
        {
            "name": "dev",
            "environmentId": "00000000-0000-0000-0000-000000000000",
            "appNames": [
                "App Display Name"
            ]
        },
        {
            "name": "prod",
            "environmentId": "00000000-0000-0000-0000-000000000000",
            "appNames": [
                "App Display Name"
            ]
        }
    ]
}

Use Cases

  • Interactive Deployment: If you’re managing a single environment and need to disable consent for just one app, the script allows you to manually select the environment and app, making the process straightforward.

Conclusion

Using PowerShell to automate the bypassing of Power Apps consent forms can greatly simplify the user experience, particularly in large deployments. By incorporating flexibility to either select an app interactively or use a configuration file, you can customize the process to suit your needs—whether it’s a quick update or a flexible deployment process.

The articles by Matthew Devaney and Wouter provide an excellent foundation, and this script builds upon those concepts to offer more advanced, flexible automation. I hope this guide and the PowerShell script help you streamline your Power Apps deployments and reduce friction for your users.

Comments

Post a Comment

Popular posts from this blog

Add User As Local Administrator On Domain Controller

I recently was settting up a new Microsoft SharePoint 2010 machine and had promoted the machine to a domain controller before creating my SharePoint admin accounts.  I needed to add several of my accounts to the local Administrators group.  Unfortunately after you promote a server to a domain controller you can no longer access the GUI for Local Users and Groups.  Instead I had to use the command line to add the users. Open a command promt using the "Run as administrator" function and then run the following command. net localgroup Administrators /add {domain}\{user} Note: do not include the {} brackets.
Read more

Calling Dataverse Web API in PowerShell using Client Credentials

Image
Connecting to Dataverse using PowerShell can be very helpful for data migrations and use within Azure DevOps. Connecting to an instance in a non-interactive way can be tricky though. This article will provide you the links you need for creation and App registration and adding the app user to your environment. You can then utilize the script provided to call Web API requests including ones you define using the new Custom API functionality now available. The script was written so that it is not dependent on any outside libraries such as the Microsoft.Xrm.Tooling connector. This is helpful in situation where involving an outside library will slow down your deployment time by having to be approved in a change control board. If utilizing an outside code library is not a concern you can create a connection to Dataverse utilizing the Microsoft.Xrm.Tooling connector Get-CrmConnection cmdlet. Create App Registration The first thing to do is create an App Registration within Azure AD for
Read more

Windows Server 2008R2 VMs Shut Down After 1 to 2 Hours

Image
When created a lab environment to test ADFS 2.0 I utilized the Windows 2008R2 VM baselines distributed by Microsoft.  After a few days I was told that I had to activate.  The VMs included a 180 day license for use but I didn't feel like adding another network adapter into Hyper-V to connect them to the internet.  I started having issues though where the servers would shut down every hour or so.  I though that maybe there was a memory issue and Hyper-V was shutting them down in order to free up RAM.  Turns out that if Server 2008R2 is not activated it automatically shuts down after a period of time.  After connecting the server to the internet and activating them the problem went away. Finally the madness of the unknown shut downs has ended :)
Read more