Skip to content

fix(solid): keep the stored session when a restore attempt is old - #674

Merged
ixuz merged 1 commit into
mainfrom
fix/restore-attempt-keeps-session
Nov 8, 2026
Merged

ixuz merged 1 commit into
mainfrom
fix/restore-attempt-keeps-session

Conversation

@ixuz

@ixuz ixuz commented Nov 8, 2026

Copy link
Copy Markdown
Member

What and why

A load that found an unanswered silent restore attempt older than the restore deadline ended the stored session in every tab. So did a restore that ran out of time or failed. Another page can affect when a tab comes back and whether it leaves at all, so neither the attempt's age nor the deadline shows that the provider failed.

  • Only the provider's own refusal of the tab's request, which the sign-in client handles, ends the stored session on its own.
  • An unanswered attempt of any age skips the silent restore and shows that the provider did not answer. A silent restore that runs out of time shows that it took too long and keeps the attempt, so the next load doesn't wait on the provider again. Both keep the stored session.
  • The landing page that shows either error offers Forget this session while a session is stored. It ends the stored session without asking the provider, and tells the other tabs, as a logout does. New message app.forgetSession in all six locales.
  • docs/authentication.md and docs/solid-memo-client.md describe the new rules and their cost: with a provider that never answers, a load waits up to the deadline until the learner logs in again or forgets the session.

Refs: GHSA-73gp-72j2-85h8

A load that found an unanswered silent restore attempt older than the
restore deadline ended the stored session, on the reasoning that a
working provider would have answered by then. A restore that ran out
of time, or failed, ended it too. But another page can navigate the
tab, keep it from leaving for the provider, and choose when it brings
it back, so neither an attempt's age nor the deadline proves anything
about the provider, and the learner could be logged out in every tab
without any answer from it.

Now only the provider's own refusal of the tab's request, which the
sign-in client handles, ends the stored session on its own. An
unanswered attempt of any age skips the silent restore and shows that
the provider did not answer. A silent restore that runs out of time
shows that it took too long and keeps the attempt, so the next load
does not wait on the provider again; a login's answer that runs out
of time keeps none. Both keep the stored session, for a later load to
try again.

So that a learner whose provider never answers is not stuck with it,
the landing page that shows either error offers "Forget this session"
while a session is stored. It ends the stored session without asking
the provider and tells the other tabs, as a logout does. It takes a
click on the app's own page.

Refs: GHSA-73gp-72j2-85h8
@ixuz ixuz added the bug Something isn't working label Nov 8, 2026
@ixuz
ixuz added this pull request to the merge queue Nov 8, 2026
Merged via the queue into main with commit 34c87ff Nov 8, 2026
51 checks passed
@ixuz
ixuz deleted the fix/restore-attempt-keeps-session branch November 8, 2026 23:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant