Request make from other screen

[LSIA]

Hi,

I develop an application with some SharePoint data connection. For security purpose, I have created few screens with restricted access to ensure that people without ability (based on O365 groups) cannot view them.

When I use the application with an account without permission to access "screen 2" (no buttons available), I have got some access denied errors. When I inspect why using Power Apps monitor, I can see that all errors are coming from "screen 2" connections. But the current user never access to this screen and I have no data connection from the home page (on start or other means).

Info : To ensure security, the SharePoint list/library have (and must have) custom rights definitions.

So, two questions :

1. Why fields connected on "screen 2" to restricted SharePoint connection make requests when "screen 2" is not being used ?
2. Is it possible to avoid multiple error messages when I'm logged in with an account without rights to access "screen 2" ?

[RandyHayes · Accepted solution]

@LSIA 

A PowerApp app is not like a developed app.  The player for apps needs to be able to access any referenced datasources in your app and will initialize them when you start up.  Even if they are not ever used, they are initilized.

So, the moral of the story is, you cannot implement security of your app the way you are.  Users must have access to datasources in your app.

I hope this is helpful for you.

[LSIA]

hi @RandyHayes,

Many thanks for your feedback.

I was sincerely hoping that I was the one me who missed something.
This means we have two options:

1. Create two different applications, depending on the profiles
2. Abandon the security of the application

However, for performance reasons, I think it's a bad things that all queries are made at initialization, even for data that is never used.

[RandyHayes]

@LSIA 

Not all data is gathered during initialization.  PowerApps is very performant and that can be broken very easily once designed.

When you start an app, PowerApps creates session tables in the cloud.  This is an intermediary between the real datasource and the app.  It would be highly inefficient if PowerApps accessed the datasource directly all the time.  So, PowerApps will create a "stub" table in the cloud session.  That stub table has all of the relevant data information - the schema, required information, data types, etc.  But it is empty.  It uses a Lazy Load pattern to fill up.  Once you start requesting data in your app, it goes to the datasource and gets it and puts it in the session table.  From there it exists for further calls to that data.

BUT, I am going on more about the "after initialization".  For your scenario, the first part of that is important - if the app is defined to use a particular table, then it will stub out that table.  It may NEVER have data in it, but it is still initialized, and as such, the user needs access to read that information as the app will run under the context of that user...and it will want to stub out the table.  If it can't...then you will see the internal error banner.

In your scenario, the "easiest" solution is a separate app for the more privileged list.  The first app can bring that up for those that have access.  This may or may not be sufficient depending on what you are doing (or considering doing) in your current app.

Beyond that, there are methods to employ PowerAutomate to alter permissions on items as they are created in a list.  So, the user would have full access to what they need.  Their records would be visible to only them and any "administrators" that are designated.  This way, they still have access to the list (and the stubbing will work fine) and when they access the list, they will see only what they have permission to see.

[LSIA]

Many thanks for this valuable informations.

It's good to know how it works internally, and I now understand why these requests are made. Splitting the app into two parts is clearly not a the way we want to go.

I found a solution by creating a custom right level in SharePoint, with only access to application pages, not items. This solution is easy to use for all SharePoint data source.

We already use Power Automate to break inheritance and set custom permissions, this is one of our 26 workflows used in this app 😅.