[O365] Debugging Office add-ins

In my previous posts I wrote about creating an office add-in using the Yeoman generator and my first add-in using Yo Office. Now as long as everything just works, these samples are doable. But when things start to go wrong, you can lose quit some time finding your way in the wonderfull world of add-ins.

This post wil list some of the “crap, now what?” situations I encountered and how to solve them. It’s not said you’ll run into each of them, but maybe this will help a few (my future self included).

Debugging: debugging outside of OWA

I quickly ran into the problem where my add-in would function within Office 365 Mail (Outlook Web Access), but not when being ran out of context (just hitting https://localhost:8443 in the browser).

By default, the angular app is bootstrapped as part of the Office.js initialization (app.module.js line 19):

Now in my case, Office.js would crash on the following error:

And as a result, the bootstrap method of Angular is not called any more. This means your angular code is not attached to the UI and thus doesn’t do or display anything. To prevent this, I commented out both angular.bootstrap calls and instead used the ng-app directive to bind the Angular app to the container (index.html line 38):

This doesn’t fix the Office.js error, but it prevents it from blocking the bootstrapping. I’m not completely sure yet whether this is a perfect solution (which would raise the question why it’s not like this in the first place).

Debugging: response_type ‘token’

When I ran into this error:

I found out that it is caused by the wrong return URL configured in Azure AD. When you open up the “CONFIGURE” tab, it lists a reply URL down to the bottom. This URL needs to match the exact URL of your add-in, otherwise the above error pops up. Others have found that changing the ‘oauth2AllowImplicitFlow‘ parameter of the appmanifest can be of influence. Read more in this StackOverflow thread: http://stackoverflow.com/questions/29326918/adal-js-response-type-token-is-not-supported.

Important! When changing things on the Azure AD / server side of things, just F5-refreshing on the client-side doesn’t always cut it. To prevent cookies and caching from messing up things, I would recommend using an incognito instance of Chrome to test out new server side settings.

Debugging: no permission to access user information

Next error you might encounter:

This one is pretty informant; it states the application does not have permissions to access user information. To grant these permissions, head over to the Azure management portal. More details on how to grant permissions are in my other blog post.


If you’re using JavaScript to query online API’s, it won’t take long before you run into problems loading stuff that is located on another domain. For instance when you query an API endpoint that doesn’t live in the Office 365 space. This is due to the browsers same origin policy which protects you from malicious scripting by checking everything being loaded by scripts is coming from within the same origin domain.

That’s nice, but it becomes a problem when you actually want to get data from an endpoint that lives on a different domain than your website / add-in. For this, CORS is there to help. The use of CORS is simple, but you do need a source (webserver) that allows it. A good write-up on CORS and how you can use it can be found here.

Leave yours below!

Found some other gotcha’s that you’ve solved (or not)? Feel free to leave them in the comments below. I will try to update this blog post with any new information that might help others.