Keep your own settings out of someone else's account #94

New Issue

Closed

opened 2026-08-27 16:59:27 +00:00 by jcoffey-dev · 0 comments

jcoffey-dev commented

2026-08-27 16:59:27 +00:00

Owner

Found by sharing a folder between two real accounts.

Switching to an account someone shared pointed the whole app at it. The rule was "use the selected account if it can do this" — and a shared file account can, by definition, do files.

ihasmail keeps its settings in the account's Files, which is what makes them follow you between devices. So changing any setting while looking at somebody's shared folder wrote your settings.json into their storage, creating the ihasmail folder there to do it. Signature images went the same way, and push registration would have gone to whichever account was on screen.

Reading someone else's data by mistake is bad. Writing yours into theirs is worse, and one line was doing both.

Two questions that had one answer

	follows the account switcher?
What am I looking at — their files, a shared calendar	yes, that's what switching is for
What is mine — synced settings, signature images, push registration	never

accountFor keeps the first meaning; ownAccountFor is the second, and settings sync, signature images and push now use it. A ?? accountId fallback in loadStoredSignature went with it — the reader's own signature, fetched through whoever happened to be selected.

A third rule was hiding in the first

A capability the selected account doesn't advertise fell back to the selected account anyway, so a session naming no primary for something aimed it at whoever was selected — someone else. It now answers with nothing, which is honest: the feature is unavailable, rather than pointed at a stranger.

What this does not settle

Whether the mail, calendar and contacts the switcher appeared to offer were ever really reachable, or only asked for and refused. That depends on what Stalwart advertises in accountCapabilities on a shared account, which needs a look at a sharee's session. If it advertises capabilities nobody shared, more is needed here than routing.

323 web and 77 server tests pass, nine new. npm run typecheck clean.

Independent of #93 — no overlapping files; either can merge first.

🤖 Generated with Claude Code

Merged 2026-08-27 as coffey-labs/ihasmail@9f4c0c3351

_{Rebuilt from: git history, session transcript.}

Found by sharing a folder between two real accounts. Switching to an account someone shared pointed the **whole app** at it. The rule was "use the selected account if it can do this" — and a shared file account can, by definition, do files. ihasmail keeps its settings in the account's Files, which is what makes them follow you between devices. So changing any setting while looking at somebody's shared folder wrote your `settings.json` into **their** storage, creating the `ihasmail` folder there to do it. Signature images went the same way, and push registration would have gone to whichever account was on screen. Reading someone else's data by mistake is bad. Writing yours into theirs is worse, and one line was doing both. ### Two questions that had one answer | | follows the account switcher? | | --- | --- | | What am I **looking at** — their files, a shared calendar | yes, that's what switching is for | | What is **mine** — synced settings, signature images, push registration | never | `accountFor` keeps the first meaning; `ownAccountFor` is the second, and settings sync, signature images and push now use it. A `?? accountId` fallback in `loadStoredSignature` went with it — the reader's own signature, fetched through whoever happened to be selected. ### A third rule was hiding in the first A capability the selected account doesn't advertise fell back to the selected account *anyway*, so a session naming no primary for something aimed it at whoever was selected — someone else. It now answers with nothing, which is honest: the feature is unavailable, rather than pointed at a stranger. ### What this does not settle Whether the mail, calendar and contacts the switcher appeared to offer were ever really **reachable**, or only asked for and refused. That depends on what Stalwart advertises in `accountCapabilities` on a shared account, which needs a look at a sharee's session. If it advertises capabilities nobody shared, more is needed here than routing. 323 web and 77 server tests pass, nine new. `npm run typecheck` clean. Independent of #93 — no overlapping files; either can merge first. 🤖 Generated with [Claude Code](https://claude.com/claude-code) **Merged** 2026-08-27 as coffey-labs/ihasmail@9f4c0c335104 <sub>Rebuilt from: git history, session transcript.</sub>

This repo is archived. You cannot comment on issues.

1 Participants

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: coffey-labs/ihasmail-github-archive#94