Repository navigation
feat: support lock reason in user search - #813
Conversation
Add lockReasons and tempLockReasons to SearchRequest (descope/etc#18708)
d6bd15f to
322f08e
Compare
There was a problem hiding this comment.
The request side looks right: both filters pass through search and searchTestUsers and are dropped when unset.
Gap: search returns UserResponse from @descope/core-js-sdk, which has no lockReason / tempLockExpiration (on main or on descope-js#1505). So user.lockReason is a TypeScript error here, while Go, Java and Python expose it. Suggest adding both fields to core-js-sdk's UserResponse (I suggested it on descope-js#1505) and bumping core here before release.
core-js-sdk's UserResponse has no lockReason / tempLockExpiration yet, so UserSearchResponse now uses a node-sdk UserSearchResult that adds both (descope/etc#18708) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
🐕 Shuni ReviewNo new issues found. 🤖 Model: Review scope: Partial incremental re-review Reviewed new changes (3)
🐕 Review complete — View session on Shuni Portal 🐾 🤖 Model: |
…stead This reverts commit 4e3ce94. lockReason and tempLockExpiration are added to core-js-sdk's UserResponse in descope/descope-js#1507; core is bumped here once that's released. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Added them to cores UserResponse: descope/descope-js#1507. I'll bump core here once its released. |
descope/etc#18708 ## Related PRs - Follow-up to descope/node-sdk#813, which types these fields on search results only, via a node-sdk `UserSearchResult` - Related: #1505 (user management widget lock reason) ## Description The user APIs return two brute-force lock fields that `UserResponse` doesn't type, so SDK consumers can only read them with a cast: - `lockReason?: string` - the auth method that triggered brute-force protection (`password`, `totp`, `recovery_codes`, `security_questions`), empty when none - `tempLockExpiration?: number` - when a temporary lock ends, in unix seconds (0 when none). The user is temporarily locked while this is greater than now Types only. Both fields are optional, so nothing changes for existing callers or for backends that don't return them. Once this is released, node-sdk can drop `UserSearchResult` and `load` and the other user methods get the fields too. ## Must - [x] Tests (existing suite passes; the change is type-only) - [ ] Documentation (if applicable) 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
core-js-sdk 2.75.0 adds lockReason and tempLockExpiration to UserResponse (descope/descope-js#1507), so search results expose them (descope/etc#18708) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Related Issues
Related: descope/etc#18708
Description
Adds
lockReasonsandtempLockReasonstoSearchRequest. The deprecated positionalsearchAllis unchanged. The response type lives in core-js-sdk, which needslockReason?: string; tempLockExpiration?: number;onUserResponsein a separate descope-js change.tempLockExpirationis unix seconds (0 when none). A user is temporarily locked whiletempLockExpiration > now. TOTP has no temporary lock, sotempLockReasonsaccepts only password, recovery_codes and security_questions.Must
🤖 Generated with Claude Code