Authenticating a REST request in an Excel Add-in - excel

Question

I am trying to develop an add-in for Excel with the goal that it will create calendar events based on data inside a spreadsheet.
I can do almost everything that I want except use the REST API to build the events in the calendar and I can't exactly figure out where I went wrong.
I have followed the documentation suggested by #MarcLaFleur.
I can build and run the application no problem, but when I click on the 'Get my files from OneDrive' button, I get the following:
Code: 5001
Message: An internal error has occurred.
name: Internal Error
This is coming from the program.js file in the public directory somewhere in the else clause of this function.
function getDataWithoutAuthChallenge() {
Office.context.auth.getAccessTokenAsync({ forceConsent: false },
function (result) {
if (result.status === "succeeded") {
// TODO1: Use the access token to get Microsoft Graph data.
accessToken = result.value;
getData("/api/onedriveitems", accessToken);
}
else {
console.log("Code: " + result.error.code);
console.log("Message: " + result.error.message);
console.log("name: " + result.error.name);
document.getElementById("getGraphAccessTokenButton").disabled = true;
}
});
}
Here are the scopes in my manifest.xml
...
<WebApplicationInfo>
<Id>c931b396-7 ... </Id>
<Resource>api://localhost:3000/c931b396-7 ... </Resource>
<Scopes>
<Scope>files.read.all</Scope>
<Scope>profile</Scope>
</Scopes>
</WebApplicationInfo>
</VersionOverrides>
And here are the scopes on apps.dev.microsoft.com:
If you can shed any light for me, it would really help me out.

Answer 1

5001 can be caused by not requesting profile scope. You need to request the profile scope in addition to Calendar.ReadWrite. You do this when you register the app, as well as in the manifest. For more information, see the articles that Marc LaFleur linked to.

Answer 2

The 5001 error often suggests something fundamentally wrong with the add-in API in Office. For example, your Office app doesn't support the API, the manifest is incorrect, or the version of office.js doesn't work with it. Since you're using the sample, two things come to mind:
You aren't running the latest Insiders
build
The wrong manifest is getting loaded (this sometimes happens if you're
on Windows and using a version of Visual Studio 2017 that has old
schema files, so you have to do a post-build clean up of the debug
Manifest XML)
Your manifest and Azure registration look mostly good, though Rick's comment about Scopes is relevant. profile must work with openid as a pair (profile alone won't work; openid alone won't work), and as discussed you need this consented. As the developer, you can try consenting for yourself at the protocol level. You’ll want to update the client_id, redirect_uri, and scope query parameters as appropriate, and add &prompt=consent.
To answer a later question, Excel and Mail add-ins are different, and my answer only applies to Excel. For Outlook there's a different sample.

Answer 3

The documentation can be found at Enable single sign-on for Office Add-ins. There is also walk though for both ASP.NET and Node.js as well documentation on Troubleshooting.
There are a number of things that could be going wrong here but without knowing more about your registration it is difficult to determine. That said, here are a couple of common mistakes:
You'll need to make sure you receive Admin Consent for the tenant you're developing against. This is only a dev requirement and won't be required once your publish to the Store.
Make sure you've pre-authorized the correct applications. You'll need pre-authorizations for:
d3590ed6-52b3-4102-aeff-aad2292ab01c (Microsoft Office)
57fb890c-0dab-4253-a5e0-7188c88b2bb4 (Office Online)
bc59ab01-8403-45c6-8796-ac3ef710b3e3 (Office Online)
Make sure the scopes you're defining in your manifest.xml are reflected in the app registration at apps.dev.microsoft.com.
If you make changes to your permission scopes, you need to make sure you repeat the Admin Consent process. When you receive consent, they are consenting to the scopes that were registered at the time of consent rather than the App ID itself.