cancel
Showing results for 
Search instead for 
Did you mean: 

Removing user ability to access data source without using the app

Problem:

One of the biggest issues in PowerApps right now is that we cannot protect our data. If we connect any data source to PowerApps (Excel, SharePoint List, SQL Server Connection) it has to be shared with all users for them to be able to use the app.

This creates a problem where user has access directly to data source and can bypass the app to do direct modifications to the data source as well as see information not meant to be seen by them. If your app was built to limit users access to some data, for example:

  1. Showing users only their vacation requests and hiding other user vacations
  2. Showing user only their travel request and hiding other user travels

That means that all users can see all data as well as they can modify it without any trace.

 

In case of Excel file on OneDrive we need to give users access to this file, that means that user can just go on OneDrive and find the excel file and edit it.

In case of SharePoint List, that means that user needs to have Edit rights to that list and can just find it on the SharePoint Site and go in and edit.

In case of SQL Server Connection, that means that user can open PowerApps, click create new app, open Data Sources and the shared SQL connection will be there and he can connect to it. This will allow the user to see all tables in that SQL connection with edit rights.

 

Idea:

I believe the best way to fix it, and this will allow PowerApps to become truly powerful tool to replace most of organization applications is to give the App itself write rights to the Excel sheets, SharePoint lists or SQL Connection and not the user. This way the user will have no access to the files, SharePoint List or SQL Connection and the only way to interact with data will be through the App.

Status: Under Review
Comments
AIUYM19
Helper V

@TedBabcock 

Yes, you could hard code a passcode into both your Power App and into the second flow for a bit more security. However, this is easily circumvented by the resourceful user, because they'll be able to isolate the passcode from the data stream, if it's sent in plaintext. That's precisely why I hashed the passcode and made the passcode itself time-sensitive. The user can't see the code in Power Apps or Power Automate that generates the token, so while they could isolate the token from the data stream, they wouldn't be able to reuse it from another Power App or flow.

skylitedave
Kudo Kingpin

There are two kinds of Flows - Instant Flows and Background Flows - 

Instant Flows are triggered using the PowerApps Connector and you typically add them to the OnSelect of a button in the Power App.  They get called instantly when a user hits the button and you don't need to "share them".  If you have access to the button then you can invoke the instant flow.

 

Background flows are triggered on a timer job behind the scenes.  They have a trigger like " when an item is added to this Sharepoint list"... Those background flows can be shared.  They can sometimes take up to 5 minutes to run.

 

I almost ALWAYS use instant flows and call them through a button click or with logic within the Power App or On Success when I submit a form . They are super useful and powerful.

 

You don't need to hardcode the password, just have a flow call another flow using the method I described in the last post.

 

If you did want to pass the password, you can do it as a parameter or create a JSON structure and pass the password to the flow from the specific Power App that invokes the instant flow.  That way, if another app invokes the instant flow it wont have the password to pass to the flow - since that password is embedded within the logic (script) of the original Power App - I hope this makes sense!

TedBabcock
Helper II

Yes, this all makes sense. Again, thanks to both of you. As I mentioned way above in this thread, I was ecstatic when I heard about PowerApps, and then crestfallen when I learned about implicit sharing. It was a gloomy day, indeed, as I thought I wouldn't be able to use PowerApps after all. Your contributions to this solution saved me.