Magic client-side Web SDK provides Test Mode as a quick way to test your integration locally by asserting specific error codes or bypassing the magic link flow completely.

#Usage

To enable Test Mode, provide testMode: true to the SDK constructor.

01import { Magic } from 'magic-sdk';

02

03const magic = new Magic('YOUR_API_KEY', {

04  testMode: true,

05});

With Test Mode enabled, you can assert the desired behavior through the email address you provide to loginWithMagicLink.

To assert a success state, use test+success@magic.link.

01magic.auth.loginWithMagicLink({ email: 'test+success@magic.link' });

To assert a failed state, use test+fail@magic.link.

01magic.auth.loginWithMagicLink({ email: 'test+fail@magic.link' });

To assert a case-specific failed state, you can also provide an RPC error code with test+fail_with_{RPC_ERROR_CODE}@magic.link.

01import { RPCErrorCode } from 'magic-sdk';

02

03magic.auth.loginWithMagicLink({ email: `test+fail_with_{${RPCErrorCode.MagicLinkFailedVerification}}@magic.link` });

04magic.auth.loginWithMagicLink({ email: `test+fail_with_{${RPCErrorCode.MagicLinkExpired}}@magic.link` });

05magic.auth.loginWithMagicLink({ email: `test+fail_with_{${RPCErrorCode.MagicLinkRateLimited}}@magic.link` });

06...

You can find a list of relevant RPC error codes here.

#Advanced Usage

Web3 and blockchain use-cases sometimes require access to deterministic key-pairs so that testnet funds are available at runtime. To enable this, users can explicitly specify the key-pair associated to a test user, like so:

01test+success_with_{PUBLIC_KEY:PRIVATE_KEY}@magic.link

In practice, you can assert a successful login with:

01magic.auth.loginWithMagicLink({

02  email:

03    'test+success_with_{0x89A3983da27fF0eFCF901F74C4df84e0450A17B7:0x19de850af732e9e5745915162d707d6d8cf013ce7b2862e93081b0c8883bdfae}@magic.link',

04});

In the example above, we encode an Ethereum-compatible key-pair in the test user's email address. The login method will immediately resolve with a success state, bypassing the passwordless flow and enabling Ethereum or EVM-compatible signing methods to work seamlessly with your existing Web3 code.

#Expected Behavior

Client-side Web SDK methods

• The loginWithMagicLink method from the Auth Module will be the only login option to assert the desired behavior. Passing test+success@magic.link into the loginWithEmailOTP method will throw an RPCError.
• Attempting to change the email address via use of the updateEmail method from the User Module will throw an RPCError.
• You can generate a new DID token via use of the getIdToken or generateIdToken methods from the User Module.
• Calling the getMetadata method from the User Module while test+success@magic.link is logged in will return the following;

01{

02	issuer: 'did:ethr:0x1e9FF803fFA22209A10A087cc8361d4aa3528c45',

03	publicAddress: '0x1e9FF803fFA22209A10A087cc8361d4aa3528c45',

04	email: 'test+success@magic.link'

05}

• Calling the isLoggedIn method from the User Module will return a boolean value after checking if test+success@magic.link is currently logged in.
• Calling the logout method from the User Module will log test+success@magic.link out.

Server-side SDK methods

• magicClient.auth.loginWithMagicLink({ email: 'test+success@magic.link' }) resolves to a DID token that is not valid to all server-side SDK methods.
• Passing the DID token to the validate method from the Token Module will throw an IncorrectSignerAddress error.
• Passing the DID token to the getIssuer method from the Token Module will return the following;

01{

02  issuer: "did:ethr:0x1e9FF803fFA22209A10A087cc8361d4aa3528c45"

03}

• Passing the DID token to the getPublicAddress method from the Token Module will return the following;

01{

02  publicAddress: "0x1e9FF803fFA22209A10A087cc8361d4aa3528c45"

03}

• Passing the DID token to the decode method from the Token Module will return [string, Claim]: containing the [proof, claim] that composes the DID token.

01import { Claim } from '@magic-sdk/admin';

02

03interface Claim {

04  iat: number; // Issued At Timestamp

05  ext: number; // Expiration Timestamp

06  iss: string; // Issuer of DID Token

07  sub: string; // Subject

08  aud: string; // Audience

09  nbf: number; // Not Before Timestamp

10  tid: string; // DID Token ID

11  add: string; // (optional) Misc additional signed data

12}

• Passing the DID token to any method from the User Module will throw a ServiceError error. Getting metadata server-side is not supported from the Test Mode DID token. Logging out via server-side SDK method logout is also not supported.