[Bug]: MetaMask signature request immediately appears and then disappears depending on the content of the signature request's message

[oconnorjoseph]

Describe the bug

This issue only occurs in v10.26 and not in v10.25.0 or earlier. It occurs in both Chrome v111 and the latest version of Brave.

When sending a signature request to MetaMask, the following message will cause the MetaMask Notification popup for the signature request to appear for <1s and immediately disappear: The MetaMask Notifiation popup loads only displaying the MetaMask logo before immediately crashing.

Modifying this message very slightly by either removing the newline character after the first ':' (as seen in the image below) or removing the first ':' does not produce this error. The MetaMask Notification popups appears as expected for the signature request.

Steps to reproduce

1. Request a signature of the form

   
   blumint.com wants you to sign in with your Ethereum account:
   0xa6b691ff5fbDd3A79011899709fB21d3d63cAA27

URI: https://blumint.com/ Version: 1 Chain ID: 1 Nonce: vzIdleYcNrqDJ5JSw Issued At: 2023-03-20T15:53:22.173Z Expiration Time: 2023-03-20T16:08:21.892Z Not Before: 2023-03-20T15:53:21.892Z

### Error messages or log output

```shell
No error message or log output is produced.

Version

v10.26.1

Build type

None

Browser

Chrome, Brave

Operating system

Windows, MacOS

Hardware wallet

No response

Additional context

No response

[danjm]

@oconnorjoseph can you share the code you used to construct the request?

[danjm]

actually, it's okay, I can repro

1. go to https://www.blumint.com/
2. sign in
3. in the console enter window.ethereum.request({"method":"personal_sign","params":["0x00000000219ab540356cBB839Cbe05303d7705Fa", "blumint.com wants you to sign in with your Ethereum account:\0x00000000219ab540356cBB839Cbe05303d7705Fa\n\nI accept the MetaMask Terms of Service: https://community.metamask.io/tos\n\nURI: https://bluemint.com/\nVersion: 1\nChain ID: 1\nNonce: 32891757\nIssued At: 2023-03-20T15:53:22.173Z"],"id":1}) (replacing the address with the address of the account you connected)

And, as reported, removing the first \n in the second param prevents the error

Also, when the error occurs, I can see the following in the metamask background ​ SES_UNHANDLED_REJECTION: Error: SIWE domain is not valid: "www.blumint.com" !== "blumint.com"

[danjm]

@oconnorjoseph The problem here is a domain mismatch. We are going to partially improve on this in v10.26.2, but the origin of your site is www.blumint.com while the origin in your message is blumint.com. Correct the latter and these types of message signatures will work again.

[atjeff]

@danjm - is checking new URL().host the proper check here? For localhost it is causing mismatches, as localhost:3000 is not the domain localhost.

https://github.com/MetaMask/metamask-extension/blob/a04fa20f96a09461abfcb9a3b8b4db1f20cca2b8/ui/components/app/signature-request-siwe/signature-request-siwe.stories.js#L25

I see in your tests you also allow domain to contain a port, however providers may not. Would new URL().hostname be the better check?

Similar discussion here with Moralis:

https://forum.moralis.io/t/authentication-api-after-metamask-10-26-1-update/22877/5

[bschorchit]

Might be addressed with: https://github.com/MetaMask/metamask-extension/pull/18296

[badalmeta1]

For me I needed to do JSON.stringify the typeData and this issue resolve in the v10.26 and above

[digiwand]

This issue was fixed with the v10.26.2 hotfix https://github.com/MetaMask/metamask-extension/pull/18200. With the repo steps above, this would have shown a warning message since the domain and URI subdomain weren't matching

I see that the blumint team updated the domain in the signature message to include www to match the origin so players can now sign in successfully and without seeing a warning message. Nice 👍

Closing issue

[digiwand]

Hey @oconnorjoseph, thanks for reporting this original issue. Glad to see it's working now. Is the issue your warning modal mentioned fixed? Else, are there more details you could help provide here?

[andrewminton]

I'm using sub domains here and this is still an issue in the latest release for Chrome. https://games.[domain].com in the request and in the APP_DOMAIN env variable.

Even if this is a subdomain request to sign, is the root URL requiring a www version? Using vercel for this and all domain redirects have https://games.[domain].com as the master redirect for all activity.