Skip to content

fix(auth): preserve addAccount param through SSO redirect#877

Closed
Just-Insane wants to merge 3 commits into
SableClient:devfrom
Just-Insane:fix/auth-sso-addaccount
Closed

fix(auth): preserve addAccount param through SSO redirect#877
Just-Insane wants to merge 3 commits into
SableClient:devfrom
Just-Insane:fix/auth-sso-addaccount

Conversation

@Just-Insane
Copy link
Copy Markdown
Contributor

@Just-Insane Just-Insane commented May 19, 2026

Description

When an SSO login is initiated for a second account (with ?addAccount=true), the parameter was not preserved across the provider redirect and was silently discarded. The returning user was logged in as a new primary session instead of being added to the multi-account switcher. This fix threads the addAccount parameter through the SSO callback URL so it survives the redirect.

Fixes #

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings

AI disclosure:

  • Partially AI assisted (clarify which code was AI assisted and briefly explain what it does).
  • Fully AI generated (explain what all the generated code does in moderate detail).

The fix reads addAccount from the pre-redirect query string and appends it to the redirectUri passed to the identity provider, so after the provider redirects back to Sable the login handler adds the session to the multi-account switcher instead of replacing the current session.

When adding a second account via SSO login/registration, the addAccount=1 parameter was not preserved through the SSO provider redirect. This caused the system to treat it as a primary login instead of adding an account, effectively blocking users from adding additional accounts when their first account used SSO.

Changes:
- Login.tsx: Check for addAccount param and include it in ssoRedirectUrl
- Register.tsx: Same fix for SSO registration flow
- Register.tsx: Import withSearchParam utility

Flow now works:
1. User clicks "Add Account" → navigates with ?addAccount=1
2. User chooses SSO → redirectUrl includes ?addAccount=1
3. SSO provider redirects back → addAccount=1 preserved
4. Login completes → system knows to add account, not replace

Fixes issue where SSO accounts blocked adding any other accounts (SSO or non-SSO).
@Just-Insane Just-Insane marked this pull request as ready for review May 19, 2026 23:15
@Just-Insane Just-Insane requested review from 7w1 and hazre as code owners May 19, 2026 23:15
Copilot AI review requested due to automatic review settings May 19, 2026 23:15

This comment was marked as spam.

@dozro
Copy link
Copy Markdown
Member

dozro commented May 20, 2026

#882 seems to fix this as well 🤷‍♀️

@dozro dozro added the duplicate This issue or pull request already exists label May 20, 2026
@dozro dozro closed this May 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

duplicate This issue or pull request already exists

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants