Conversation
Updates the aws-sdk-swift dependency to 1.7.53, which moves the transitive dependency: smithy-swift 0.223.0 -> 0.238.0 aws-crt-swift stays resolved at 0.64.1: smithy-swift raised its floor from `from: "0.63.0"` to `from: "0.64.0"`, which the already-pinned 0.64.1 satisfies. No other transitive pins change. The aws-sdk-swift range is almost entirely API and endpoint model regeneration. For the services Amplify depends on the changes are additive only: Cognito Identity Provider gains GetProvisionedLimit / UpdateProvisionedLimit, EumsSms in SmsConfigurationType, and AdminGetUserAuthFactors; CloudWatch Logs gains storage-tier and lookup-table APIs; TranscribeStreaming gains an optional TranscriptFormat parameter. The one breaking entry in the range (1.7.28 removes SimSpaceWeaver, Panorama, IoT Events, IoT Events Data) does not touch any Amplify dependency. smithy-swift's breaking changes in 0.224.0-0.238.0 are confined to the @_spi(SchemaBasedSerde) codegen surface that only the SDK's own generated code consumes: ShapeDeserializer.readInteger/readLong narrowing to Int32/Int64, readDocument returning `any SmithyDocument`, and ReadStructConsumer being replaced by a deserializeMember requirement. The modules Amplify imports directly - SmithyIdentity, SmithyRetries, SmithyHTTPAuth and their API variants - are unchanged. ClientRuntime's only behavioral delta is percent-encoding moving its implementation into SmithyHTTPAPI.URLEncodingUtils with the same allowed character sets. Verified that the non-sparse-map null regression which gated the previous bump (#4234) has not returned: SmithyJSON's Deserializer still compacts UnexpectedNullError out of non-sparse maps and lists, so Cognito RespondToAuthChallenge responses carrying a null ChallengeParameters value (e.g. "FRIENDLY_DEVICE_NAME": null in the SELECT_MFA_TYPE challenge) continue to deserialize.
…s remember devices (#4254) * fix(auth): read device metadata with the caller's username during sign-in `ConfirmDevice` stores device metadata under `signedInData.inputUsername` (the username the caller signed in with), but the sign-in flow read it back using `parameters["USERNAME"]` — the value Cognito echoes, which is the sub for pools configured with alias sign-in. On those pools the read never matched the write, so `DEVICE_KEY` was omitted from the password-verifier response. Cognito treated every sign-in as a new device: it returned fresh `NewDeviceMetadata`, `ConfirmDevice` stored it under the email again, and the next sign-in repeated the cycle — MFA on every sign-in and a new device record per attempt (one user had accumulated 50). Pools where the username *is* the email are unaffected, since the two values coincide there. Reads now use the same value as the write: - VerifyPasswordSRP: `inputUsername` - VerifySignInChallenge (both call sites): `challenge.inputUsername ?? username` Nothing sent to Cognito changes — `username` still supplies `USERNAME` on every request; only the keychain lookups moved. Known gap: the DeviceSRP actions (InitiateAuthDeviceSRP, VerifyDevicePasswordSRP) still look up by the echoed username. That path only executes once Cognito starts accepting the device key, so it is now reachable and tracked separately. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(auth): delete device metadata with the same username used to read it Commit 122689e changed the sign-in flow to read device metadata with the caller's `inputUsername` (matching how `ConfirmDevice` writes it), but left the `deviceNotFound` recovery paths deleting under `username` — the value Cognito echoes, which is the sub for pools with alias sign-in. When a stored device key is stale, Cognito rejects the password verifier with `ResourceNotFoundException`. The recovery path then deletes the wrong keychain entry, leaving the real one in place, so the retry re-reads the same stale key, Cognito rejects it again, and sign-in loops indefinitely. Read and delete now use the same value in both actions: - VerifyPasswordSRP: `inputUsername` - VerifySignInChallenge: `challenge.inputUsername ?? username` Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(auth): use inputUsername for device metadata in the device SRP flow Once a device is remembered, Cognito answers the password verifier with DEVICE_SRP_AUTH instead of an MFA challenge, routing sign-in through InitiateAuthDeviceSRP / VerifyDevicePasswordSRP. Both looked the stored device metadata up by the Cognito-echoed username (the sub, on pools with alias sign-in) rather than the `inputUsername` it was written under, so the lookup missed and the request omitted DEVICE_KEY — Cognito then rejected sign-in with "Missing required parameter DEVICE_KEY". - UserPoolSignInHelper: carry `inputUsername ?? username` into `.initiateDeviceSRP` so InitiateAuthDeviceSRP reads (and re-sends) under the right key. - VerifyDevicePasswordSRP: read metadata with `inputUsername`; the request still sends `username` (the echoed value), which is what Cognito expects. Completes the alias-pool device-remembering fix (see prior two commits); the DEVICE_SRP_AUTH path is only reachable once DEVICE_KEY is accepted, so it could not be exercised until the earlier read/delete fixes landed. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> Co-authored-by: Harsh <6162866+harsh62@users.noreply.github.com>
harsh62
approved these changes
Aug 4, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
kickoff release