Content
View differences
Updated by Marcello Rocha Pereira almost 2 years ago
**TL;DR:** To make use of `Sites.Selected` we need to specialize our implementation to be SharePoint specific.
I've investigated the usage of `Sites.Selected` instead of our more broad `Files.ReadWrite.All`.
#### A brief primer on `Files.ReadWrite.All`
Since we deal with files and their related permissions exclusively, this permission ensures that we can operate then freely. Also it is the permission checked every time we access any of the `/drives/{driveId}/` endpoints of the MS Graph API.
Note that files can be accessed by multiple different paths (such as `/sites/{sideId}/drives/{driveId}/` or `/me/drive/`), but the more universal is the mentioned above.
##### But what are the risks involved with this permission?
The main issue is that this permission is tenant wide. If you grab another driveId for that tenant, the application will have full access to it.
#### Cool, what about `Sites.Selected`?
This permission was first introduced to limit the access of application to just certain resources within Sharepoint. Basically you grant the application this permission and then a Sharepoint Admin adds the app to specific Sharepoint sites, lists and drives.
Of course this permission offers better fine-grained control over the resources of a larger Sharepoint deployment.
##### But at what cost?
To make actual use of this permission (based on my current understanding), we would need to scope all calls through a Sharepoint site requiring the rework of almost all commands and queries to scope the access to a Sharepoint site and probably add the Sharepoint Site ID as a configuration to the Storage.
I've investigated the usage of `Sites.Selected` instead of our more broad `Files.ReadWrite.All`.
#### A brief primer on `Files.ReadWrite.All`
Since we deal with files and their related permissions exclusively, this permission ensures that we can operate then freely. Also it is the permission checked every time we access any of the `/drives/{driveId}/` endpoints of the MS Graph API.
Note that files can be accessed by multiple different paths (such as `/sites/{sideId}/drives/{driveId}/` or `/me/drive/`), but the more universal is the mentioned above.
##### But what are the risks involved with this permission?
The main issue is that this permission is tenant wide. If you grab another driveId for that tenant, the application will have full access to it.
#### Cool, what about `Sites.Selected`?
This permission was first introduced to limit the access of application to just certain resources within Sharepoint. Basically you grant the application this permission and then a Sharepoint Admin adds the app to specific Sharepoint sites, lists and drives.
Of course this permission offers better fine-grained control over the resources of a larger Sharepoint deployment.
##### But at what cost?
To make actual use of this permission (based on my current understanding), we would need to scope all calls through a Sharepoint site requiring the rework of almost all commands and queries to scope the access to a Sharepoint site and probably add the Sharepoint Site ID as a configuration to the Storage.