verifying signing key

[Nadia]

hi all! i'm trying to test enhanced security code before going to prod, following instructions found here https://github.com/knocklabs/knock-node#signing-jwts

on the client app in react

    <KnockFeedProvider
      apiKey={apiKey}
      feedId={feedId}
      userId={walletAddress}
      userToken={authToken}
    >
      <>
        <NotificationIconButton
          ref={notifButtonRef}
          onClick={() => setIsVisible(!isVisible)}
        />
        <NotificationFeedPopover
          buttonRef={notifButtonRef}
          isVisible={isVisible}
          onClose={() => setIsVisible(false)}
        />
      </>
    </KnockFeedProvider>

on the server side this is how i'm signing the jwt

import { Knock } from "@knocklabs/node";
Knock.signUserToken(walletAddress, {
            expiresInSeconds: 10 * 60,
          })

API key starts with pk_test_Ujf and set with NEXT_PUBLIC_KNOCK_PUBLIC_API_KEY env variable, and authToken starts with LS0tLS1CRU and set with KNOCK_SIGNING_KEY env variable, the auth response sends back {"code":"authorization","message":"You are not allowed to access that resource","status":403,"type":"authentication_error"}
I've inspected the request headers which includes the authorization and x-knock-user-token, am I missing a step?
enhanced security mode is turned on for dev environments.

running with

    "@knocklabs/node": "^0.4.17",
    "@knocklabs/react-notification-feed": "^0.8.2", 

Thanks!

[Chris Bell]

Hey @naquarius could you tell us your Knock account slug or send over a request ID we could lookup, please? What you're doing here looks right.

[Nadia]

hi @cjbell does this work? x-request-id: F0pARTYO_-n5IfkE8-uC

[Chris Bell]

@naquarius yep that's great, thanks – looking into this now for you 👀

[Chris Bell]

OK @naquarius I figured this out. So when we decode the user_id out of the JWT, the user_id is coming out as user_id: "0xe7d9xxx" which you'll notice is downcased from 0xE7D9xxx that you're using as a user_id.

A workaround right now is to downcase all of your user_ids but we're actively looking into this issue on our end to see what we can do. We think this might be a bug with the token parsing library we're using but we're still investigating!

[Nadia]

@cjbell thank you for the quick turnaround! we will work around this :)

[Nadia]

OK @naquarius I figured this out. So when we decode the user_id out of the JWT, the user_id is coming out as user_id: "0xe7d9xxx" which you'll notice is downcased from 0xE7D9xxx that you're using as a user_id.

A workaround right now is to downcase all of your user_ids but we're actively looking into this issue on our end to see what we can do. We think this might be a bug with the token parsing library we're using but we're still investigating!

actually, the error exist on my side, the wallet address returned from our get user call is all lower case. 😵‍💫

[Chris Bell]

@naquarius ah-ha! Ok now that is good to know!

[Chris Bell]

Closing this now 👍