Skip to content

Conversation

@agbaraka
Copy link

@agbaraka agbaraka commented Sep 8, 2024

Hello Team.

Kindly assist to review this initial implementation of App Check Replay Protection API as requested in issue #632

Your feedback and guidance will be highly appreciated.

@google-cla
Copy link

google-cla bot commented Sep 8, 2024

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

Copy link

@weixifan weixifan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for this contribution! I have left comments addressing App Check domain-specific concerns, but I will leave it to other reviewers to address Go language style and library use concerns.

@agbaraka
Copy link
Author

Hi @weixifan and @lahirumaramba

Thank you for taking your time to review this implementation. Your guidance on this is much appreciated.

I have update the implementation as per @weixifan recommendations. Please review and advise.

Happy coding

@agbaraka agbaraka requested a review from weixifan September 10, 2024 18:27
@agbaraka
Copy link
Author

Hi @weixifan. I hope all is well.

I have refactor token verifier url generation as recommended. I agree, It looks cleaner than before.

Please review

Thanks

@agbaraka agbaraka requested a review from weixifan September 11, 2024 14:52
@agbaraka
Copy link
Author

Hi @weixifan and @lahirumaramba.

Any feedback on this PR?

Copy link

@weixifan weixifan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry about the delay. This is approved from App Check's point of view. A Golang reviewer will review your PR for style and consistency with existing code.

Thank you for your contribution!

@sharathguvvala
Copy link

Hi – This is a really important feature for securing backends, and I was wondering if there’s any estimated timeline for when this might be reviewed and merged?

@agbaraka
Copy link
Author

Hello,

Any updates on this?

Thanks

@lahirumaramba lahirumaramba changed the title Add replay protection feature feat(appcheck): Add replay protection feature Nov 14, 2025
Copy link
Member

@lahirumaramba lahirumaramba left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for you contribution and thank you so much for your patience on this. We have prioritized this feature. I added a few comments. Let me know if you have any questions.

@agbaraka
Copy link
Author

Hello @lahirumaramba. Thank you very much for your feedback. I have added another commit with include changes from your comments.

I had to also update TestVerifyOneTimeToken. Kindly assist to review

Thanks

@agbaraka
Copy link
Author

agbaraka commented Dec 1, 2025

Hi @lahirumaramba

I have updated as per the above feedback.

Thank you for your assistance

@lahirumaramba
Copy link
Member

@gemini-code-assist review

Copy link

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces replay protection for App Check tokens by adding a VerifyOneTimeToken method. The implementation correctly reuses the existing VerifyToken logic for initial validation and then makes an API call to a new endpoint to consume the token. The changes are well-structured, and the necessary modifications to propagate client options for testing purposes are included. The new functionality is covered by a table-driven test, which is great. I've suggested an improvement to the test to cover more failure scenarios.

Comment on lines +61 to +68
appCheckVerifyTestsTable := []struct {
label string
mockServerResponse string
expectedError error
}{
{label: "testWhenAlreadyConsumedResponseIsTrue", mockServerResponse: `{"alreadyConsumed": true}`, expectedError: ErrTokenAlreadyConsumed},
{label: "testWhenAlreadyConsumedResponseIsFalse", mockServerResponse: `{"alreadyConsumed": false}`, expectedError: nil},
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The test cases for TestVerifyOneTimeToken cover the successful API calls well. To make the tests more comprehensive, it would be beneficial to add cases for API call failures, such as network errors or non-200 HTTP status codes from the backend. This will ensure that errors from the underlying httpClient.DoAndUnmarshal are correctly propagated and handled.

For example, you could add cases to your test table for:

  • A network error during the API call (by setting Err on mockHTTPResponse).
  • An unsuccessful HTTP status code like 500 from the backend (by setting StatusCode on mockHTTPResponse).

@agbaraka
Copy link
Author

agbaraka commented Dec 2, 2025

Hi @lahirumaramba and team.

Kindly advise on the failed test stage.

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants