search

OfficeDev / office-js

A repo and NPM package for Office.js, corresponding to a copy of what gets published to the official "evergreen" Office.js CDN, at https://appsforoffice.microsoft.com/lib/1/hosted/office.js.
https://learn.microsoft.com/javascript/api/overview
Other
685 stars 95 forks source link

Custom Addin OAuth flow broken in Desktop/orginal WebView (EdgeHTML) #1354

Closed abegun closed 4 years ago

abegun commented 4 years ago

We have an addin for Word that is following the guidance here (w/out SSO) to authenticate with AAD or Google: https://docs.microsoft.com/en-us/office/dev/add-ins/develop/auth-with-office-dialog-api

The flow is working as expected in:

  1. Office on the Web (i.e. Chrome, EdgeHTML, Chromium Edge)
  2. Mac Word
  3. Windows Word w/ WebView2 (Word Beta Channel + WebView2 SDK)
  4. Windows Word w/ WebView (EdgeHTML) when the addin is using https://localhost

The flow breaks in Windows Word w/ WebView (EdgeHTML) when the addin/manifest is using our staging or production environments. After AAD Auth, the redirect back to our page fails (i.e. from our end, breakpoints in the index for the page never hit) and the WebView is torn down (at least an attached debugger disappears at that point). The dialog displays:

ADD-IN ERROR A problem occurred while trying to reach this add-in." is displayed.
[retry]

Expected Behavior

Desktop Word w/ WebView should work like other hosts :)

Current Behavior

See above.

Steps to Reproduce, or Live Example

  1. I'm pretty sure that this is a regression and that it did work before. Unfortunately we have internally been heavily using Mac and Office Online for our non localhost usage so I'm not sure exactly when it started behaving like this.

Context

This is a core blocker for most of our customers since:

  1. They use Windows and not Macs 2a. Word Online does not support all features of Word. For example, two column layouts are represented as one, tabs are stripped, etc. These are non-starter issues for many of our customer's documents 2b. The performance of some API operations we do with Word is painfully slow with Word Online (such as full OOXML replacement.)

Your Environment

Useful logs

Please let me know of any particular logs that can be useful or how to enable more verbose logging. In particular, if there is a way to have Word not tear down the WebView control so that the final logs can be captured that would be great.

Thanks for the the help! -andrew

abegun commented 4 years ago

thanks for the triage @Rick-Kirkham. @smaremanda please let me know how I can aid in investigation, or if there are things you'd like me to try on my end.

abegun commented 4 years ago

@smaremanda - any thoughts to share here?

smaremanda commented 4 years ago

@abegun - we are looking into this issue. We'll follow up here as well as via the email thread we have open with you.

abegun commented 4 years ago

@abegun - we are looking into this issue. We'll follow up here as well as via the email thread we have open with you.

thanks Sudheer!

abegun commented 4 years ago

I'm going to close this out :) ! After some investigation from Microsoft and some further digging on my side it looks like the Edge WebView control takes exception to 404 responses and will close the addin if that happens. In this particular case, for our deployed webapp (i.e. not running on localhost) we are using Azure CDN to serve the static webapp, which is in turn a SPA. Deep link access into our app (including the /callback URL from the OIDC provider) was returning a 404 with the error page of index.html so all continued to work in the browser (normally). I found some good issues on Stack Overflow and GitHub that have suggestions on doing a redirect instead of returning a 404 for this type of webapp deployment:

https://stackoverflow.com/questions/59072306/hosting-spa-with-static-website-option-on-azure-blob-storage-clean-urls-and-dee

https://github.com/MicrosoftDocs/azure-docs/issues/43257#issuecomment-580668444

Hope this helps anyone else who stumbles upon this.