VerificationException status: 2(INVALID_APP_IDENTIFIER) occurs when using verifyAndDecodeNotification method in Production Environment

[LoisFromNeo]

Hello,

I hope this message finds you well.

I am currently using version 1.4.0 of your app-store-server-library-node. However, when trying to verify the signedPayload received from the server notification for an auto-renewable subscription using the verifyAndDecodeNotification method, a VerificationException with {status: 2 and cause: undefined} occurs.

The parameters passed to create the verifier instance have remained the same, and this error has been occurring continuously from July 27th(KST) until today. There has been no change in the app id.

In this situation, I would like to know what I should check and what I can correct. Please provide guidance on how to resolve this issue.

Thank you.

[alexanderjordanbaker]

@LoisFromNeo The simplest thing to check is to either use a debugger or take the JWS and plug it into a JWS/JWT decoder and read out the bundleId and appAppleId from the notification. Does it match the bundleId and appAppleId you are passing into the SignedDataVerifier?

[LoisFromNeo]

Yes, I just checked the app apple id and app bundle id in the signedPayload using the JWS decoder as you advised. As a result, I found that they match the values I’m passing as parameters when creating the verifier instance.

[alexanderjordanbaker]

@LoisFromNeo In a debugger are they the same when you breakpoint the line that throws the error?

[LoisFromNeo]

Yes, I debugged with VSCode debugger, and I was able to check the values are same. Could you let me know in what situations this exception might occur?

[alexanderjordanbaker]

If the values are the same, then presumably it wouldn’t throw a mismatch exception

[alexanderjordanbaker]

@LoisFromNeo to confirm, you are seeing https://github.com/apple/app-store-server-library-node/blob/5f344871b21f3882611c5cf791b0c0ca7428d56f/jws_verification.ts#L136-L138

The bundle id values match but the equality is failing?

[LoisFromNeo]

Yes, the values were indeed the same.

However, during the process of rewriting the code on our server to create the client library instance from JS to TS yesterday, we found that the Environment value was being passed as a variable defined by our server, instead of the constant value provided by the library, even though they were the same. Since it wasn’t TS, we weren’t able to verify if incorrect parameter values were being passed in the original Javascript code.

After fixing this and redeploying the server, the exception no longer occurs. I apologize for any confusion this may have caused :(

[alexanderjordanbaker]

@LoisFromNeo Glad you were able to work it out!

[azhaochen]

I saw the same case as @LoisFromNeo said, where the APPLE_ID must be a numerical value, not a string.