Merge upstream aws-amplify/amplify-swift main (through 2.60.1) - #5
Merged
Conversation
… 26 (URL signing + Sendable credentials) (aws-amplify#4248) * fix(predictions): fix SigV4 URL signing for iOS 26 and temporary credentials * fix(auth): make AWSCredentials Sendable (aws-amplify#4253) Co-authored-by: zhouzihao <zhouzihao@changzhi.top> --------- Co-authored-by: zhouzihao <nenseso@163.com> Co-authored-by: zhouzihao <zhouzihao@changzhi.top>
Bumps [body-parser](https://github.com/expressjs/body-parser) from 1.20.5 to 1.20.6. - [Release notes](https://github.com/expressjs/body-parser/releases) - [Changelog](https://github.com/expressjs/body-parser/blob/master/HISTORY.md) - [Commits](expressjs/body-parser@1.20.5...1.20.6) --- updated-dependencies: - dependency-name: body-parser dependency-version: 1.20.6 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [json](https://github.com/ruby/json) from 2.19.7 to 2.19.9. - [Release notes](https://github.com/ruby/json/releases) - [Changelog](https://github.com/ruby/json/blob/master/CHANGES.md) - [Commits](ruby/json@v2.19.7...v2.19.9) --- updated-dependencies: - dependency-name: json dependency-version: 2.19.9 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* feat: add connect client * add unit tests to ci/cd * fix unit tests * update amplify outputs configuration parsing * address review comments * feat(connect): rework client to Option C API contract Public surface is now identifyUser(userProfile:), registerDevice(token:), and removeDevice(). All routes are SigV4-signed (Bearer token path removed; the backend derives the caller identity from the request signature, so userId is no longer sent). IdentifyUserOptions and OptOut are removed. UserProfile now carries email, name, phone, customAttributes, and location (city, country, postalCode, region). registerDevice resolves deviceId, platform, appVersion, and channelType internally, with platform derived from the target OS. Removes the now-unused AuthToken and AuthTokenProvider protocols from AmplifyFoundation and updates unit and integration tests to the new contract. * chore(connect): declare UserDefaults required-reason API in privacy manifest AmplifyConnectClient persists a device identifier in UserDefaults, so the privacy manifest now declares NSPrivacyAccessedAPICategoryUserDefaults with reason CA92.1, and the target is added to the required-reason API list in the root README. * fix(connect): declare collected data types in privacy manifest The client can transmit email address, name, phone number, coarse location (city, country, postal code, region), and a device identifier (persistent device id and push token). Each is declared as linked to identity, not used for tracking, collected for app functionality. Adds a README note that apps should narrow their app-level privacy declarations to the optional UserProfile fields they actually send. * fix(connect): enforce https endpoints and validate input lengths Endpoint hardening: configuration loading now rejects malformed or non-https endpoint URLs, and the client re-validates before every request so manually constructed configurations are covered. The SigV4 signing target (host, port, protocol) is derived from the endpoint URL instead of hardcoding port 443, so the signature is always computed over the same authority the request is sent to. Input bounds: user profile fields (email, name, phone, location fields), customAttributes keys and values, and the device token are validated against the backend's 255-character attribute limit before any network call, throwing the new ConnectError.validation case that names the offending field. Also removes the device identifier from log messages. * fix(connect): count validation lengths in UTF-16 code units to match backend * address review comments * update files * fix swiftformat issue * fix removeDevice api --------- Co-authored-by: Ekjot <43255916+ekjotmultani@users.noreply.github.com>
* feat: add event enrichment client * add more tests * fix swiftformat issue and run tests on CI/CD * add appId to client init and persist client id internally * address review comments * add missing test scheme * update tests * address review comments * address review comment * address review comments * address review changes
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 (aws-amplify#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 (aws-amplify#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>
Brings the fork up to date with upstream releases 2.58.5, 2.59.0, 2.60.0 and 2.60.1 (19 commits from merge base 8741e90). Resolved the sole conflict (.github/workflows/unit_test.yml, modify/delete) by keeping the fork's deletion — all upstream workflows were removed in 7b90dc6. Note: upstream 2.60.1 includes aws-amplify#4254, which is our device-metadata alias-pool fix upstreamed. The fix/device-metadata-alias-username branch is now redundant.
dmorrow
force-pushed
the
dm/merge-upstream-2.60.1
branch
from
August 5, 2026 03:07
818da30 to
b7f9402
Compare
andrewclements
approved these changes
Aug 5, 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
4 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.
Brings the fork up to date with
aws-amplify/amplify-swift2.60.1. Merge base was8741e9058(aws-amplify#4252); the fork was 17 ahead / 19 behind.Single merge commit
b7f940241offorigin/main(312494826) intoupstream/main(827003772, tag2.60.1).Upstream changes pulled in
fix(predictions): Face Liveness with temporary credentials on iOS 26 (URL signing + Sendable credentials) (fix(predictions): fix Face Liveness with temporary credentials on iOS 26 (URL signing + Sendable credentials) aws-amplify/amplify-swift#4248)feat: add connect client (feat: add connect client aws-amplify/amplify-swift#4245) → newAmplifyConnectClienttargetfeat: add event enrichment client (feat: add event enrichment client aws-amplify/amplify-swift#4243) → newAmplifyEventEnrichmentClienttargetfix(auth): key device metadata byinputUsernameso alias sign-in pools remember devices (fix(auth): key device metadata by inputUsername so alias sign-in pools remember devices aws-amplify/amplify-swift#4254);chore(deps): bump aws-sdk-swift 1.7.27 → 1.7.53 (chore(deps): bump aws-sdk-swift from 1.7.27 to 1.7.53 aws-amplify/amplify-swift#4262)chore(deps): bumpjson2.19.7 → 2.19.9 (chore(deps): bump json from 2.19.7 to 2.19.9 aws-amplify/amplify-swift#4255), bumpbody-parser(chore(deps): bump body-parser from 1.20.5 to 1.20.6 in /AmplifyPlugins/Notifications/Push/Tests/PushNotificationHostApp/LocalServer aws-amplify/amplify-swift#4257)fix/device-metadata-alias-usernameis now redundantUpstream aws-amplify#4254 is our device-metadata fix — it landed upstream as a squash of the three commits on
fix/device-metadata-alias-username(f1f35ae81,e08bbb526,25e5d1675).Verified equivalent:
git diff origin/fix/device-metadata-alias-username HEADover the four affected files (VerifyPasswordSRP.swift,VerifySignInChallenge.swift,VerifyDevicePasswordSRP.swift,UserPoolSignInHelper.swift) is empty. That branch can be deleted once this merges — carrying it forward would be a no-op at best.Conflict resolution
Exactly one conflict:
Kept the fork's deletion.
7b90dc628 "getting rid of amplify swift workflows"removed all 70 upstream workflow files; upstream's edit here only addedAmplifyConnectClient/AmplifyEventEnrichmentClientscheme rows to a workflow this fork doesn't run.No other file was touched by both sides.
Extend customizations preserved
git diff --stat upstream/main HEADover the fork's custom files is unchanged from before the merge (9 files, +215 / −43):AWSCognitoAuthPlugin.swift(+145 — public reset/config methods)AmplifyConfiguration.swift,Amplify+Reset.swiftSignedInData.swift,DeviceMetadata.swift,HostedUIOptions.swift,HostedUIProviderInfo.swift,SignInMethod.swiftAmplifyTests/CoreTests/ConfigurationTests.swiftAll 17 fork commits verified reachable from
HEAD, andupstream/main(2.60.1) is now an ancestor.Note
Upstream added two new workflow files (
unit_test_connect.yml,unit_test_event_enrichment.yml) that auto-merged in without conflict. Both areworkflow_dispatch-only, so they never trigger automatically. Left as-is.