Conversation
… exception AM 8.1.0 (OPENAM-24154) returns HTTP 400 when a user selects the wrong number in a Push Number Challenge. Previously the SDK surfaced a generic PushMechanismException with no semantic meaning. This fix introduces PushNumberChallengeException (extends PushMechanismException) so callers can distinguish a wrong-number rejection from other failures, and leaves the PushNotification in its pending state so the app can offer a retry. Phases: - phase 1: Create PushNumberChallengeException (8804d77c) - phase 2: Handle 400 for Push Number Challenge in PushResponder (fe17bf07) - phase 3: Unit tests for 400 number-challenge path (4d57f2ca) - code review: Remove body logging, fix test builder placement (cc910478) Refs: SDKS-5114
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## develop #521 +/- ##
=============================================
- Coverage 65.77% 65.76% -0.02%
- Complexity 1762 1763 +1
=============================================
Files 264 265 +1
Lines 8658 8673 +15
Branches 969 972 +3
=============================================
+ Hits 5695 5704 +9
- Misses 2532 2536 +4
- Partials 431 433 +2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
spetrov
left a comment
There was a problem hiding this comment.
LGTM. Just one question to clarify...
| listener.onSuccess(null); | ||
| } else if (response.code() == 400 && pushNotification.getPushType() == PushType.CHALLENGE) { | ||
| // Number challenge failed — notification stays pending so the user can retry. | ||
| listener.onException(new PushNumberChallengeException( |
There was a problem hiding this comment.
Isn't this hardcoded message Number challenge failed: the selected number was incorrect. too specific?... The 400 response on a CHALLENGE notification could be for other reasons (expired challenge or malformed JWT payload for example...)
In fact, maybe it would be better to directly surface the message coming from AM - i.e. with the fix AM now returns this:
{
"code": 400,
"reason": "Bad Request",
"message": "Number challenge predicate not met."
}
Also, consider adding a WARN level message in the logs...?
eaf7d9f
* SDKS-4658: Set code verifier to null for Apple Sign-In The `codeVerifier` is explicitly set to `null` in the `AuthorizationRequest.Builder` for the Apple Sign-In handler. * SDKS-4714: Use empty request body in self-service session endpoint (#510) * SDKS-4714: Use empty request body in self-service session endpoint Remove the `EMPTY` constant from OkHttp's `RequestBody` and has been replaced with `"".toRequestBody()`. * Update Session.kt Signed-off-by: Andy Witrisna <andy.witrisna@forgerock.com> --------- Signed-off-by: Andy Witrisna <andy.witrisna@forgerock.com> * Add migration support for Ping SDK with DefaultStorageClient (#511) * Increase sleep time in FRUserMockTest to ensure token expiration (#513) The `Thread.sleep` duration in `FRUserMockTest.kt` is increased from 1000ms to 2000ms to allow sufficient time for tokens to expire before testing the refresh token flow. * ForgeRock Android SDK 4.8.4 Release preparation (#512) * Updated for the ForgeRock 4.8.4 release * Fixed various e2e test cases. * SDKS-4947 Updating README with maintenance information (#515) * Updating README with maintenance information * Rename contribution file name * SDKS-5037 - Upgrade bcpkix-jdk18on from 1.81 to 1.84 to address CVE-2026-5588 (#516) * ForgeRock Android SDK 4.8.5 Release preparation (#517) * Removed Sonatype OSS Index Scan from the CI (this service has been discontinued) * Updated version number for the ForgeRock 4.8.5 release * Fix mend tasks to fail the pipeline if critical or high vulnerabilities are found * SDKS-5096: Enhance WebAuthn registration by adding optional device name (#519) * SDKS-5096: Enhance WebAuthn registration by adding optional device name parameter * SDKS-5120: Add authenticationValidityDuration support to device binding and signing (#520) * SDKS-5120: Allow configurable authenticationValidityDuration in DeviceBindingCallback and DeviceSigningVerifierCallback * PR review - guard authentication validity duration. * [fix] SDKS-5114 Handle AM 400 for Push Number Challenge with distinct exception (#521) * [fix] SDKS-5114 Handle AM 400 for Push Number Challenge with distinct exception AM 8.1.0 (OPENAM-24154) returns HTTP 400 when a user selects the wrong number in a Push Number Challenge. Previously the SDK surfaced a generic PushMechanismException with no semantic meaning. This fix introduces PushNumberChallengeException (extends PushMechanismException) so callers can distinguish a wrong-number rejection from other failures, and leaves the PushNotification in its pending state so the app can offer a retry. Phases: - phase 1: Create PushNumberChallengeException (8804d77c) - phase 2: Handle 400 for Push Number Challenge in PushResponder (fe17bf07) - phase 3: Unit tests for 400 number-challenge path (4d57f2ca) - code review: Remove body logging, fix test builder placement (cc910478) Refs: SDKS-5114 * Addressing comment from Stoyan * Updated version number for the ForgeRock 4.8.6 release (#522) --------- Signed-off-by: Andy Witrisna <andy.witrisna@forgerock.com> Co-authored-by: Andy Witrisna <witrisna@gmail.com> Co-authored-by: Andy Witrisna <andy.witrisna@forgerock.com> Co-authored-by: Vibhor Goswami <vibhor.goswami@gmail.com> Co-authored-by: Rodrigo Reis <rodrigo.reis@forgerock.com>
JIRA Ticket
SDKS-5114 "[Legacy][Android] forgerock-authenticator handle AM 400 for Push Number Challenge"
Description
AM 8.1.0 added server-side validation for Push Number Challenge: selecting the wrong number now yields
400 Bad Requeston the authenticate endpoint instead of200. PreviouslyPushResponder.performAuthentication(...)treated any non-200 as a genericPushMechanismException("Communication with server returned <code> code."), so users got no semantic signal and the app could not distinguish a wrong-number rejection from a network failure.This change introduces a new
PushNumberChallengeException extends PushMechanismExceptionsubtype and wires it into theonResponsecallback: when the response code is400and the notification isPushType.CHALLENGE, throw the distinct exception and leave the notificationpending = true/approved = falseso the app can retry. All other code paths (200 success, non-CHALLENGE 400, 401/500/etc.) keep their current behavior exactly.Definition of Done Checklist: