Office-js: Calls to api/v2.0/me/messages/ with a REST token obtained using getcallbacktokenAsync fail with 404 for a shared folder

[GrumpyAL]

Calls to api/v2.0/me/messages/ with a REST token obtained using getcallbacktokenAsync on an item in a shared mailbox fail with 404. This was working a few weeks ago and suddenly stopped.

Expected Behavior

When an Office Add-in has the supportssharedmailbox flag set to true, REST tokens obtained should work to pull messages from the shared mailbox when invoked by a user with the proper permissions. As it did previously.

Current Behavior

REST tokens obtained by the add-in on a shared mailbox and used to authenticate to api/v2.0/me/messages/ return a 404:

{"error":{"code":"ErrorInvalidMailboxItemId","message":"Item Id doesn't belong to the current mailbox."}}

Steps to Reproduce, or Live Example

I do not have code I can share at this time, but the repro steps are simple.

Repro Steps

1. Load a manifest with set to true
2. Invoke on an email in a shared mailbox in which you have Full Control
3. Obtain the REST token, Item ID and REST URL using Office Add-ins Functions
   a. Office.context.mailbox.item.itemId
   b. Office.context.mailbox.restUrl
   c. Office.context.mailbox.getCallbackTokenAsync({isRest:true}, ...)
   
   
   
   1. Using those, attempt to retrieve the item at api/v2.0/me/messages/[ITEMID]
   
   
   2. A 404 is returned (this worked previously)
   
   

Context

We have an add-in that implements that was tested and found to work until something changed recently.

Your Environment

• Platform PC, Mac, OWA, iOS, Android
• Host Outlook
• Office version number: Any that supports API set 1.8 (e.g. 2004 (Build 12730.20236)
• Operating System: Windows 10, Server 2016
• Browser (if using Office Online): Chrome, IE, Edge, Safari
• Can reproduce in PowerShell if correct information obtained through an Add-in (Token, ID, etc).

Useful logs

{"error":{"code":"ErrorInvalidMailboxItemId","message":"Item Id doesn't belong to the current mailbox."}}

[DmitryKostochko]

We are facing the same issue and need a fix ASAP. FYI, this REST API functionality worked fine a few days ago.

[exextoc]

To confirm, are you seeing this for a read mode item? Does this only repro for a shared folder (items that the user is accessing are owned by someone else)? And are the mailboxes hosted on Microsoft/Office 365 instead of on-premise?

If so, to construct the rest URL for shared item, instead of using api/v2.0/me/messages/, the addin should use the info from SharedProperties, following https://docs.microsoft.com/en-us/javascript/api/outlook/office.sharedproperties?view=outlook-js-1.8.

[DmitryKostochko]

To confirm, are you seeing this for a read mode item?

Our add-in works in the compose mode. We are using REST API to read emails from another mailbox.

Does this only repro for a shared folder (items that the user is accessing are owned by someone else)?

In our case, user A gave access to a folder (and all parent folders) for user B. User B got access to all emails in the folder. Note, user A did not delegate access to mailbox, just folder permissions were used.

And are the mailboxes hosted on Microsoft/Office 365 instead of on-premise?

Yes, both mailboxes are hosted on Microsoft 365.

@exextoc, we don't have the SupportsSharedFolders flag in our manifest, moreover, we have clients that use 1.7 and even 1.5 versions of Outlook JS. As you understand, we cannot use SharedProperties. And I think all these details are secondary, not important. The important thing is that the part of the REST API that worked for years does not work today. And no workarounds or new APIs will help all existing applications that rely on the REST API. I think this compatibility problem shall be fixed asap, agree? Please consider the issue from this point of view.

[GrumpyAL]

Thank you for the information @exextoc. I will create a POC with that information and see if it works for us.

However, I do notice one thing. When I access my mailbox via outlook.office.com (vs outlook.office365.com) the sharedProperties property targetRestUrl does not exist. When I look in the network tab, I see it's trying to reach out to an autodiscover URL (https://outlook.office.com/autodiscover/autodiscover.json/v1.0/[STMP]?Protocol=REST) and getting a 404. If I change my outlook URL to outlook.office365.com and run the test script again then thetargetRestUrl property works as expected and the autodiscover URL returns properly. Curious if this is a bug or temporary issue or if we should code a fallback to use Office.context.mailbox.restUrl in the event that sharedProperties targetRestUrl is undefined and just hope they are the same in that event.

Also, could you please explained what changed? Previously we were able to use the api/v2.0/me/messages/ end point to retrieve a message from a shared mailbox. Unfortunately, the supportsSharedMailboxes documentation does not reference the also new sharedProperties interface documentation so we simply added that tag and saw that it worked. I see now changes we can implement to use the sharedProperties interface, but curious if something on the back-end changed, or if there was a bug etc that allowed it to work in the first place via api/v2.0/me/messages/

Thanks very much.

[exextoc]

@GrumpyAL for the missing targetRestUrl issue, to confirm, are you seeing that particular issue with OWA?
With api/v2.0/me/messages/ 'me' is meant for the calling user. This is one of the reasons we introduced the SharedProperties API for supportssharedmailbox with addins.
Thank you for you feedback on documentation, we will update based on this discussion.

[exextoc]

@DmitryKostochko since your addin is for compose, and you are not using SupportsSharedFolders, could you please create a new post with more details?
Support for addins in a shared folder is introduced with 1.8 API and SupportsSharedFolders in the manifest. Having said that, some compose scenarios (eg. sending as another user) still operate within the user's mailbox, and a new post will help us understand more.

[exextoc]

For reference, here's a post related to this change: https://developer.microsoft.com/en-us/office/blogs/accessing-outlook-items-in-a-users-archived-shared-or-delegated-mailboxes-using-microsoft-graph/

[GrumpyAL]

@GrumpyAL for the missing targetRestUrl issue, to confirm, are you seeing that particular issue with OWA?

@exextoc Yes, this is in OWA, when accessed via outlook.office.com

[JamesBigChange]

We're in a similar position.
Thanks @GrumpyAL for the cause of the 404 errors - that had me stumped for the last 24 hours as I had https://outlook.office.com bookmarked!
@exextoc must we tell our add-in users to use https://outlook.office365.com rather than https://outlook.office.com for Office Online?

[naemcivic]

This issue seems to be similar to our issue on hand. https://github.com/OfficeDev/office-js/issues/1116

The flow use to work up until 2 weeks ago on our end. Please help us resolve this.

[exextoc]

@GrumpyAL Could you please provide the following details regarding the issue " sharedProperties property targetRestUrl does not exist in outlook.office.com?

• In which browser are you seeing this issue and is the issue consistent?
• Are you getting any errors in console while making the call to Office.context.mailbox.item.getSharedPropertiesAsync and whether other Shared Properties such as targetRestUrl, owner, delegate Permissions populating correctly?
• Are you making this call for Shared Message in Read mode?

[JamesBigChange]

@exextoc hope you don't mind me adding our findings while you wait for @GrumpyAL .

When using https://outlook.office.com in the Chrome and Firefox browsers (others untested), we see a 404 error in the console for:
https://outlook.office.com/autodiscover/autodiscover.json/v1.0/[email protected]?Protocol=REST
at:
getSharedPropertiesApiMethod.ts:34

targetRestUrl is NOT populated while others such as delegatePermissions, owner and targetMailbox ARE populated.

We do not see this issue when using Office Online at https://outlook.office365.com (different domain)

We are making the call in Read mode.

[exextoc]

@JamesBigChange #1161 is tracking this fix.
@naemcivic This is because of a change in Graph API, using getSharedPropertiesAsync is the solution. Our team is working towards enable this API on Outlook for Mac.
@GrumpyAL Can you respond to our queries?

[GrumpyAL]

Hi @exextoc sorry for the delay.

• In which browser are you seeing this issue and is the issue consistent?

I was testing in Chrome and using the console to input the commands. It was consistent with the office.outlook.com URL

• Are you getting any errors in console while making the call to Office.context.mailbox.item.getSharedPropertiesAsync and whether other Shared Properties such as targetRestUrl, owner, delegate Permissions populating correctly?

This last time I tried, I get a 503 trying to reach the autodiscover URL, thrown by getSharedPropertiesApiMethod.ts at 34

The properties I have available are:

• DelegatePermissions
• owner
• targetMailbox

targetRestURL is missing / undefined

• Are you making this call for Shared Message in Read mode?

This is in the context of an add-in in read mode with the add-in frame open. The add-in has declared the "supportsSharedFolders" tag in the manifest.

Please let me know if you need additional information.

[GrumpyAL]

I think we're seeing the same thing as @JamesBigChange and as stated in #1161 as well. Just sometimes it can be a 503, other times a 404. But the end result is the same, the targetRestUrl property is undefined.

[exextoc]

Thanks for the confirmation @GrumpyAL please use #1161 to track

[GrumpyAL]

To confirm, are you seeing this for a read mode item? Does this only repro for a shared folder (items that the user is accessing are owned by someone else)? And are the mailboxes hosted on Microsoft/Office 365 instead of on-premise?

If so, to construct the rest URL for shared item, instead of using api/v2.0/me/messages/, the addin should use the info from SharedProperties, following https://docs.microsoft.com/en-us/javascript/api/outlook/office.sharedproperties?view=outlook-js-1.8.

@exextoc I'm seeing this reverted again in a shared mailbox:

1. If I get an item ID for a shared item and...
2. Get a rest token using getCallbackTokenAsync(isRest:true) and...
3. Construct the rest URl using the /me/messages endpoint

I am able to pull the message, however, I don't expect this to work per the blog post linked above:

https://developer.microsoft.com/en-us/office/blogs/accessing-outlook-items-in-a-users-archived-shared-or-delegated-mailboxes-using-microsoft-graph/

The result of this is that we're able to pull emails from shared mailboxes in unsupported scenarios (https://github.com/OfficeDev/office-js/issues/1295) but in an unintended way.

I'm wondering if what we're seeing here is a bug and that the ability to pull an item from another mailbox using the /me endpoint is unintentionally or if this was reverted intentionally.

Thanks!