You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ROS users were identified by the pair (identity, auth_url), and in the v10 port
this was translated to (user_id, provider_type), but that isn't actually how
Atlas users work. An App is the equivalent of the old auth_url, and within an
App user_id uniquely identifies a user. Users don't actually have a
"provider type" at all: users have one or more identities, each of which has a
provider type, and the same SyncUser should be used regardless of which
identity was used to log in.
This had surprisingly mild consequences, but was visibly broken in a few ways.
Logging into the same user using two different identities resulted in two
SyncUsers with the same user id. Opening the same partition (or any flx Realm)
with both users resulted in both using whichever SyncUser happened to open it
first, and the second would not create a SyncSession. This meant that most of
the potential bad things (such as creating two session for one file) didn't
actually happen, but the second user's list of sessions would be "incorrect",
and removing one of the users would remove the incorrect set of local files.
Linking identities to anonymous users resulted in the user still being treated
as anonymous. The primary negative effect of this was that linking an identity,
logging out, then logging back in would result in the user being removed
entirely in between, forcing the re-download of all Realms (and the loss of any
un-uploaded data).
This bumps the schema version of the metadata Realm primarily for the sake of
recovery on metadata Realms in invalid states: the migration block handles the
case of multiple users with the same user id and unifies them. Since this needs
a migration anyway, it fixes some incidental problems with the metadata Realm's
schema which weren't fixable without a migration: the marked_for_deletion
column was redundant with the Removed state, identity objects were leaked
due to not being embedded, and the local_uuid field is no longer used for
anything other than opening files written by early v10 versions, so there's no
need to populate it for new users.
Copy file name to clipboardExpand all lines: CHANGELOG.md
+10-2Lines changed: 10 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,13 +5,21 @@
5
5
6
6
### Fixed
7
7
* <How do the end-user experience this issue? what was the impact?> ([#????](https://github.com/realm/realm-core/issues/????), since v?.?.?)
8
-
* None.
8
+
* Logging into a single user using multiple auth providers created a separate SyncUser per auth provider. This mostly worked, but had some quirks:
9
+
- Sync sessions would not necessarily be associated with the specific SyncUser used to create them. As a result, querying a user for its sessions could give incorrect results, and logging one user out could close the wrong sessions.
10
+
- Existing local synchronized Realm files created using version of Realm from August - November 2020 would sometimes not be opened correctly and would instead be redownloaded.
11
+
- Removing one of the SyncUsers would delete all local Realm files for all SyncUsers for that user.
12
+
- Deleting the server-side user via one of the SyncUsers left the other SyncUsers in an invalid state.
13
+
- A SyncUser which was originally created via anonymous login and then linked to an identity would still be treated as an anonymous users and removed entirely on logout.
14
+
(since v10.0.0)
9
15
10
16
### Breaking changes
11
-
* None.
17
+
* SyncUser::provider_type() and realm_user_get_auth_provider() have been removed. Users don't have provider types; identities do.
18
+
* SyncUser no longer has a `local_identity()`. `identity()` has been guaranteed to be unique per App ever since v10.
12
19
13
20
### Compatibility
14
21
* Fileformat: Generates files with format v23. Reads and automatically upgrade from fileformat v5.
22
+
* The metadata Realm used to store sync users has had its schema version bumped. It is automatically migrated to the new version on first open. Downgrading to older version of Realm after upgrading will discard stored user tokens and require logging back in.
0 commit comments