We are retrieving the email and attachments using the oAuth token from getCallbackTokenAsync in office.js JavaScript library and sending the token to the web application to retrieve them from EWS (~/EWS/Exchange.asmx) using SOAP request similar to the approach shown in https://learn.microsoft.com/en-us/office/dev/add-ins/outlook/get-attachments-of-an-outlook-item
Could anyone please confirm that the deprecation of Outlook Rest API 2.0 will not affect the existing functionality. I am new to the Outlook add-in development and the documentation seems vast to digest.
https://devblogs.microsoft.com/microsoft365dev/outlook-rest-api-v2-0-deprecation-notice/
Do we need to register the add-in anywhere OR provide any permissions to the add-in specifically for getCallbackTokenAsync method to retrieve the token OR making the SOAP request to download attachments.
EWS remains unchanged for Outlook web add-ins. Make sure that you don't use the isRest option for the getCallbackTokenAsync call.
Take a look at the recent Office add-ins community call where this question was discussed in depth. Here is a screenshot for others:
Related
I have an outlook addin that I've built using Yeoman. The addin communicates with a server API on my server to combine data from an email with additional data from a database that a user has saved against an email address. This is all working great.
Next I want to store a copy of the email server side, as a file on disk, .msg preferred but I'll take a .eml if thats the only option.
I have 2 options but don't know if either are possible. Either the addin generates the .msg file and posts it to the server API OR the server side API generates the .msg file directly. I have got the server side using the Outlook v2 API and able to pull back the email information when the client passes it the token, id etc. If it could just generate/download a .msg file server side this would be ideal.
As a side note, many of the Microsoft API pages point out the deprecation of the Outlook API in favor of the Graph API, however there are inconsistent links between the pages and it get confusing. I have discovered the token from getCallbackTokenAsync only works with the Outlook API and not Graph, but I cant find out a way to generate a graph compatible token. All the example code from MS uses Office.context.mailbox.restUrl which still gives the Outlook API url and not Graph!
So I guess I'm trying to find out if it's even possible to get/generate a .msg or .eml file either client side using outlook.js or server side using one of the api's. Thank you.
I can get message data both client and server side but cannot get a physical email file.
The Office JavaScript API (OfficeJS) doesn't provide anything for saving messages as msg files (or getting streams). The best what you could do is to use Graph API where you could get the EML file, see Get MIME content of a message for more information.
The server-side code may use the OAuth 2.0 On-Behalf-Of flow (OBO) to request a new access token with permissions to Microsoft Graph. Read more about that in the Authorize to Microsoft Graph with SSO article.
The on-behalf-of (OBO) flow describes the scenario of a web API using an identity other than its own to call another web API. Referred to as delegation in OAuth, the intent is to pass a user's identity and permissions through the request chain.
For the middle-tier service to make authenticated requests to the downstream service, it needs to secure an access token from the Microsoft identity platform. It only uses delegated scopes and not application roles. Roles remain attached to the principal (the user) and never to the application operating on the user's behalf. This occurs to prevent the user gaining permission to resources they shouldn't have access to. See Microsoft identity platform and OAuth 2.0 On-Behalf-Of flow for more information.
Eugene's answer is good. If ultimately you need to get that message to your backend service, using Graph as Eugune described would be the recommended approach. If for whatever reason you are still looking for a capability to access it on client using Office.js, it is not a part of the product. We track Outlook add-in feature requests on our Tech Community Page. Please submit your request there and choose the appropriate label(s). Feature requests on Tech Community are considered, when we go through our planning process. Note there is already a couple of similar ideas there, if you search for "eml" keyword, that you may want to upvote.
My Outlook web add-in is using the Office.context.mailbox.getCallbackTokenAsync method passing 'isRest = true' in options. This is to get an authorized token I can use to make requests to the Outlook REST API. This works fine on Outlook 2019, in OWA and on Office 365 Windows Desktop client, however it does not work for Outlook 2016. Attempting to use the retrieved token against the REST API returns 403 status.
The requirement sets for the add-in API indicate that Windows Outlook 2016 only supports up to version 1.4 (see here), and the support for 'isRest=true' in the getCallBackTokenAsync method is only added in requirement set 1.5.
Given this limitation on Outlook 2016 is there any other way to silently (as in no user interaction via pop-ups etc) get an Outlook REST API token in my web add-in on Outlook 2016?
The REST API endpoint that needs to be contactable is '/v2.0/me/'.
Note the target backend is an Exchange 2016 on premise solution so integrating with Azure isn't an option from what I can tell.
Potential Options Already Considered
Calling getCallBackTokenAsync and passing isRest on Outlook 2016 looks to return an EWS token - Exchange.Callback.V1. However I cannot use this as the add-in is passing the retrieved token to a server that makes the REST API request and that server cannot be changed to also support the EWS token without a much longer turnaround than if I can modify the add-in code instead.
I looked at taking the relevant isRest code from outlook-win32-16.02.js to make the call myself. I got as far as executing the token call against window.external but while this works on Outlook 365 it doesn't successfully return on Outlook 2016 so I'm assuming it that the underlying client does not support the operation rather than just the office.js library not having it exposed.
window.external.Execute(12, [JSON.stringify({"isRest" : true, "itemNumber": "1"})], function(result){console.log('Result is: ' + JSON.stringify(result));});
Considered overriding the request to the server made by a getCallbackToken call for EWS token and modifying the XML body to the REST token retrieval equivalent however overriding XMLHttpRequest.send only had an impact in OWA. That does not seem to be used in the Outlook desktop client to issue the EWS call to retrieve the token.
Currently I'm looking at whether I can make a GetClientAccessToken call to the Exchange server manually (the office.js makeEwsRequestAsync method does not support this call), however I can't see a way to get a valid authentication header for the request and the Id and ParentItemId properties that need to be passed on request body. The EWS token from getCallbackToken is not authorized to perform a GetClientAccessToken call.
Retrieving a REST token in Outlook 2016 is currently not supported.
An alternative is to use oauth. The add-in developer could register an appId and have the add-in users go through the one-time consent flow for authentication. Documentation on how to use oauth can be found here.
I'm currently using Microsoft Graph, but have been running into its limitation on the request size. Seeing as how the Outlook REST API doesn't have that limitation and is supposed to be very similar to the Graph API for mail related functions, I wanted to use the Outlook API for sending messages with larger attachments.
But is there a way to get application level permissions with the Outlook REST API? Or make calls without a user? The authentication approach I'm using with Microsoft Graph is the one outlined at https://learn.microsoft.com/en-us/graph/auth-v2-service and it would be nice to be able to do the same with the Outlook API.
My app is registered at the Microsoft Application Registration Portal, but the permissions there are only for Microsoft Graph. I have seen an article that mentions being able to edit the manifest in order to get permissions working with other APIs (like the Outlook API), but wasn't too sure about that.
I'm researching requirements for a new Outlook add-in. I'd like to determine if the current version of the JavaScript API allows add-ins to enumerate all of the current user's contacts and calendar events. I need to sync these contacts and events against a third-party system using a REST API.
Is a "get contacts" and/or "get events" (bounded by a date) query possible using the native Outlook add-in JavaScript API?
I'd prefer to do this using the native JavaScript API, but this could be something more suited to an Exchange Web Services call. Something involving makeEwsRequestAsync, perhaps?
The Mailbox API doesn't have any methods for accessing data beyond the context of the current item that the add-in is activated for. So yes, EWS is an option, as well as the Outlook REST APIs.
EWS can be quite difficult to work with, as the XML requests and responses are time consuming to work with (one typo and you're screwed). I would recommend the REST APIs instead.
I have written an Outlook Add-In using the "standard" approach, which is a COM Add-In, compatible with Outlook Windows desktop versions.
I'm doing now a research about the capabilities of the new Office API which uses Javascript/HTML and is compatible with Outlook 2016 Windows/Mac and Web.
However, the resources seem really limited, where can I the information what functionalities that API provides i.e. in scope of the Calendar functionality of Outlook?
You can get started using JavaScript APIS using this link : https://dev.outlook.com/MailAppsGettingStarted/GetStarted
API Reference : https://dev.outlook.com/reference/add-ins/
This API provides access to mail/calendar item. This APIs are supported in Windows Outlook 2016 and Outlook Web Mail access client.
Hope it helps.
You are right, the functinality is still limited. See https://dev.outlook.com/ for more information about available APIs. But you may also find the EWS helpful. Read more about that in the EWS Managed API, EWS, and web services in Exchange section.