Azure Static Web Apps, with Authentication, WASM fails

[mikeirvingweb]

Current behavior

If you deploy to Azure Static Web Apps (a working Uno Platform WASM app)

then turn on basic "Password protection" authentication ("Standard" hosting required)

then reload your app (maybe open an Incognito / Private window, for a fully fresh experience)

you will get the Azure login screen

Enter your password, hit Submit

The page starts to load, but hangs.

Open the Dev Tools (F12) and Refresh the page to see what's going on.

In the console. Lots of errors

and in the Network Tab, you will se that lots of the files in the package_ ... folder get issued a 302 redirect back to the authorisation page.

If you request one of these files in a Fresh browser tab, it works

This is because the fresh request can see the Auth cookie.

But the Framed / Embedded request cannot.

Here is the Azure Static Web Apps Cookie - see Application Tab in Developer Tools

This seems like a Browser security issue see: https://stackoverflow.com/questions/68788202/page-within-iframe-not-seeing-its-own-cookies

--

I have tried various settings in my staticwebapp.config.json file to try to alleviate this, namely:

• trying to set some content as "allowedRoles": "authenticated", some as "allowedRoles": "anonymous"
• adding various CSP and CORS headers

to no resolution.

--

it would appear, given the browser security settings, this would happen on other web hosting services that are looking for a cookie too.

Any suggestions?

Expected behavior

a WASM deployed app would work, behind authentication

How to reproduce it (as minimally and precisely as possible)

No response

Workaround

No response

Works on UWP/WinUI

Yes

Environment

No response

NuGet package version(s)

No response

Affected platforms

WebAssembly

IDE

No response

IDE version

No response

Relevant plugins

No response

Anything else we need to know?

No response

[mikeirvingweb]

p.s. I feel this would happen behind any form of authentication that is failing due to cookie access.

[jeromelaban]

Thanks for the report. It is likely that the .NET runtime is not propagating the required cookies for authentication to work properly.

We're using this:

https://github.com/unoplatform/Uno.Wasm.Bootstrap/blob/6ee09b0df97780d5ca8f9ff22e04c39d502978c6/src/Uno.Wasm.Bootstrap/ts/Uno/WebAssembly/Bootstrapper.ts#L570

to fetch the runtime's assets, but it may not be enough to get everything through.