Notes

  messageParentApiMethod

 getBodyAsyncApiMethod

 getBodyTypeAsyncApiMethod

 bodyPrependAsyncApiMethod

 closeApiMethod

 closeAppApiMethod

 getEnhancedLocationsAsyncApiMethod

 addEnhancedLocationsAsyncApiMethod

 removeEnhancedLocationsAsyncApiMethod

 addItemAttachmentAsyncApiMethod

 addFileAttachmentAsyncApiMethod

 addFileAttachmentFromBase64AsyncApiMethod

 removeAttachmentAsyncApiMethod


refer
bug (https://outlookweb.visualstudio.com/Outlook%20Web/_workitems/edit/59675/) , a preliminary PR has been merged now. Now we should be creating a list and then put this check in every apis.

Merged PR for context - https://outlookweb.visualstudio.com/Outlook%20Web/_git/client-web/pullrequest/36676?_a=overview

------------------------------------------------------------------------------------------------------------------------------------------------------------

Currently OWA React is not failing add-in API calls that an add-in doesn't have permission to call, based on the permission level in the manifest.

Note that getCallbackTokenAsync still returns the correct token because that check is done on the server-side. I also tried makeEwsRequestAsync in OWA. That API returned a successful result, but at least the SendItem request that the feature test add-in runs seems to have failed because no email was sent.

So, one example of a known impact of this bug is it allows ReadItem add-ins to call ReadWriteItem APIs.

Add-ins have 4 possible permission levels: Restricted, ReadItem, ReadWriteItem, and ReadWriteMailbox. Each API also has a minimum permission level. Together, these levels determine which APIs an add-in can call.

The API files loaded by Office.js runs within the add-in iframe and checks the permission level before a call is made to the host application in order to throw a javascript error if the add-in doesn't have permission to call the API. Since the API file runs within the add-in iframe, it can be modified or bypassed, so the permission check must also be performed by the application hosting the add-in.

I found this bug because there was a separate bug in the new version of the API file, where the permission error was not being thrown by the API file, and the call was passed onto the host. This made the bug in OWA more easily discover-able. The new API file is flighted only within Microsoft and that bug will be fixed before it is flighted externally. Opened this bug for the API file: Bug 3768555: [Dogfood Feedback] New JS API files don't return errors based on permission checks

It looks there is some API-specific code in OWA React that checks the permission level, but it's not used to prevent APIs from being executed.

APIs tested so far that should return an error but don't:
makeEwsRequestAsync - doesn't return an error; though doesn't seem to work either
body.prependAsync - writes text to the body, which shouldn't be allowed
Most other Compose APIs (ran the API test add-in under ReadItem permissions and most of the Compose tests succeeded)