Guidance for use in Outlook about office-js-helpers

[elegault]

Thank you very much - I will get on all that!

[WrathOfZombies]

So the issue here is that your Azure AD application has been set to redirect the user to a registered redirect_url with the user's token. This is done for security reasons.

However in OfficeHelpers, for convenience, we auto set the redirect url to your current application's domain, in this case, https://mywebapp.azurewebsites.net. In order to solve this please copy the redirect_url as is and use the advanced config as:

// set the redirect url by providing the config object.
authenticator.endpoints.registerMicrosoftAuth('client id here', {
    redirectUrl: 'redirect url here'
});

As for your issues with the browser execution, I have already started work on a new variant of this where it should resolve the cross-origin frame issues. I have received some feedback and I am trying to rectify the code while remaining backwards compatible.

In the meantime you can try the beta version here: https://unpkg.com/@microsoft/[email protected]/dist/office.helpers.js

Please try it out and let me know..

[elegault]

Note that I have been using registerAzureADAuth, not registerMicrosoftAuth, as Exchange Online permissions cannot be set using the latter type of application AFAIK. I had tried using the redirectUrl parameter with registerAzureADAuth but it didn't work (perhaps because I also included the responseType: 'id_token' parameter and value, which I'm not sure is incorrect or not). Should I try again using registerAzureADAuth and just the redirectUrl parameter? Also, it's not clear to me what I should use as the url - the domain only or the add-in's page url? If it's not the add-in URL will it still try to redirect to the default page at the root?

[WrathOfZombies]

Let me break this down into multiple replies.

what I should use as the url

Please use a url that you'd want your users to be redirected to after login. This can be the default page at the root or a custom page saying authenticated. The only significance of this is that on AzureAD you're telling to send the user with the token back to this page and on the Add-in, we are waiting for this page to appear in the popup so that we can know when to close it automatically.

No matter what you decide, both the redirectUrl property and the redirectUrl set on Azure must match for a successful authentication.

Note that I have been using registerAzureADAuth, not registerMicrosoftAuth

Doesn't make a difference as all helpers registerXAuth use the same underlying code. So the overrides work consistently.

(perhaps because I also included the responseType: 'id_token' parameter and value, which I'm not sure is incorrect or not)

There's an active bug that I need to investigate (#54). Probably related to that.

Should I try again using registerAzureADAuth and just the redirectUrl parameter?

Yes please try that.