Adopt IAM's hashed_client_secret contract for OAuth replication

What does this MR do and why?

This MR adopts the upstream IAM contract change that renamed the client_secret field to hashed_client_secret on both CreateClient and UpsertClient RPC requests.

The MR comprises two commits:

  1. Regenerates the vendored gitlab-iam-grpc gem from IAM revision 467484f. Master's previous gem regeneration (as part of UpsertClient adoption) was pinned to IAM revision 193b959, which predates the hashed-secret contract change; this regeneration forward to revision 467484f brings in the renamed field and a new dynamic field (pulled in but not adopted/used here).
  2. Renames the keyword argument from client_secret: to hashed_client_secret: in OauthApplicationReplicator, updates the matching assertions in the replicator's spec and the GrpcClient spec, and adds a new spec pinning the value sent to IAM's validation pattern ^[0-9a-f]{128}$, catching future changes to Doorkeeper's secret-storage strategy before they silently wedge replication at IAM's validation boundary.

Without this field rename, replication calls to IAM fail validation, causing the outbox to retry forever with INVALID_ARGUMENT. The actual secret value sent is unchanged — application.secret is already the SHA-512 hex digest produced by Gitlab::DoorkeeperSecretStoring::Sha512Hash (configured in config/initializers/doorkeeper.rb) — so this is strictly a field-name rename.

The replication feature is behind the default-off feature flag iam_data_replication. Re-draining and backfilling applications already replicated before this fix is a separate post-merge operational follow-up, tracked in the linked work item.

References

How to set up and validate locally

Enable the iam_data_replication feature flag to exercise the replication path locally. Specs for OauthApplicationReplicator and GrpcClient have been updated, and a new spec for pattern validation has been added; all should pass.

Edited by Smriti Garg

Merge request reports

Loading
Loading