Fix link-outcome redirect query key mismatch with users-web - #69
Merged
Merged
Conversation
…contract linkErrorRedirect sent ?link_error=<reason> on failure and a bare redirect with no outcome param at all on success. users-web's SettingsController only ever reads req.query[String.self, at: "link"] and settings.leaf only recognizes linkOutcome == "conflict"/"error"/"success" - so neither path ever produced a banner. Confirmed on dev: a real conflicting-account link attempt correctly failed server-side (?link_error=conflict in the URL) but showed no error to the user at all. Maps every LinkErrorReason except .conflict to the generic "error" outcome - users-web never surfaces the denied/expired/unavailable distinction itself, only "conflict" has its own banner copy. Success now redirects with ?link=success. No existing test exercised linkCallback's redirect at all, which is how this shipped unnoticed. Added a regression test for the earliest error branch (Auth0 returning ?error=) - reproducible without mocking Auth0's HTTPS token endpoint, which the existing linkComplete fake-server tests deliberately avoid for the same reason (see their own comment).
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
1 participant
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
linkErrorRedirectsent?link_error=<reason>on failure, and the success path redirectedbare with no outcome param at all.
users-web'sSettingsControlleronly ever readsreq.query[String.self, at: "link"], andsettings.leafonly recognizeslinkOutcome == "conflict"/"error"/"success"- so neither path ever produced a banner on the settingspage.
Confirmed on dev: a real conflicting-account link attempt correctly failed server-side
(
?link_error=conflictin the URL) but showed nothing to the user at all - no error message,no indication anything happened.
Fix
?link=<outcome>, mapping everyLinkErrorReasonexcept.conflictto the generic"error"outcome -users-webnever surfaces the specificdenied/expired/unavailable distinction, only
"conflict"has its own banner copy.?link=success.No existing test exercised
linkCallback's redirect at all, which is how this shippedunnoticed. Added a regression test for the earliest error branch (Auth0 returning
?error=),reproducible without mocking Auth0's HTTPS token endpoint - the existing
linkCompletefake-server tests deliberately avoid that for the same reason (see their own comment).
Part of closing out sweetrpg/platform#70.
Test plan
swift build- cleanswift test(full suite, 26/26) - passswift format lint --recursive --strict Sources Tests- cleansuccessful link shows the success banner