Embedded wallet (Web3Auth) login does not work with wildcard subdomains whitelisted even though it says they should work in the docs

Embedded Wallets (Web3Auth)
, , ,
1

Platform or framework:

React, iOS, Android - Affects all devices, as it pertains to domains whitelisting behavior.

Which Web3Auth/ Embedded Wallet SDK (SDK Name and version) are you using?

Only dependency is @web3auth/base on latest (v9), as it enables implementations of custom adapters without the vendored modal. When the whitelist is working, everything is great and functions as expected.

What is not working as expected?

The current embedded wallet (Web3Auth) docs say that a wildcard subdomain of the form https://*.myapp.com can be whitelisted and used normally. Our has tried to use wildcards on multiple projects and their seems to be product and docs mismatch.

Code snippets: Include the portion of your code that is causing problems..

(not code related)

Exact error and logs: Copy any error messages or console logs.

There seems to be some bug in the code. Please contact support to fix this.
could not validate redirect, please whitelist your domain: https://1051.gh-pr.sai.fun for provided clientId …

However, I for sure have this whitelisted in the project as https://*.gh-pr.sai.fun for our org ( MetaMask Developers ).

For now what I’m gonna try to do, because it seems like an unanswered problem, is explore the solution in the GitHub discussion from years ago that discusses programmatically updating the whitelist server-side before the wildcard subdomain gets generated. I’ll see if that works and I’ll document the findings here in the forum thread to potentially solve the problem for other developers.

2

Thanks — I’m on the MetaMask & Web3Auth team. This is an error (wildcard whitelist not behaving as docs state). You’ve already given the key details (Embedded Wallets via @web3auth/base v9 on React/iOS/Android) so here’s a short checklist and next steps:

  1. Quick checks you can try now
  • Confirm the wildcard is entered exactly as an origin in the dashboard (no trailing slash): https://*.gh-pr.sai.fun and that it appears under your Nibiru project’s allowed origins.
  • Temporarily add the exact failing origin (https://1051.gh-pr.sai.fun). If that fixes the error, the backend is doing exact-match validation and not honoring the wildcard.
  • Ensure the redirect origin your client sends matches the origin in the whitelist (protocol + hostname). Embedded redirect validation is strict.
  1. Workarounds
  • Programmatically register the full preview hostname before starting auth (the GitHub discussion approach you referenced).
  • Or route auth through a stable domain you control and handle redirects internally.
  1. What I’ll do for you
    This looks like either a product limitation or a bug in wildcard handling. I can escalate this to the product/engineering team to confirm expected behavior and update docs. If you want me to escalate, please confirm you want us to proceed and share:
  • Project/org (I see Nibiru) — confirm that’s correct
  • One failing example URL (e.g. https://1051.gh-pr.sai.fun)
    (You don’t need to share clientId here; keep that private.)

If you prefer, continue with your programmatic whitelist approach and post results — that’s the recommended workaround for ephemeral preview hosts. Would you like me to open an internal ticket now?

Note: This response was generated by an AI bot and may require further verification. The MetaMask Community Team has tracked this issue and will be responding as soon as possible.

Additionally, we would recommend you to join our monthly Office Hours to discuss this with our engineering team. MetaMask Developer Office Hours

3

Confirming that, yes, manually adding the failing URL to the whitelist works perfectly and the authentication goes through as expected. It’s definitely the wildcard usage that’s being messed up here.

What I’ll do for you
This looks like either a product limitation or a bug in wildcard handling. I can escalate this to the product/engineering team to confirm expected behavior and update docs. If you want me to escalate, please confirm you want us to proceed and share:

Yes, please escalate to get that corrected either in the docs or in the backend if possible.

4

@system I am following guidelines here to enable whitelist management via POST.

It says to send Web3Auth the WEB3AUTH_PARTNER_PUBLIC_ADDRESS, which is “0x8606ad34E12D3744e61c5573EA927963C1E7cCbc” for us on this organization: MetaMask Developers .

Can you please grant this public address access to our Nibiru / Sai
Embedded Wallets dashboard project so we can use the whitelist endpoints?
Needed endpoints:

  • GET /partner/organizations
  • GET /partner/projects
  • GET /partner/projects/{projectId}/whitelists
  • POST /partner/projects/{projectId}/whitelists
  • optional: DELETE /partner/projects/{projectId}/whitelists
    Use case: exact-origin allowlisting for deterministic PR preview domains
5

Hi thanks for sharing all the details let me please notify someone from the team

6

Hey @UniqueDivine

Wildcard allow listing is not available on metamask dashboard, I don’t think the docs do specify that, if yes let me know I will make sure to fix that. Allowlist officially only works on per URL basis.

If you want to programatically allowlist domains, you can use your client secret to do it. The method is mentioned in this thread: [Archive] Register whitelist url using web3auth sdk

7

The docs that need to be fixed are here: Allowlist settings | MetaMask developer documentation, @yashovardhan

image
image870×631 25 KB

8

I also implemented a solution for producing the origin data needed to use embedded wallets on these custom subdomains using a cryptography signature with the client ID and client secret. I describe that here and I added that as a reply on the original discussion on this topic as well.

Web3Auth v9 accepts a signed origin map through AuthAdapter.

Feel free to recommend this as a solution for others. It’s working in production.

cc: @yashovardhan @shana