[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):
// when Office has initalized, manually bootstrap the app if (location.href.indexOf('access_token=') < 0) { // when Office has initalized, manually bootstrap the app Office.initialize = function () { console.log('>>> Office.initialize()'); angular.bootstrap(document.getElementById('container'), ['officeAddin']); }; } else { angular.bootstrap(document.getElementById('container'), ['officeAddin']); }
Now in my case, Office.js would crash on the following error:
Uncaught TypeError: window.external.GetContext is not a function
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):
<div id="container" ng-app="officeAddin"> <div data-ng-view></div> </div>
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:
response_type 'token' is not enabled for the application
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:
No permission to access user information is configured for '1ac648a8-34ad-4313-a4a6-0ddf41006f85' application, or it is expired or revoked.
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.
CORS
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.
November 17, 2015 at 11:04 am |
[…] Enter the URL to your application. You can change these later on so during debugging just use ‘https://localhost:8443/appcompose/index.html’ provided you didn’t change it to a different port or URL. It’s important that the URL matches the one that Azure AD will redirect the user to, including /appcompose/index.html. I found that you can get errors otherwise (see debugging post). […]
November 19, 2015 at 8:08 pm |
[…] Debugging Office Add-ins […]
December 31, 2015 at 6:30 am |
[…] Debugging Office Add-ins […]
January 2, 2016 at 6:46 am |
[…] Debugging Office Add-ins […]