Hi, we’re using the Web3Auth Unity SDK (v7.0.2) and I’m trying to understand the expected behaviour around localhost and the allowlist on mainnet.
Our setup is a Unity WebGL build running on sapphire_mainnet. The project’s allowlist only contains our production domain, and we never added localhost. Despite that, when we build for WebGL and serve it locally from http://localhost, login works without any problem.
I’d expected it to be rejected, since the dashboard says only allowlisted origins can authenticate, and I’ve seen it mentioned that localhost whitelisting was disabled on mainnet networks for security reasons.
So I’m trying to confirm which is correct: is localhost meant to be blocked on sapphire_mainnet, and if so, why is our Unity WebGL build able to log in without it being on the allowlist?
Related question: the same seems to apply when running in the Unity Editor, where login also goes through a localhost redirect. Should the allowlist block logins from the Editor on mainnet as well, or is that flow expected to be exempt?
And indeed localhost is intentionally blocked on Web3Auth Sapphire Mainnet for security reasons and cannot be allowlisted. Local development is supposed to use Sapphire Devnet.
If your Unity WebGL build can still log in from localhost, likely explanations are:
It’s actually using a Devnet client ID.
The login flow you’re using isn’t hitting origin validation in the way you expect.
The app isn’t truly being served from localhost (e.g. tunnel/proxy).
An existing Web3Auth session is being restored.
The first thing I’d check is the runtime values for clientId, web3AuthNetwork, and window.location.origin
I double checked my implementation based on your suggestions, and on my side the client ID is definitely sapphire_mainnet, I can even see the logins appear on the dashboard. The origin of my localhosted WebGL build also reads http://localhost:8000.
I also tried it in a fresh browser, as well as incognito, and after clearing Unity’s PlayerPrefs; so I don’t think it’s a restored session either.
Out of curiosity I tried the same client ID and network with the v11 web SDK from localhost, and that one did get rejected as expected.
It seems like the Unity SDK is still using the v9 authentication, could that be the issue? And if so, is there anything I can do on the Unity side to fix this?