Compute the anti-abuse hash on Authress calls; stamp User-Agent everywhere - #5
Merged
Merged
Conversation
…ery request
The login SDK port never sent antiAbuseHash on /authentication or
/authentication/{id}/tokens, so Authress rejected the calls. Added
JwtManager.calculateAntiAbuseHash (the SDK's proof-of-work: search a
fine-tuner until base64url(SHA-256(timestamp;fineTuner;values)) starts
with "00") and wired it into both request bodies.
Also, only the Authress calls carried an identifying header
(X-Powered-By), and even those relied on OkHttp's default User-Agent.
Added a UserAgentInterceptor on the shared OkHttpClient so both the
Authress session client and the Email API client send a real
User-Agent on every request.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XRMBgZXVCEVwBuBWapy5J7
…Logs tab Compared the Kotlin port against @authress/login (web) call-for-call: - Fixed a real bug in the antiAbuseHash algorithm: array-valued props (e.g. audiences) must stringify as JS would (comma-joined, no brackets) when they fall through untouched into the hash's join step — Kotlin's default List.toString() produces "[a, b]" instead of "a,b", which would have kept producing a hash the backend can't reproduce for any call using array props. - Expanded authenticate() to accept the same options the web/RN SDKs support (tenantLookupIdentifier, inviteId, responseLocation, flowType, scopes, audiences, connectionProperties, multiAccount), with the antiAbuseHash prop order matching the web SDK's authenticate() exactly. - Added linkIdentity, getUserProfile, getDevices, and deleteDevice — present in the RN SDK but missing from this port; closes the MFA/passkey gap noted in todo.md (the Settings UI for device management is still a follow-up). - Added antiAbuseHash to linkIdentity, matching the web SDK's key order. Also added an AppLogger (Room-backed) that every Authress call now reports failures to, and a Settings > Logs tab so a user can review and share (via the system share sheet) what happened when reporting a problem back to us, instead of it only ever reaching logcat. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XRMBgZXVCEVwBuBWapy5J7
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.
Summary
AuthressLoginClient/JwtManager) never sent anantiAbuseHashon the/authenticationor/authentication/{id}/tokenscalls, so Authress was rejecting them. Ported the SDK's proof-of-work algorithm — search afineTuneruntilbase64url(SHA-256("timestamp;fineTuner;values"))starts with"00", formatted asv2;timestamp;fineTuner;hash— intoJwtManager.calculateAntiAbuseHash, and wired it into both request bodies.X-Powered-By), and even those fell back to OkHttp's defaultUser-Agent. The Email API calls had no identifying header at all. Added aUserAgentInterceptoron the sharedOkHttpClientinAppContainerso every request — Authress session calls and Email API calls alike — carries a realUser-Agent.Test plan
/authenticationno longer rejects for a bad/missing anti-abuse hashUser-Agentis present on both Authress and Email API requests (e.g. via request logging)@authress/login-react-native/@authress/loginSDK sources for algorithm parity🤖 Generated with Claude Code
https://claude.ai/code/session_01XRMBgZXVCEVwBuBWapy5J7
Generated by Claude Code