Enabling App Service Authentication causes word add-in to open in browser rather than in the task pane.

[LiamSolDev]

Note: This repo is only for questions related to its samples. If you have questions about how to use office.js or the Office developer platform, please post your question on https://stackoverflow.com. Tag your question with office-js or outlook-web-addins

Enabling App Service Authentication causes word add-in to open in browser rather than in the task pane.

At client request we have enabled the App Service Authentication (Classic), setting screenshot bellow.

Our application still runs within the online version of word with no issue however the desktop version of the app immediately attempts to open the word add-in in the browser for what I assume is authentication and shows nothing in the task pane.

Inspection of the task pane shows that no html is loaded before the authentication check

Is this something you have encountered before? or got a solution for?

Task Pane Working Online:

Task Pane On Desktop:

Browser Window Opened By Desktop Taskpane:

[lindalu-MSFT]

@davidchesnut Hi David, can you help triage this issue?

[davidchesnut]

Hi @LiamSolDev,

Depending on how you've modified the sample, you'll want to be sure you are using the dialog API for the UI, and not the task pane. See Authenticate and authorize with the Office dialog API for more info.

If that's not it, see if you can monitor the network traffic with something like Fiddler. See if there is a difference between the add-in loading online, versus on desktop. Sometimes you can get additional info about what might be getting confused before the page loads.

Hope this helps,
David

[LiamSolDev]

Hi David,

Thank you for you help.
I have re-installed the base sample and it works as expected and I am now trying to find differences between the sample and my current code base to find the issue.

I am trying to understand what the load order is for the solution so that I can find at what part this authentication is called and is opening in the browser.

I have re-added the functionality to the SSOAuth and SSOAuthES6 as these appeared to be loaded first but this has not been enough- is the authentication for the web app checked before this?

[Rick-Kirkham]

@LiamSolDev Your symptoms remind me of the first 2 paragraphs of this section in the docs: Specify domains you want to open in the add-in window. After reading that, I suggest that you use the Fiddler tool, as David suggested, to determine what domain the add-in is trying to open and add that domain to the <AppDomains> in the manifest. See also: AppDomain.

If that doesn't fix it, then some questions:

1. Where does the "App Service ... " screenshot come from? I assume it is somewhere on the Azure portal, but I'm not familiar with that page.
2. If you do not enable this service, does that fix the problem?
3. Using this article as a guide, Browsers used by Office Web Add-ins, what browser is being used when you run the add-in on desktop?
4. What is the default browser on the computer? Is it the same as the answer to 1?
5. When the add-in opens in a browser window, what browser is it? The default browser for the computer or the browser that is the answer to 1 (if they are different)?
6. If you have a Mac can you test on desktop Office for Mac? It might be informative to see if the problem happens there too.

[LiamSolDev]

Hi Rick,

I have some more information on this, it turns out some of my initial testing was in error.

No sample works with authentication turned on in the app service.
Will all implementations causing it to open in a new window.
Our client has been insistent that this authentication is turned on unless we can prove that it is impossible to do so.
Have you ever sucessfully deployed a word add-in with app service authentication turned on?
when looking with fiddler we are taken to the following domains for app service authentication.

To answer your other questions:

1. The App Service... Screenshot is from the authentication page for the app service that is hosting the word addin.

2. Disabling the authentication does resolve the issue- but the client has requested that this is enabled as they do not want public websites that can be accessed without a domain account. Is it correct that all word add-ins are sitting on publicly available web apps as this doesn't seem correct to me

3. Looking at the source I believe that the add-in is currently running in edge. However, when the app opens the new window it opens in my default browser of chrome

4. Chrome is my default browser

5. The add in opens a browser window on chrome. Chrome is my default browser.

6. I do not have access to a mac.

[Rick-Kirkham]

@LiamSolDev I can't find that "App Service ... " UI on my Authentication page. Different kinds of subscriptions in Azure can have variant UIs. Can you please give me the step-by-step procedure you use to get that UI on the screen?

[LiamSolDev]

Hi Rick, This is on the App Service that is hosting the application so that it is web accessible. I set up the app service with the following options: * Publish: Ensure Code is Selected * Runtime stack: Node 12 LTS * Operating System: Windows Though we have seen the same Authentication screen on both windows and linix. Once on the app service - select "Authentication (Classic)" and turn it on with either azure or Microsoft account validation.  Thank you.

…

________________________________ From: Rick Kirkham ***@***.***> Sent: 15 July 2021 19:18 To: OfficeDev/PnP-OfficeAddins ***@***.***> Cc: Liam Dick ***@***.***>; Mention ***@***.***> Subject: Re: [OfficeDev/PnP-OfficeAddins] Enabling App Service Authentication causes word add-in to open in browser rather than in the task pane. (#183) @LiamSolDev<https://github.com/LiamSolDev> I can't find that "App Service ... " UI on my Authentication page. Different kinds of subscriptions in Azure can have variant UIs. Can you please give me the step-by-step procedure you use to get that UI on the screen? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#183 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKWEHSDQXCEY7KDKRFJCMVDTX4RA3ANCNFSM47U5IVUQ>.

[Rick-Kirkham]

@LiamSolDev OK. I understand what you mean now. (I was thinking of "App Service" in a different sense.) I'll see if I can find someone who can help with this.

[LiamSolDev]

Hi Rick,

This is on a deployed app being hosted on an Azure App Service with the following settings.
Once the App Service is setup you can navigate to the Authentication services by doing the following navigation

From the Azure Portal, search at the top for "App Services" and select it.
In app services select the App Service that your work add in is currently deployed to.
From the opened app service look at the left hand side of the navigation.
The "Authentication Classic" is in this menu.
Once the Classic Authentication is open, turn on "App Service Authentication" and then select "Login with Azure Active Directory" and then hit save at the top.
The web app will now look for authentication when loading the web app into word.

Kind Regards,
Liam

[davidchesnut]

Hi Liam,

Checking with our team it looks like you can see this behavior (popping out into a separate browser) when your add-in gets a redirection to a domain that is neither a subdomain of your SourceLocation nor a domain listed under your AppDomains.

I also notice in your Fiddler trace the protocol is HTTP. You must use the HTTPS protocol for any auth scenarios.

Cheers,
David

[LiamSolDev]

Hi David,

One thing we had already tried was adding all the address from the fidler trace to the App domains section and this did not resolve the issue.

I am unsure why the trace is using HTTP? sorry I am inexperienced with fiddlr

[davidchesnut]

Hi @LiamSolDev,

Thanks for that screen shot as it is super helpful. You need to specify the protocol and port as well, for example https://login.windows.net:443. See https://docs.microsoft.com/office/dev/add-ins/reference/manifest/appdomain for full details on how to fill out the AppDomain. BTW: I'm not sure if you need all of those domains. If you get it working you should try backing some of those off one at a time (or perhaps check with Azure on which domains/subdomains are going to be used with app service authentication.) I suspect a few of those might just be from Office making calls, and not your add-in.

Hope this helps,
David

[LiamSolDev]

Hi David,

We tried adding the https and port but it made no difference.

Have you been able to get this working before?

Kind Regards,
Liam

[davidchesnut]

Hi @LiamSolDev,

I tried setting up a simple ASP.NET server just to try out the app service authentication with similar settings as yours. I tested just browsing to the home HTML page to see how it would act. It redirects to a login page.

I believe this may be what you are seeing.

1. Office requests the task pane's HTML page.
2. Azure sees this as an unauthenticated request and redirects to login.windows.net.
3. Office isn't expecting a redirect and opens the new browser window. And the login doesn't render properly.

You should be able to test this by opening a browser window and loading your task pane HTML page (or any other resource) using the URL. If you see the request redirect, that behavior will not work with Office. Logins (and redirects) need to always be handled through the dialog API. If you can't configure app service authentication to not redirect on some requests (like the HTML page) it's not going to work with Office add-ins.

Cheers,
David

[LiamSolDev]

Hi David,

Thank you and @Rick-Kirkham for all of your help so far :)

So to confirm do you believe that it is not possible to get this working within an office add-in or do you think it could be managed through the dialog API (not something I am familiar with), but since the redirect is happening before any code loads I am not confident that we could make use of any code based solution. I do not see any setting available to us to make the authentication page by page based as it is a whole solution issue.

I know that you and Rick have been heavily involved in the development of this and the development of the tutorials but we have been asked by our client to raise a ticket with Microsoft to confirm that turning this option on will not work before we proceed- I am unclear on this but do you work for Microsoft and do you know the best option to get in touch with Microsoft about this specific issue? We tried looking at the support within the Microsoft partner centre but this makes mention to an "Offer ID", "Offer Type" and "Offer Name" none of which we can fill in.

This is become a major blocker for a development we have invested a lot of time on and we can only move forward by either resolving the issue or proving with contact from Microsoft (clients request) that it is not possible- any assistance you provide will be greatly appreciated.

[davidchesnut]

Hi @LiamSolDev,

Kind of a lot to try to answer here. :-) Yes Ricky and I work for Microsoft on the Office Add-ins team doing docs, samples, tutorials, and working with the rest of the engineering team. You're reaching out to a good source. I've been consulting with the engineering team as we go along.

1. If you can reach out to CSS they can provide good help on your auth scenario. They'll know more about Azure then we do. We're very knowledgeable on the Office side of auth, but our team can't research all the variables and configurations that are possible in Azure.
2. I encourage you to do another Fiddler trace for domains. When I was trying out Azure app service auth, I noticed https://login.microsoftonline.com/ was one of the domains in addition to the others. If you are missing even one, you'll see the popout behavior.
3. Can you use SSO with Azure app service? No. Because Azure app service will auth on the very first request for the task pane, you won't have a chance to call getAccessToken first. Your JS is not even loaded yet. Therefore the user will get logged in a second time.
4. Can you use auth without SSO? In general this works. You can have the task pane redirect to a login page and get this to work on load. Basically Office is just loading a WebView (IE, Edge, WebView2 depending on Office version). WebView can handle the redirects and login pages. It would only fail if the Azure flow was attempting something unexpected. And that's where you'd need help from CSS or the Azure Active Directory team.

Hope this helps,
David

[LiamSolDev]

Hi David,

Thank you again for all your assistance.
Thanks to your feedback, we have now stopped the authentication from popping out to a new window.

Is there anywhere I can go to write a review or give you a +1 :) You two deserve it!

Time to get back to programming rather than bug fixing- thank you for all your support.

[AlexJerabek]

Hi @LiamSolDev,
Thanks for the kind words about @davidchesnut and @Rick-Kirkham. Glad they could help unblock you and let you get back to the fun part of the job.