feat(eng-4621): add recent login awareness to login page

[PrestigePvP]

Summary

• Stores the user's last-used login method (with org slug for SAML/OIDC/LDAP) in localStorage
• Shows a "Last used" badge on the matching login button on return visits
• Auto-fills the org slug input on the SSO and LDAP login pages based on the last login

[maidul98]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[greptile-apps]

Greptile Summary

This PR adds "recent login awareness" to the frontend login page: the last-used login method (plus org slug for SAML/OIDC/LDAP) is persisted to localStorage via a new useLastLogin hook, surfaced as a "Last used" badge on matching buttons, and used to auto-fill the org slug on SSO/LDAP pages. The refactoring into reusable OrgLoginButton and SocialLoginButton components cleanly removes duplication from InitialStep.

Key issues found:

• saveLastLogin is not called on CLI email login (the callbackPort branch in InitialStep), so users authenticating via CLI will never see the "Last used" badge.
• saveLastLogin is called before the SAML/OIDC redirect completes in SSOStep. Unlike email and LDAP flows (which save only on confirmed success), a failed or cancelled SSO attempt still records the method and persists an incorrect org slug, which will be pre-filled on the next visit.
• saveLastLogin is called before window.open() for social logins — if the popup is blocked or closed without authenticating, the method is still saved as "Last used".

These timing inconsistencies mean the "Last used" state can become incorrect or stale across different login flows.

Confidence Score: 3/5

• Safe to merge — purely additive frontend feature with no backend changes or API breaking changes.
• The core implementation is clean and well-structured. The score is reduced because of three timing inconsistencies in when saveLastLogin is triggered across different login flows: CLI email login doesn't save at all, SAML/OIDC save before auth completes (allowing wrong slugs to be persisted), and social logins save before popup confirmation. These result in the "Last used" state being incorrect or stale for different user populations.
• frontend/src/pages/auth/LoginPage/components/InitialStep/InitialStep.tsx (missing saveLastLogin in CLI flow, premature save in social flow) and frontend/src/pages/auth/LoginPage/components/SSOStep/SSOStep.tsx (saveLastLogin before auth confirmation).

_{Last reviewed commit: 6ae37ad}

[greptile-apps]

Additional Comments (2)

frontend/src/pages/auth/LoginPage/components/InitialStep/InitialStep.tsx
saveLastLogin not called on CLI email login success

The saveLastLogin({ method: LoginMethod.EMAIL }) call (line 148) is only in the else branch (regular web login). The CLI login path (when callbackPort is set) doesn't call saveLastLogin on success, so users who authenticate via the CLI flow will never see the "Last used" badge on the Email button.

        if (isCliLoginSuccessful && isCliLoginSuccessful.success) {
          saveLastLogin({ method: LoginMethod.EMAIL });
          navigateToSelectOrganization(callbackPort);

---

frontend/src/pages/auth/LoginPage/components/SSOStep/SSOStep.tsx
saveLastLogin called before authentication is confirmed

For SAML and OIDC, saveLastLogin is called immediately on form submission — before the window.open() completes and the IdP redirect finishes. This is inconsistent with the email (InitialStep.tsx) and LDAP (LoginLDAPPage.tsx) flows, where saveLastLogin is only invoked after a confirmed successful response.

The practical impact: if a user submits with a wrong or non-existent org slug, the incorrect slug is still stored in localStorage and will be pre-filled on the next visit. Since the window closes regardless of the outcome, the user has no indication the login failed, and they'll arrive back at a pre-filled slug that doesn't work.

While SSO redirect flows make it impossible to hook into server-side success the same way as credential logins, consider adding a comment documenting this known behavioral difference between the flows, or add a client-side validation check before persisting (e.g., ensure ssoIdentifier is non-empty).

[scott-ray-wilson]

Overall logic looks good - two comments and one suggestion 👍

[scott-ray-wilson]

one thing that feels off though is it seems like oidc/saml set Last used even if I don't actually log in - for instance I clicked OIDC (which I don't have configured) but it says I last used it; I think we should only set this on successful login?

[scott-ray-wilson]

Nice QoL improvement 👍