Business user flow: Office Online does not load properly after user sign-in when third-party cookies are disabled

[tylerbutler]

As part of the business user flow, users will be asked to sign in using their Office 365 credentials. After sign-in, they will be re-directed to the HostEditUrl. However, if third-party cookies are disabled, the Office Online application will fail to load because the authentication cookie needed to verify the user has signed in successfully with O365 is not sent along with the Office Online iframe request.

Users must either allow third-party cookies or add *.officeapps.live.com to their browsers cookie allow list.

Note that in some browsers, like Safari, third-party cookies are disabled by default.

In addition, browsers like Internet Explorer have a concept of 'zones' which can change how cookies are handled (among other things). Ensure all the sites in question are in the internet zone.

[mschering]

Just stumbled on this issue while using Safari. Ending up in a infinite reload loop. Would be nice if this was fixed!

[theTechie]

I agree @mschering. We cannot tell our customers to allow third party cookies.

[srikanthnd]

@tylerbutler is there a date to fix this issue? Because as per this link : https://docs.microsoft.com/en-us/azure/active-directory/develop/reference-third-party-cookies-spas even Chrome and other browsers based on the chromium will stop supporting third-party cookies:

"Safari isn't alone in blocking third-party cookies to enhance user privacy. Brave has blocked third-party cookies by default, and Chromium (the platform behind Google Chrome and Microsoft Edge) has announced that they as well will stop supporting third-party cookies in the future."

[naugtur]

Hi, one of the early WOPI implementers here. I'm considering an experiment with opening editing in new tab instead of iframing it, because the fix is not easy.
We have our own embeddable experience for integrations and I've been leading the work to add support for when cookies are off. That involves keeping a token in memory in JS and fiddling with its lifespan to make it as short as possible and pinning it to IP or TLS session in case it gets stolen via XSS. That makes it almost as secure as a cookie.
That's not all though.
You need to get the token into JS memory, for which you have 2 choices:

1. get the user to log in each time they open up your experience
2. use cookies anyway, for which you must then pop up a top level browser window to read cookie and pass the token back to the iframe via postmessage.

1 is actually reasonable for Office, because it uses the userinfo action and once the user logs in, they're persisted in the WOPI server. I'd go that route if I were MSFT
Option 2 is phishing waiting to happen

This is a hard problem and as much as I like privacy improvements, I think Firefox is the only browser that did it right - they block cookies selectively, not based on just the fact that they're being used in an iframe.

[ICISJ]

@tylerbutler Word for the web is not working on MAC book Safari browser latest versions.
Can you please provide a resolution to get this working. It is very critical for adoption of WOPI feature for our customers.

PFA screenshots for your reference.

[ndench]

Any chance this issue is being looked at? Most browsers are moving towards blocking third-party cookies by default, which will make adoption of any WOPI integration impossible.

[TomasMatusek]

This seems to be a problem for newer browsers that by default dont allow third party cookies.

[dgordoncal]

Also experiencing this issue and it's now critical.

[v-stsier]

Hello all,

Apologies for the long delay in answering from our end.

As indicated by Tyler earlier in this thread, WOPI does require cookies to function correctly. Unfortunately, as of today there is only the workaround of enabling third party cookies in the user's browser in order to complete the WOPI business flow.

We understand that with Safari's default behavior of blocking third party cookies this is affecting more users than ever. We also know that in some user environments third party cookies are not an option.

This issue is currently receiving significant attention and prioritization in our engineering team. At this time we do not have an ETA for a solution to the problem and the workaround is the only way to enable the scenario. This thread will be updated when we have more information for you.

Stefan

[naugtur]

@v-stsier I've done research and recommended workarounds for this issue on other apps in Egnyte. Between my experience in WOPI and browser quirks I think I have a few ideas how to solve it. Feel free to reach out and I can help either as part of existing cooperation between MS and Egnyte or independently.

[TomasMatusek]

I think this is becoming a bigger and bigger problem as all major browsers are migrating to the policy of not allowing 3rd party cookies by default. Is there any workaround ?

[naugtur]

@TomasMatusek wasn't it fixed a few months ago?

[john-yick]

@naugtur I can confirm that the issue still exists for WOPI links that are opened in an iframe for the latest iOS and MacOs Safari. When the iFrame fails to load no errors are shown all I see is a white area.

[RobRol]

@john-yick can you check if there is already a # on the iFrame URI we're trying to load?

[john-yick]

@RobRol So I figured it out, yes there was a hash in the URL but the main issue with ios seemed to be that it didn't like the window.open() to be called within an async method. Changing the code to this made it work on ios:

        const windowReference = window.open()

        this.$store.dispatch('openDocumentPreview', { self: this, document: this.documentDetails }).then(wopiUrl => {
            windowReference.location = wopiUrl
        })

[RobRol]

@john-yick - Thanks for sharing the mitigation you discovered. Hopefully this will end up helping others in the future too, instead of being an instance of this:

[DorofeevMark]

@RobRol Hello Rob, could you please provide an example of hash usage in URL? It's not really clear where to put it. I'm not able to find any mentions of this in the docs and 3rd party cookies problem still exists for me

[Renkas]

Isn't the solution to set the cookie as SameSite=None; Secure? Set-Cookie: flavor=choco; SameSite=None; Secure
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite

Or am I missing something here?
This issue really needs a solution as it makes it impossible to use our WOPI integration ...
Almost 7 years without a solution is kind of too long.

[RobRol]

@DorofeevMark - Sorry, I missed this when you sent it like 4 months ago. What I'm about to explain is my understanding of the problem, it is possible it isn't 100% correct. This isn't a space I work in.

Typically, there should not be a # in a WOPI URL. The problem is that a # represents the boundary where a fragment should be present. The problem seems to arise when certain webservers or frameworks introduce a # as part of the path to the resource itself, which then becomes part of the WopiSrc.

The authentication redirect flow may add query parameters in a strange spot when that occurs. The spot it adds the query parameter would be before the #. This seems to be the correct space to add them based on how a URI is structured, but for those specific scenarios it causes the WOPI src to get mangled and thus interferes with the rest of the flow.

I've never tested it, but in those specific scenarios, it may be possible to mitigate the issue by URL encoding the # as a %23. Again, it's untested, so I don't know if that will work, but it would be the first thing I'd recommend the host implementing the WOPI protocol tries.

@Renkas - I had thought that this issue was fixed a while back. The primary offending browser with Safari. Are you still seeing a problem first-hand? I am not an admin of this GitHub community, so I can't close the ticket.

Regardless, it isn't about adding the SameSite=none cookie attribute. That field controls how 3rd party cookies get routed for browsers that accept 3rd party cookies at all. Some browsers just outright reject them.

I don't own a Mac, but I had a friend try the app on their Macbook Pro back in March 2021, and it was working. This indicates that the auth flow was fixed... at least at that time.

[Renkas]

In our tests Safari will stay in a redirect loop.

[RobRol]

@Renkas - Do you have any browser plug-ins? What version of Safari? What version of Mac OS? Are you on an Intel Mac or an Apple Silicon one?

Also, are you implementing a new WOPI host as part of the CSPP program, or are you trying to leverage an existing one?

[Renkas]

It does not matter which version. It has been happening for atleast over a year. Maybe even two. From the first time we implemented WOPI.

I tested right now on 2 different Mac's: Intel and M1
Both have same OS/Safari versions:
Safari Version 15.4
Os X: 12.3.1

And I verified that when I allow cross-site tracking in the preferences then redirect loop ends and Office can be used. But that's not a solution. We can't start telling our customers to compromise their privacy just to get editing in Office working.

[RobRol]

@Renkas - That's helpful. I can forward it to the team that works in this area. Which WOPI host are you using when you run into this problem? It'll help in their validation to use the same one.

[Renkas]

https://my.folderit.com is the domain if that's what you mean.

You can also register for free and have the functionality available for testing for 30 days.

[ArjunGovaniTR]

@Renkas

i am getting below error in console while its reloading loops in safari browser
if anyone can help

Blocked a frame with origin "https://testSite.test.com" from accessing a frame with origin "https://ffc-word-edit.officeapps.live.com". Protocols, domains, and ports must match.

and when I allow cross-site tracking in the preferences then redirect loop ends and its working fine

[Denver-LawVu]

This is also an issue for us, endless looping when cross-site cookies are disabled. At the moment most of our customers are using Chrome and have cross-site cookies enabled by default but I'm anticipating this causing more issues for us in the near future. Is there a plan to solve this in a way that doesn't require users adjusting their security settings?