Sp-dev-docs: Error in API Permission Request handling

[spcph]

Category

• [x] Question
• [ ] Typo
• [x] Bug
• [ ] Additional article idea

Expected or Desired Behavior

When adding a solution with permission requests, I would expect the API Management page to know if a request for a specific permission has been already approved, and hence not re-add it to the pending requests on solution update. Particularly in light of the fact that approved permissions are valid across solutions.

Observed Behavior

When I add a solution with Graph Permission Requests, they are added as Pending Requests in API Management. When I update the solution in the app catalog, it appears to me as if the Permission requests are added to API Management once again.

If I have several solutions with permission requests, that are regularly updated, i soon end up with a massive amount of pending approvals. As the list grows, eventually I reach 100 pending requests, and then everything stops. No new permission requests are added. Even though I add a new solution with a new set of requests. Since I am unable to approve an already approved request without receiving an error I have no way of keeping the pending approval list under control.

Steps to Reproduce

Add a solution to the app catalog with permission requests, and update it a couple of times and watch the pending approval list grow. Keep updating it and watch everything stop at 100 pending requests.

---

Or is it just me who haven't understood the way this is supposed to work?
Thanks.

[msft-github-bot]

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[andrewconnell]

As strange as this is, it is by design.

Best way to deal with it: submit a user voice feature request... I'd vote it up! http://aka.ms/sp-dev-uservoice

[spcph]

As strange as this is, it is by design.

Best way to deal with it: submit a user voice feature request... I'd vote it up! http://aka.ms/sp-dev-uservoice

Ok, I am completely puzzled by you answer. I think it might actually keep me awake to night. :-) Are you saying that it is by design that more than 100 pending requests makes you unable to add any further permissions requests, when at the same time I have no way of bringing down the number of pending requests except for not deploying solutions with requests???? Bearing in mind that removing the solution with the original request doesn't even remove the request and deploying an update just doubles up on the requests..

I have a really hard time comprehending that someone would deliberately make a design like that.

How would you suggest the wording of the UV feature request? "Please redo your design architecture for Permission Requests because the current one actually doesn't work. It's not a bug, it's a design flaw." :-)

[andrewconnell]

I missed your point about "100"... I didn't realize you were being literal. Are you saying that when you add 100, no more pending requests are added? ... please clarify this point...

There are two ways to add permission requests: declaratively from within the app & via the REST API (more commonly submitted with POSH / O365 CLI).

IMHO, the latter two options make the most sense. App installation & permission grants are not tied together... permission grants are for an entire tenant, not to an app. So from my POV, it's a bit odd (_to be clear, this is my opinion, not representing MSFT in any way_) to include it within the app. Rather, the app should be built to detect if a request fails and if so, it should be part of the guidance to point to the tenant admin to ensure the app has the necessary permissions with guidance on how to address it.

[spcph]

I missed your point about "100"... I didn't realize you were being literal. Are you saying that when you add 100, no more pending requests are added? ... please clarify this point...

There are two ways to add permission requests: declaratively from within the app & via the REST API (more commonly submitted with POSH / O365 CLI).

IMHO, the latter two options make the most sense. App installation & permission grants are not tied together... permission grants are for an entire tenant, not to an app. So from my POV, it's a bit odd (_to be clear, this is my opinion, not representing MSFT in any way_) to include it within the app. Rather, the app should be built to detect if a request fails and if so, it should be part of the guidance to point to the tenant admin to ensure the app has the necessary permissions with guidance on how to address it.

I am refering to the declarative way. When I include permissions in the package-solution.json file like this:

"webApiPermissionRequests": [
{
"resource": "Microsoft Graph",
"scope": "Files.Read"
}
]

the "magic" happens.

Let's say we have a couple of solutions each with 4 or 5 permission requests. Even though some of the requests are for the same permissions they are essentially duplicated in the api management and will appear one time for each solution. Now as I experience it, every time I update a solution, the requests are re-added to the pending list. You can probably imagine that the number of pending requests just keeps growing with time. This might just be down to poor design as you say but what I experience is that once I have more than 100 pending requests, any further requests in any solution, updated or newly added, are simply just ignored.

I'm sorry if this wasn't completely clear in my original post. :-)

I completely agree on the oddity of tenant wide permission being tied to the solution. On the other hand, in an SPFx context it kind'a makes sense that a solution requires specific permission, which it then requests. It shouldn't however have to care or know about any other solutions requesting the same permissions. The API Management should just recognize that a requested permission has already been approved.

Maybe it's just me having too high hopes that the declarative pains from feature framework caml was gone now that we use JSON instead of XML. :-)

[andrewconnell]

Yup... now I get it. In full agreement, and this is why I don't like the declarative approach; the declarative approach has no consideration of what other permissions are already granted/pending. Further, to a non-educated admin, it implies the permission is only for that one app... even though it isn't. This is why my rec is to use the POSH / O365 CLI to grant permissions. This approach is MUCH more clear in saying "it's for the tenant, not the app" because nowhere do you specify the app in a grant.

At present, my understanding is that the UX is "by design", so a feature request/enhancement would be the best vehicle to get it changed.

[spcph]

Great. Everything is clear now.

Please upvote. :-)

https://sharepoint.uservoice.com/forums/329220-sharepoint-dev-platform/suggestions/36608707-let-the-declarative-way-of-requesting-api-permissi

[andrewconnell]

[spcph]

I think the 2 options you mention @andrewconnell needs to be stronger promoted by MS. I searched around for info last night and was only able to find Waldeks blog from early November about the new features of O365CLI. I have yet to find official info on the POSH method/commands.

Luckily the CLI is the only way for me on a Mac, and it just works beautifully. I can completely clean up my request queue. So bye bye webApiPermissionRequests.

Thanks for clarifying things for me.

[andrewconnell]

Yup... working on it. I doubt you'll see MSFT push the REST API based options (POSH/O365 CLI)... but good to hear that resonated with you. I do plan on blogging about it myself soon... working on this chapter for my course at the moment so getting my message down first ;)

[waldekmastykarz]

FWIW, not sure if you've seen it already @spcph, but we have a new command in the CLI that simplifies adding grants even further: https://pnp.github.io/office365-cli/cmd/spo/serviceprincipal/serviceprincipal-grant-add/

[spcph]

FWIW, not sure if you've seen it already @spcph, but we have a new command in the CLI that simplifies adding grants even further: https://pnp.github.io/office365-cli/cmd/spo/serviceprincipal/serviceprincipal-grant-add/

Thanks @waldekmastykarz, the CLI was exactly what I used to clean up the mess. And what I will keep on using going forward. It works like a charm. I had used the grant add command seconds before your post. :-)

[msft-github-bot]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues