[in_app_purchase] Return jwsRepresentation and jsonRepresentation for StoreKit2

[shaunpanjabi]

Fix for flutter/flutter#164433

Providing access to jwsRepresentation. property of the transaction. With the most recent update PurchaseVerificationData returns empty now. I think it could make sense to repurpose it and return the:

• jsonRepresentation for localVerificationData
• jwsRepresentation for serverVerificationData

Pre-Review Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter.
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy, or I have commented below to indicate which version change exemption this PR falls under¹.
• I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style, or I have commented below to indicate which CHANGELOG exemption this PR falls under¹.
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which test exemption this PR falls under¹.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

Footnotes

1. Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩² ↩³

[flutter-dashboard]

It looks like this pull request may not have tests. Please make sure to add tests or get an explicit test exemption before merging.

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.If you believe this PR qualifies for a test exemption, contact "@test-exemption-reviewer" in the #hackers channel in Discord (don't just cc them here, they won't see it!). The test exemption team is a small volunteer group, so all reviewers should feel empowered to ask for tests, without delegating that responsibility entirely to the test exemption group.

[maks-epowar]

Hi is there any update on adding this? This is more logical than returning empty verification data

[LouiseHsu]

Approved, with a comment about the versioning

[LouiseHsu]

The reason the repo_check is failing is b/c of this - could you add lines 3-5 to a new 0.4.1 version and remove the NEXT?

[shaunpanjabi]

Thanks! I updated to 0.4.2 since 0.4.1 just got merged in recently. Hope that is okay 🙏

[auto-submit]

autosubmit label was removed for flutter/packages/9280, because This PR has not met approval requirements for merging. The PR author is not a member of flutter-hackers and needs 1 more review(s) in order to merge this PR.

• Merge guidelines: A PR needs at least one approved review if the author is already part of flutter-hackers or two member reviews if the author is not a flutter-hacker before re-applying the autosubmit label. Reviewers: If you left a comment approving, please use the "approve" review action instead.

[LouiseHsu]

@LongCatIsLooong Can you take a look at this when you have time? 😺

[LongCatIsLooong]

Thanks for the patch!

I couldn't find the relevant information in the PurchaseVerificationData documentation so could you clarify how localVerificationData and serverVerificationData are supposed to be used? From reading the storekit documentation, my impression is that you don't have to do anything with localVerificationData (as StoreKit has already verified it), but you can optionally check the signed information in serverVerificationData on your own server or on the device, to verify the purchase?

[LongCatIsLooong]

nit: final instead of late?

[shaunpanjabi]

I believe it has to be late since it is being referenced inside the listen callback. So it is being referenced before it is initialized.

[LongCatIsLooong]

(here and below) I don't think the string interpolation here is necessary, since jwsRepresentation is a string itself: https://developer.apple.com/documentation/storekit/verificationresult/jwsrepresentation-21vgo (if I'm looking at the right jwsRepresentation, that is)

[LongCatIsLooong]

Could you add a bit color to what are jwsRepresentation and jsonRepresentation? Also maybe which jwsRepresentation and jsonRepresentation since there are several fields with identical names in the StoreKit documentation. The 2 lines seem a bit vague without the context.

[shaunpanjabi]

Thanks for the patch!

I couldn't find the relevant information in the PurchaseVerificationData documentation so could you clarify how localVerificationData and serverVerificationData are supposed to be used? From reading the storekit documentation, my impression is that you don't have to do anything with localVerificationData (as StoreKit has already verified it), but you can optionally check the signed information in serverVerificationData on your own server or on the device, to verify the purchase?

Yeah the localVerificationData isn't really necessary. I just thought it might be useful for debugging locally or for accessing the properties of transaction directly if they aren't already exposed. I'd be open to removing it if people don't think it's useful.

serverVerificationData is used to pass the signed transaction securely to your server so it can be verified.