The demo user becomes Nora Lindqvist, engineering lead at Meridian Labs,
in the week of a product launch. The fixtures tell one story across mail,
contacts, calendar, tasks and files, and exercise the features the
screenshots and the public demo should show:
- a second, mail-only login (her personal domain) and the shared Support
mailbox delegated to the work account, so the account switcher, the
shared section and the merged inbox have real content
- raw headers the way Stalwart writes them: the sender check fails on
the phishing mail, newsletters carry a one-click unsubscribe, one mail
asks for a read receipt, and spam scores show in the details
- an iMIP invitation with a served .ics, an event waiting for the answer
on the calendar, and RSVP patches applied in the demo client
- @mentions as mailto links in a received mail, a verification code
twelve minutes old, nested folders, named tags on the mail, contact
groups, a scheduled message and tasks switched on
- every attachment and file backed by real bytes under public/demo,
generated by `scripts/demo-assets/generate.mjs`; contact photos are
bundled portraits instead of requests to randomuser.me
- folder counts computed from the mail instead of hand-kept numbers
Demo login seeds the tags, templates and merged-inbox settings once per
device and switches the cross-account gate on for the session; "Reset"
restores them. `bulwark-demo-simulate=off` in localStorage stops the
simulated incoming mail for screenshot runs.
Part 2 of 3 of the account archive agreed in #1198. When the admin turns on
"Account List Backup: Passwords" (off by default), saving the list offers to
include the passwords of the accounts signed in here with a plain password.
They are encrypted in the browser together with the list. On restore, those
accounts are signed in to in the background, one by one, without leaving the
active account; a refused password leaves the account waiting for a sign-in by
hand, as before. OAuth and TOTP accounts are saved without a password.
Logout switched to the first account in the list. After a restore that
is often an account still waiting for sign-in, which has no client, so
logout took the full sign-out path and dropped every account. It now
switches to the first account that is connected.
Boot also counted waiting accounts when deciding whether any account
could be restored, so a reload with only waiting accounts left showed a
connection error instead of the login page.
Users with several accounts can save the list of accounts in their browser
(address, server, label, colour) on the webmail server and bring it back on
another device. The list is encrypted in the browser with a password the user
chooses (PBKDF2-SHA-256, 600,000 iterations, AES-256-GCM, owner bound as
additional data); the server stores only the envelope, one file per owner
under SETTINGS_DATA_DIR/account-archives. No mailbox passwords are included.
Off by default behind the admin feature gate accountArchiveEnabled, pinned
off in Lite. Every method of /api/account-archive needs a session cookie of
the owner, matched without regard to case, whose credential is checked
against the mail server on each call; listing included.
Restored accounts this browser lacks are listed as awaiting sign-in: they
survive a reload, and opening one leads to the sign-in form with the address
filled in. Accounts already present get their archived label and colour.
When Stalwart accepted the password and code but refused to issue
tokens (in Lite: `invalid_client` for an OAuth client with a secret),
login retried `password$totp` over Basic. Stalwart 0.16+ rejects that, so
the browser showed its own Basic-auth dialog and the login page then
reported a wrong code. The login now stops with a message pointing at
the OAuth client settings. Password-only logins keep the Basic fallback.
After a load the logins other than the one on screen reconnect in the
background, and until they are all back the unified counts cover only
some of them. With many logins that lasts seconds, and a partial total
looks exactly like the whole one.
While that restore runs, the "All accounts" header shows how many logins
are already in the scope, e.g. "4/10", with a translated label for screen
readers. It goes away when the scope is complete or the restore is over -
a login that failed to reconnect does not keep it up.
`restoringAccounts` in the auth store marks the background restore; the
count itself is a pure function with its own tests.
`/api/auth/sso/complete` only accepted cookie slots 0-4 and quietly
used slot 0 for anything higher. Since the account limit rose to
`MAX_ACCOUNT_SLOTS` (50) on HTTP/2, adding a sixth account through
server-side SSO wrote its refresh token over the first account's cookie,
while the new account was registered on slot 5 with no cookie behind it.
The route and the OAuth callback's pending-slot check now use the same
bound as every other auth route.
After the login on screen, the rest were restored one after the other, so
the last of them - and with it a complete unified inbox - waited on every
other login's round trips: with ten logins it arrived about five seconds
after the first. Restore them four at a time. Each restore already handles
its own failures, so a slow or broken login holds up only its own slot.
Signing out of Lite only deleted the refresh token from web storage, so
a copy taken from the browser kept working until it expired. Sign-out
now revokes it at the endpoint the mail server (or, for an external
provider, its discovery document) advertises, once the token is gone
from storage.
A password login whose token exchange failed for any reason fell back to
Basic auth and kept the password in sessionStorage. The password is now
only kept for the tab when the server has no token login at all (or
cannot be reached for it); otherwise the Basic session lives in memory
and a reload asks to sign in again.
Several endpoints answered anyone with what fingerprints a deployment:
`/api/health?detailed=true` (versions, memory), the update status
(exact version and the text of a pending security advisory, even with
`loginShowVersion` off), `/api/plugins` (installed plugins and the hosts
they may reach), the admin policy (push relays, sidebar app URLs,
plugin lists) and `/api/config` (every domain each server serves).
Visitors without a session now get:
- the plain liveness answer from `/api/health`;
- the update status only where the login page shows the version, and
never the advisory text;
- a 401 from `/api/plugins`, which the client only syncs after signing
in;
- the policy without plugin lists, push relays and sidebar apps, marked
`X-Bulwark-Policy-Scope: public`; the client fetches the full policy
once it signs in;
- server domain lists only when servers are picked by domain.
A mailbox session, a remembered session cookie or the admin session
counts as signed in. Deployments without a session secret cannot tell
sessions apart and keep the old answers.
A full sign-out emptied the stores but left the accounts' traces in the
browser for the next person at the computer: search history, open tabs
with message subjects, Files favourites and recent files, calendar
alert acknowledgements, and attachment bytes a plugin had staged for an
upload that never started. Other open tabs kept showing the signed-out
accounts' mail, and the boot snapshot of the mailbox list was restored
for whichever account happened to be active next.
- A full sign-out now removes those keys and the staged files, and
tells the other tabs through a `storage` event so they leave for the
login page.
- The boot snapshot names its account and is only restored for it.
- The login form only remembers the username for suggestions when the
user did not decline "remember me".
Device preferences and `template-storage` stay: with settings sync off
they exist only on this browser.
`api.storage` kept one `plugin:<id>:` namespace for everyone signed in
to the browser and left it behind after signing out, so a plugin read
what it had stored for the previous account, such as quick-notes'
notes on someone else's mail.
Keys now carry the account (`plugin:<id>:@<account>:<key>`). Signing an
account out or removing it deletes its keys, and a full sign-out
deletes all plugin storage. Keys written before this change are handed
to the first account that uses the plugin. Uninstalling a plugin still
removes everything under its prefix.
Signing out switches sync off for the signed-out account. When another
account stayed signed in, the app switched to it without turning sync
back on, so every later settings change stayed local and was replaced
by the server copy on the next load. Sign-out now resumes sync for the
account it switches to, the same way an account switch does.
Clicking account B and then C before the first switch finished ran
both switches side by side, each holding the account that was active
when it started. The later one then snapshotted B's live stores under
A's key, so switching back to A restored B's identities (and mail) and
never re-fetched them: replies went out with B's From address.
Each switch now takes a generation and stops at its next await once a
newer switch has started, the outgoing account is read when the
snapshot is taken, and stores another switch already cleared are not
snapshotted over the cached state.
Persisted calendar subscriptions were matched to an account by the bare
JMAP account id, or not at all for subscriptions saved by older builds,
and to their calendar by a bare id. Stalwart hands out the same small
ids on every server, so refreshing a subscription through another login
diffed away the events of an unrelated calendar there, and "Remove"
destroyed that calendar. The secret feed URLs also stayed in
localStorage after signing out.
- new subscriptions record their owner (server plus login name), and
refresh, rename and remove act only through that login
- a subscription without an owner is adopted only when its calendar id
and name both exist in the account; otherwise it is left alone and
removing it only drops the local record
- signing out forgets that login's subscriptions, and a full sign-out
clears them all
Signing out when the next registered account had no live client (its
restore failed at boot) fell back to a full logout, but only cleared
the signed-out account's slot and removed just that next account. The
other account's remembered session survived, and on the next visit the
orphan-cookie adoption in `checkAuth` signed the browser back in as
that account and read its password back.
The fallback now drops every remaining account and clears each of
their slots together with the signed-out one. The full logout also
removes the persisted `account-registry` instead of a key that never
existed (`account-storage`).
For members of a group, Stalwart 1.0 lists the group's identity (for
example `team@example.org`) before the user's own. The identity sort
put the identity matching the login first, but compared addresses
case-sensitively, so a login typed as `UserA@Example.org` defaulted to
the group address. The identity manager kept its own copy of the same
sort.
Both now use one sort that compares addresses regardless of case, and
with an internationalized domain in either its Unicode or its `xn--`
form.
After a password change the session kept authenticating with the old
password: the JMAP client's Basic header, the server-side context the
Stalwart management calls use, and the remembered login. The next
request was refused and the user was sent back to the login page.
A successful password change now switches all three to the new
password for Basic-auth sessions. OAuth sessions are unaffected by this
change.
Linus Rath
lucamzanon
Linus Rath