Summary
After signing out and signing in as a different account, projects downloaded by the previous
account remain on the device and are fully readable — the map opens, features are selectable and
all attributes are visible — even when the new account has no access to that project at all.
The app also offers edit affordances for those projects, so a user can make edits that can never
sync. Choosing Edit geometry crashes the app.
To be clear about what is not wrong: the server behaves correctly. A manual sync attempt is
properly rejected with "No rights to access the project", and no cached credential from the
previous account is reused. The fault is entirely client-side, in how local project data is scoped.
Environment
|
|
| Device |
iPad Pro 12.9-inch (5th generation) |
| OS |
iPadOS 26.5.2 |
| App |
Mergin Maps v2026.3.2 |
| Server |
self-hosted CE, backend image 2025.7.3 |
Steps to reproduce
- Sign in as user A (an account with access to one or more projects).
- Download a project.
- Sign out.
- Sign in as user B — an account holding no project memberships at all (verified
server-side; the project listing endpoint returns nothing for it).
- Look at the projects list on the device.
Expected
Projects downloaded by user A are not readable by user B. Ideally they are hidden, removed, or
locked behind the account that downloaded them.
Actual
As user B, with no rights to anything:
| Action |
Result |
| projects downloaded by user A |
still listed |
| open the project |
opens — the entire map renders |
| select a feature |
works; all attributes readable |
| choose Edit |
offered |
| choose Edit geometry |
app quits |
| edit an attribute and Sync |
correctly rejected: "No rights to access the project" |
Server state was checked afterwards: no version was created, and the project remained at the version
last pushed by the authorised account. Authorisation and authentication are both working — this
is purely about local data not being scoped to an account.
Three distinct problems
-
Local project data is not scoped to the account that downloaded it, and is not cleared on
sign-out. On a shared device, any account — including one with no permissions — can read
another account's project data in full.
-
The app offers edit affordances for a project the account has no rights to. This is arguably
the more damaging one in day-to-day use: a field user who has been removed from a project (or who
signs in as the wrong account) can do a full session of work and lose all of it at the first
sync, with no indication until then. Edit actions should not be offered when the account has no
write access.
-
Edit geometry crashes the app. I have not yet established whether this crash is specific to
the unpermitted state or happens generally, so treat it as an additional observation rather than
a fully characterised bug. Either way, the edit affordance should not have been presented.
Impact
This matters for shared-device deployments, which is a common field pattern. In our case the tablet
holds construction records, 811 utility locate tickets and associated billing data. Sign-out is not
sufficient to hand the device to another person; local projects have to be removed explicitly.
Possibly related
Summary
After signing out and signing in as a different account, projects downloaded by the previous
account remain on the device and are fully readable — the map opens, features are selectable and
all attributes are visible — even when the new account has no access to that project at all.
The app also offers edit affordances for those projects, so a user can make edits that can never
sync. Choosing Edit geometry crashes the app.
To be clear about what is not wrong: the server behaves correctly. A manual sync attempt is
properly rejected with "No rights to access the project", and no cached credential from the
previous account is reused. The fault is entirely client-side, in how local project data is scoped.
Environment
2025.7.3Steps to reproduce
server-side; the project listing endpoint returns nothing for it).
Expected
Projects downloaded by user A are not readable by user B. Ideally they are hidden, removed, or
locked behind the account that downloaded them.
Actual
As user B, with no rights to anything:
Server state was checked afterwards: no version was created, and the project remained at the version
last pushed by the authorised account. Authorisation and authentication are both working — this
is purely about local data not being scoped to an account.
Three distinct problems
Local project data is not scoped to the account that downloaded it, and is not cleared on
sign-out. On a shared device, any account — including one with no permissions — can read
another account's project data in full.
The app offers edit affordances for a project the account has no rights to. This is arguably
the more damaging one in day-to-day use: a field user who has been removed from a project (or who
signs in as the wrong account) can do a full session of work and lose all of it at the first
sync, with no indication until then. Edit actions should not be offered when the account has no
write access.
Edit geometry crashes the app. I have not yet established whether this crash is specific to
the unpermitted state or happens generally, so treat it as an additional observation rather than
a fully characterised bug. Either way, the edit affordance should not have been presented.
Impact
This matters for shared-device deployments, which is a common field pattern. In our case the tablet
holds construction records, 811 utility locate tickets and associated billing data. Sign-out is not
sufficient to hand the device to another person; local projects have to be removed explicitly.
Possibly related
narrower: it concerns one project lingering after removal and showing errors, not another
account being able to open and read the data.