XmlHttpRequest in event-based activation in 2402+ fails with "[0x80070057] No valid origin in response" about office-js

[barclayadam]

@JunielKatarn We use ASP.NET built-in CORS middleware which I'm pretty sure does an exact match on the inbound origin, and when you configure it the configuration will always strip the forward slash. In other words, the Origin header containing a forward slash means it would never work without deep modifications or replacement.

All other Outlook clients, including older Win32 versions, have been correctly not including the forward slash in requests (presumably because the browser is responsible)

In RFC 6454 we have:

Return the triple (uri-scheme, uri-host, uri-port)
Two origins are "the same" if, and only if, they are identical.

[JunielKatarn]

Thanks for the thorough answer.
This will help us write the necessary tests to prevent regressions.

Regarding the fix, it's trivial one.
It should be available on the fast release channels early next week.

[JunielKatarn]

Starting investigation.

The message suggests mismatched values in the Access-Control-Allow-Origin header.
See https://github.com/microsoft/react-native-windows/blob/cb71c1663dc2503a281444ca12be4f8fbf344b43/vnext/Shared/Networking/OriginPolicyHttpFilter.cpp#L471

[barclayadam]

For added context our add-in continues to work in the task pane of Win32, plus OWA. Our CORS configuration has not changed, and I can see from OWA that we do indeed return the correct headers for well-formed requests:

I've wanted to debug a request from Win32 Outlook but cannot get any requests being made by event-based activation to flow through Fiddler locally to capture. Perhaps there is some documentation for proxying this traffic for inspection?

[barclayadam]

Further still, I think it's possible that there is a subtle difference in the Origin that is being sent by event-based activation, in that I think it may now contain an extra forward slash:

https://outlook.signature365.com

vs

https://outlook.signature365.com/

Our check on the origin value is strict, which I believe is therefore causing this issue. It appears the change in Outlook may be the additional slash when sending Origin header

[barclayadam]

Based on the definition at https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin I think the additional forward slash is not correct, given the definition of:

Origin: null
Origin: <scheme>://<hostname>
Origin: <scheme>://<hostname>:<port>

[JunielKatarn]

@barclayadam I will verify whether the trailing slash should be ignored in the origin comparison or not, according to the Origin Policy spec.

Can you please elaborate on the steps to reproduce?
I installed the add-in via its XML manifest but don't understand how to make the actual requests as described in the steps.

[barclayadam]

Our add-in when installed will attempt to make a call to our id.signature365.com domain whenever you create a new email, or if you opened the task pane.

I have worked around the problem on the server-side now though, so the issue should no longer be present using our add-in.

[JunielKatarn]

@barclayadam can you elaborate on the workaround you implemented?

The specific error message happens specifically when the allowed origin value is not set:

  if (allowedOrigin.empty() || !IsSameOrigin(origin, Uri{allowedOrigin})) {
    hstring errorMessage;
    if (allowedOrigin.empty())
      errorMessage = L"No valid origin in response";

[JunielKatarn]

@barclayadam
Can you please confirm the following about the bug behavior?

1. Event-based activation sends an Origin header with a trailing slash (i.e. https://outlook.signature365.com/).
2. Your server endpoint rejects this request header and does not provide the Access-Control-Allow-Origin response header.
3. The Outlook client does not find the allow origin header in the response and fails.

[barclayadam]

@JunielKatarn

On our server we used to set an allowed origin as https://outlook.signature365.com, which did not work for these Outlook versions because it was not an exact match against the header being sent, which was https://outlook.signature365.com/ (note the final forward slash).

Therefore we had to add an additional origin of https://outlook.signature365.com/ to make this work.

We were lucky because this specific part was not handled by the built-in .NET CORS middleware (https://learn.microsoft.com/en-us/aspnet/core/security/cors?view=aspnetcore-8.0) but instead one from IdentityServer4. If we were to have been using the built-in CORS middleware this workaround would not have worked from my understanding, because if I was to configure it to allow https://outlook.signature365.com/ it would still only match against https://outlook.signature365.com.

Your flow is correct in your last comment. Trailing slash is present in the Origin header, that is not an allowed endpoint and therefore no response header, which leads to Outlook rejecting the response.

For reference a couple of snippets below are from the built-in .NET CORS middleware that shows it will not handle forward slashes by default:

When adding an allowed origin:

https://github.com/dotnet/aspnetcore/blob/7874b36fd8da2f8e56b23aac48954f14bafba1fe/src/Middleware/CORS/src/Infrastructure/CorsPolicyBuilder.cs#L60

var normalizedOrigin = GetNormalizedOrigin(origin);
_policy.Origins.Add(normalizedOrigin);

The normalised URI is used, which will not include the path (extra forward slash):

https://github.com/dotnet/aspnetcore/blob/7874b36fd8da2f8e56b23aac48954f14bafba1fe/src/Middleware/CORS/src/Infrastructure/CorsPolicyBuilder.cs#L86

return builder.Uri.GetComponents(UriComponents.SchemeAndServer, UriFormat.Unescaped);

When checking an exact match against origin is used:

https://github.com/dotnet/aspnetcore/blob/7874b36fd8da2f8e56b23aac48954f14bafba1fe/src/Middleware/CORS/src/Infrastructure/CorsPolicy.cs#L175

return Origins.Contains(origin, StringComparer.Ordinal);

[JunielKatarn]

Fixed and deployed to Office starting version 16.0.17505.15020.