Office-js: Task Pane add-in shows 'disabled to keep you safe' starting October 15th 2020 in OWA (Exchange back-end)

[westconference]

Our add-in that launches a task-pane started failing in OWA for Exchange 2016 on October 15th 2020. Instead of loading the expected page the add-in displays a message:

• "This add-in has been disabled to keep you safe. To continue using the add-in validate that this item is hosted in a trusted domain or open it in the Office desktop app".

There is a 'continue' button however clicking simply shows 'sorry we can't continue'.

Note appears to still be working fine in Outlook desktop client just OWA has this issue.

Expected Behavior

Task pane should load expected add-in page.

Current Behavior

Task pane shows failure message that add-in has been disabled to keep user safe.

Steps to Reproduce, or Live Example

• Use an Exchange 2016 server backend.
• Happening across Edge and Chrome so either browser should be fine.
• Login to OWA and install an add-in from a file. Add-in should launch a task pane via a button.
• Trigger task pane, observe that error message is displayed. Nothing relevant logged in console.

Context

Breaks functionality of our add-in for Exchange users. Raises questions over why our add-in is not safe according to Microsoft from customers.

Your Environment

• Platform [PC desktop, Mac, iOS, Office on the web]: Outlook on the Web.
• Host [Excel, Word, PowerPoint, etc.]: Outlook
• Office version number: N/A
• Operating System: Windows 10
• Browser (if using Office on the web): Edge and Chrome both demonstrate this.

Not aware of any recent updates applied to the Exchange server.

Useful logs

[LokiMidgard]

Same here.

Using the old Edge the Add-In however shows a dialog asking if the domain of the Add-In is trusted.

In chromium based browsers or firefox this confirmation dialog is supressed because the iFrame does not have allow-modals set. So you can't enable the add-in again.

Manipulating the response with an proxy like fiddler adding the missing allow-modals will result in showing the confirmation dialog and make the add-in usable again. Of course that's not a valid workaround for customers.

I also crated a stack overflow entry

[exextoc]

Please update to the latest SU that was released on October 13, 2020. It has the code changes required for add-ins to work.

[westconference]

Updated to CU18 and applied the security update from October 13th. That causes Chromium based browsers to now show the 'do you trust the domain' message which we would prefer users not have to encounter but does seem to store their selection for future across browser restarts.

@exextoc Is there a way for admins to remotely configure a domain as trusted here so user doesn't have to make the decision?

Also what's the best way to keep aware of changes like this being pushed out so we can know to check for breakages in future? Is the need to update Exchange to have that security update for add-in to work recorded on release notes somewhere?

[LokiMidgard]

I agree with @westconference our non tech users propably don't even know what a domain is. The domain the add-in runs on may also be a domain the user had never seen, especially if the admin provided the Add-In, So either they press cancel and do not use a maybe required add-in. Or even worse they lern if something asks you Do you trust me just click OK and everything will be fine.

Oh and there is a third case, every user starts calling the IT department. Also probably not desirable.

So a way for the admin to take this dessision from the user should exists.

---

And the second thing I don't think is a good idea that there are only two days between the update was released and everything broke because the exchage was not up to date. In an ideal world you could just hit the update button as soon as the update is available. But the past has shown that more then once this does not work. And breaking an critical infrastructure as an Mail server is a no go.

At least in the past most of our customers did not have the latest updates installed on day one. And I assume they won't blame there IT department for not updating there exchange but us because our plugin no longer function.

[neville-jones]

This breaking change was severe for our Outlook add-in which uses the on-send event because the end-user was not shown any error information. They only knew something was wrong because the message was never sent and they could not create a new message or open another message for reading; they were only shown a notification in the message UI header area that " is working on your request".

If the add-in was regarded as sufficiently trustworthy to be centrally installed by an administrator then end-users should not have to make a second decision about its trustworthiness, especially when, as @LokiMidgard says, the majority of users would be unable to make a knowledgeable decision about trustworthiness.

Problem also observed in Exchange 2013 (in the task pane of our add-in, where the "add-in has been disabled" warning was shown).

[kratikal-sarthak]

I am getting the same error but i am using Exchange On prem 2013 and i have updated the Exchange 2013 server to CU23, but still i am getting the same error.

[neville-jones]

I am getting the same error but i am using Exchange On prem 2013 and i have updated the Exchange 2013 server to CU23, but still i am getting the same error.

you also need this Security Update - https://www.microsoft.com/en-us/download/details.aspx?id=102164

[kratikal-sarthak]

@neville-jones The Security Updated you provided is CU23 and we have already done that , but still we are facing the same issue.

[exextoc]

The update was provided to improve the security around Office add-ins. we recommends that you update to the latest October SU to stop the add-ins from breaking. Once the SU is done, users will see a one-time prompt asking them whether they trust the domain on which the add-in is hosted. This is as per design.

[neville-jones]

@neville-jones The Security Updated you provided is CU23 and we have already done that , but still we are facing the same issue.

@kratikal-sarthak The link is to a Security Update that is on top of Exchange 2013 CU23; e.g. size is 78.4 MB and was released 12 Oct 2020

[roqz]

Any updates on this issue?

Further Question @exextoc : Is there any chance to change the selection a user made when the one-time prompt first appeared? A lot of users clicked on cancel and therefore now there are limitations for them (for example Links within the app that open a browser window no longer work/do nothing, whereas it still works for users that clicked ok on the popup)

[kratikal-archit]

The update was provided to improve the security around Office add-ins. we recommends that you update to the latest October SU to stop the add-ins from breaking. Once the SU is done, users will see a one-time prompt asking them whether they trust the domain on which the add-in is hosted. This is as per design.

@exextoc as you said, we updated with latest October SU, it started to work fine on Internet Explorer and Edge browsers, but Chrome is still not showing one-time prompt. I went more into the problem and found that outlook is using iframe to load our add-in and outlook needs to have allow-modals tag in sandbox attribute of iframe. In absence of this tag, chrome is blocking one-time prompt. Is there any other we can fix this?

Demo of the problem is visualised on this website- Link

[exextoc]

@kratikal-archit
Chrome must have cached version of OWA. Please try clearing cache and cookies and try reloading OWA.
If it shows for IE and edge, it means the update has reached to you, chrome should also work.

[raymondnexsoftech]

Hi all,
Any update on this?
The 'do you trust the domain' popup makes my client confuse.

[exextoc]

@raymondnexsoftech
Refer to earlier comment on 20th Oct: Link