Skip to content

lit-node-client-nodejs test fails with "Invalid SIWE message. Missing expirationTime or issuedAt." #771

Closed
@susumutomita

Description

@susumutomita

Is there an existing issue for this?

  • I have searched the existing issues

SDK version

Using Lit JS SDK (master branch)

Lit Network

N/A (this is a unit test issue, not network-specific)

Description of the bug/issue

A test in lit-node-client-nodejs fails with the error message:

Invalid SIWE message. Missing expirationTime or issuedAt.

Specifically, the test suite:

❯ npx nx run lit-node-client-nodejs:test
FAIL   lit-node-client-nodejs  packages/lit-node-client-nodejs/src/lib/helpers/validate-bls-session-sigs.spec.ts
  ● BlsSessionSigVerify › should verify valid bls signatrue

    Invalid SIWE message. Missing expirationTime or issuedAt.

It appears that the SIWE message in the test does not include issuedAt, which is required by the blsSessionSigVerify function. According to the logic in validate-bls-session-sig.ts, both expirationTime and issuedAt must be present.

Severity of the bug

This breaks the test for lit-node-client-nodejs, causing CI to fail unless the test is adjusted to include issuedAt in the SIWE message.

Steps To Reproduce

  1. Run npx nx run lit-node-client-nodejs:test
  2. Observe that BlsSessionSigVerify test fails with Invalid SIWE message. Missing expirationTime or issuedAt.

Link to code

https://github.com/LIT-Protocol/js-sdk/blob/master/packages/lit-node-client-nodejs/src/lib/helpers/validate-bls-session-sigs.spec.ts#L29

Proposed fix

  • Add issuedAt to the SIWE message in the failing test. For example:
  it(`should verify valid bls signatrue`, async () => {
    expect(
      await blsSessionSigVerify(
        async (
          publicKey: String,
          message: Uint8Array,
          signature: Uint8Array
        ): Promise<void> => {
          expect(typeof publicKey).toBe('string');
          expect(typeof message).toBe('object');
          expect(typeof signature).toBe('object');
        },
        networkPubKey,
        authSig,
        new SiweMessage({
          domain: 'localhost',
          statement:
            'litprotocol.com wants you to sign in with your Ethereum account:\n' +
            '0xf087a967D9eA9445D9182692C2944DcC0Af57341\n' +
            '\n' +
            "Lit Protocol PKP session signature I further authorize the stated URI to perform the following actions on my behalf: I further authorize the stated URI to perform the following actions on my behalf: (1) 'Threshold': 'Execution' for 'lit-litaction://*'. (2) 'Threshold': 'Signing' for 'lit-pkp://*'. I further authorize the stated URI to perform the following actions on my behalf: (1) 'Threshold': 'Execution' for 'lit-litaction://*'. (2) 'Threshold': 'Signing' for 'lit-pkp://*'. (3) 'Auth': 'Auth' for 'lit-resolvedauthcontext://*'.\n",
          address: authSig.address,
          uri: 'lit:session:efebafcc9063827a49dffdb11c36b2d64a33330631ac7f5825e2960946bcc8ff',
          version: '1',
          nonce:
            '0x1f623ab8dfe6bbd3b3dc22c7a041deb697c14817bce471b1bd1d86a25d5a319c',
          expirationTime: new Date(
            Date.now() + 1000 * 60 * 60 * 24 * 7
          ).toISOString(),
          notBefore: new Date(Date.now()).toISOString(),
          issuedAt: new Date().toISOString(), => Add issuedAt
        })
      )
    ).toBeUndefined();
  });

After adding issuedAt, the test should pass without throwing Invalid SIWE message. Missing expirationTime or issuedAt.
If for some reason we do not want issuedAt, we'd need to update the logic in blsSessionSigVerify to remove the strict requirement, but that seems less aligned with standard SIWE usage.

Anything else?

If there's any reason we shouldn't require issuedAt, we could discuss adjusting the validation. However, EIP-4361 (“Sign-In with Ethereum”) typically includes issuedAt, so adding it is likely the correct fix.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions