-
Notifications
You must be signed in to change notification settings - Fork 190
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GetPermissionRequestsAsync does not return request for the app where another app with the same scope was previously approved. #1406
Comments
@larry-lau : thanks for reporting this. @mloitzl : is this something you can have a look at? |
@jansenbe Yep, I think I will be able to fix this issue. @larry-lau Thanks for the thorough analysis 🤜🤛 |
@mloitzl : did you manage to have some time for this? |
Hi @jansenbe, There's an edge case left I want to cover: I think I will be able to finish on one of the upcoming weekends. |
Dear @jansenbe, Some updates on that: I did some research and discovered that also the "API Access" page in the SharePoint Admin Portal now uses the Graph API instead of the CSOM API to grant OAuth2Permissions on the SharePoint Client Extensibility Principal. During that I found some other GitHub issues, e.g. SharePoint/sp-dev-docs#9633, or microsoftgraph/msgraph-sample-spfx#14 which may also have the same reason. I put together a PoC in this draft PR #1479 that mimics the behaviour of the API Access page (work in progress). It extends the IApp with an ApprovePermissionRequestsAsync method. Some questions on that:
Thanks for the feedback, Martin |
@mloitzl : interesting find on the move to Graph, let me check with the engineering side and come back to you. Thanks for helping with this one! |
Yep, tested it on 2 different tenants, loitzl1 and loitzl2, same behavior…
also with the m365 cli, btw.
Then I tried the API Access in the Admin Center and found the new way using
browser developer tools.
The new way works good 👍
Am 10.06.2024 um 14:10 schrieb Bert Jansen ***@***.***>:
@mloitzl <https://github.com/mloitzl> : can you also check if the
"SharePoint Online Client Extensibility Web Application Principal" still
showing up in your tenant?
—
Reply to this email directly, view it on GitHub
<#1406 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADARU52OBBHXVRM27O2FYC3ZGWJUDAVCNFSM6AAAAABDVPK23SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJYGE3TKNZRGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
@mloitzl : moving to Graph is indeed the recommended approach, we can mark the CSOM based methods as obsolete once done and then drop them in a next major release. The fact that CSOM fails is however not expected, I could repro this and am following up. |
Hi @jansenbe
Some issues with that: What do you think? I am open for hints/feedback/advise/help on the changes in #1479 |
@mloitzl : thanks for the great work on this! We're still investigating the issue with the existing CSOM API and will fix that, but being able to use the "modern" approach via Graph is the future. Let's settle with a "2" suffix whenever that's needed for methods and types. When there's already an "Async" suffix then the let's go for "...2Async". Once this is in place we can mark the old classes/methods as Obsolete. In a next major release then obsolete classes/methods then will be removed from the code base. This way we give folks time to switch over without breaking their code. |
Category
GetPermissionRequestsAsync does not return request for the app where another app with the same scope was previously approved.
Steps to reproduce
Note: App1 and App2 has the same scope name "access_as_user" which is commonly used in OAuth application.
4. Call GetPermissionRequestsAsync()
Expected behavior
The expected return value should contain an request object for App2 / access_as_user
Environment details (development & target environment)
Additional context
Investigating further, I found that the filter logic in GetPermissionRequestsAsync in ServicePrincipal.cs is filtering out previoysly approved permission by looking at the scope only. It does not account for different resource Id with the same scope name.
Line 102 in ServicePrincipal.cs
The filter logic should check both resource id and scope.
Thanks for your contribution! Sharing is caring.
The text was updated successfully, but these errors were encountered: