Attachments REST API returns 403 on Outlook 2016 for Mac

[abhishek1234321]

I am trying to access attachment using REST API as mentioned in this doc https://docs.microsoft.com/en-us/outlook/add-ins/use-rest-api

Both Mailbox version is 1.5

var getAttachmentsUrl = Office.context.mailbox.restUrl + '/v2.0/me/messages/' + itemId + '/attachments';

OWA sends the URL as

https://outlook.office365.com/api/v2.0/me/messages/{itemId}/attachments

This works well

Outlook 2016 version 15.41 (171205) for Mac sends the URL as

https://outlook.office.com/api/v2.0/me/messages/{itemId}/attachments

This throws a 403 error

{
    "error": {
        "code": "ErrorAccessDenied",
        "message": "Access is denied. Check credentials and try again."
    }
}

Because of this the add-in fails to work on Outlook 2016 for Mac.

It works fine in Outlook 2016 for Windows version 1711 (Build 8730.2175 Click-to-Run)

This happens for Uber receipts, I can forward the email if need be.

Another observation is, if I have 3 Uber emails, the first one works fine and rest 2 throws 403.

Whereas the same API works for a different email with a PDF attachment.

[jasonjoh]

Are you saying this only happens on these specific messages? What I would look at here is the token you're using. The URL should not matter here since outlook.office365.com and outlook.office.com are both valid hostnames for the Outlook REST API.

I would get the token from both clients for the same message, then parse it using https://jwt.io and look for differences.

[abhishek1234321]

Yes, it happens to specific messages. So I did compare the decoded data using https://jwt.io

The HEADER:ALGORITHM & TOKEN TYPE is same.

Whereas 2 things differ in the PAYLOAD:DATA

For Outlook 2016 Mac it was

"exp": 1516302672,
"nbf": 1516302372

For OWA it was

"exp": 1516303253,
"nbf": 1516302953

Does this matter?

[jasonjoh]

No, those are timestamps for the lifetime of the token (nbf = "not before", exp = "expires"). I'd expect those to be different.

Could you post the full body of the error? There's usually a request ID included. If not there it might be in the response headers.

[abhishek1234321]

request-id: 1bd8d15e-203d-4a4b-a925-4ed9f1fd8af6

is this what you need?

[jasonjoh]

I hope so :). I tried to reproduce this and could not, the token from Mac Outlook worked fine for me. However, the Uber receipt emails that I have don't have attachments, so I don't know if that's the key to your repro.

[abhishek1234321]

So the map in Uber receipt is considered as an attachment by outlook attachments API.

If you wish to repro, I could send you an email with the link to manifest.xml file and you can see console logs of the error then?

Let me know.

[jasonjoh]

Actually could you post the full set of response headers from a request that gives the error? I'm working with engineering to see if we can determine what's going on from our telemetry.

[abhishek1234321]

So I used to inspect element in Outlook for Mac using this

defaults write NSGlobalDomain WebKitDeveloperExtras -bool true

from here https://stackoverflow.com/questions/47920619/outlook-add-in-not-displayed-in-mac-os?rq=1

But this no longer seems to work, I am unable to find the option to inspect anymore. I updated outlook for mac a few days ago.

I will try to get the data using Vorlon JS. Is there any way to get the inspect element working again?

[jasonjoh]

Hmm, no idea to be honest. I see that the poster added a second post here: https://stackoverflow.com/questions/48074433/outlook-add-in-not-work-with-angular-routing-under-mac-oshigh-sierra-10-13-1

What you might try to make it easier is just copy the token out and then use it with Postman to send the same request your add-in does.

[abhishek1234321]

This was the attachment GET call
https://outlook.office.com/api/v2.0/me/messages/AAMkADRhZTE1Y2QxLWQ0YjQtNDczYS1iMGM0LTljNjE2ZDdlOWEzNABGAAAAAACJCq1z65ziQJtWHUC8GhiHBwA2e2AaQ4VLQorLqTK0zxHhAAAAAAEMAAA2e2AaQ4VLQorLqTK0zxHhAAAD4sgsAAA=/attachments

Here is the response headers

Content-Length →0
Date →Mon, 22 Jan 2018 17:30:07 GMT
Set-Cookie →exchangecookie=2bdc4e8acf684a26a4c81db8adc9cab4; path=/
WWW-Authenticate →Bearer client_id="00000002-0000-0ff1-ce00-000000000000", trusted_issuers="00000001-0000-0000-c000-000000000000@*", token_types="app_asserted_user_v1 service_asserted_app_v1", authorization_uri="https://login.windows.net/common/oauth2/authorize", error="invalid_token",Basic Realm="",Basic Realm="",Basic Realm=""
X-BEServer →MAXPR0101MB1594
X-BackEndHttpStatus →401
X-BackEndHttpStatus →401
X-CalculatedBETarget →MAXPR0101MB1594.INDPRD01.PROD.OUTLOOK.COM
X-CalculatedFETarget →MAXPR01CU001.internal.outlook.com
X-DiagInfo →MAXPR0101MB1594
X-FEProxyInfo →MAXPR01CA0035.INDPRD01.PROD.OUTLOOK.COM
X-FEServer →MAXPR01CA0035
X-FEServer →MA1PR01CA0093
X-MSEdge-Ref →Ref A: 890FD2934AC6472C954A28015F3D6ECA Ref B: MAA01EDGE0219 Ref C: 2018-01-22T17:30:08Z
X-Powered-By →ASP.NET
request-id →3b7b93e0-3fa9-4e26-a19e-c321317ae1d4
x-ms-diagnostics →2000002;reason="The token has expired.";error_category="invalid_lifetime"

So this is throwing 401 instead of 403, couldn't repro the 403 error in postman yet.

But the same call with a token from OWA works fine.

[jasonjoh]

Cool thanks. As a quick test, what happens in Postman if you just ask for the item (take off /attachments) with the same token. Also 401?

[jasonjoh]

Quick update - I did find an Uber email with the map, and I see it as an attachment. I don't reproduce the 403 error though in Mac (16.10 (180114)). I suspect you may have got the 401 in Postman if you waited too long. Those tokens aren't as long-lived as a normal token (I think it's 10 minutes?). I'd really need to see 403 response headers for us to see the problem.

[abhishek1234321]

I am unable to repro this now, looks like it started working somehow. I tried removing the /attachments, it works fine.

Will keep you posted if this comes up again.Thanks for all the support.