Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Persist user logged in if the app restarts #11

Closed
rubengarciam opened this issue Feb 6, 2021 · 3 comments
Closed

Persist user logged in if the app restarts #11

rubengarciam opened this issue Feb 6, 2021 · 3 comments
Assignees

Comments

@rubengarciam
Copy link

rubengarciam commented Feb 6, 2021

First, thanks for the sample app and its tutorial.

I am trying to understand which would be the best way to persist the logged in user in between app restarts. Right now, the user needs to log in again if the app or the phone restarts. That feels odd and it is not a standard or expected behaviour.

ClusterDB/task-tracker-swiftui suffers from the same challenge.

I haven't found any documentation, even though it should be ok as app.currentUser already maintains the identity and access token of the logged user.

Any guidance would be highly appreciated. Many thanks!

@am-MongoDB
Copy link
Collaborator

Hi @rubengarciam – that's a good question.

I've another Realm app that I think includes the behavior that you're looking for.

The top-level view checks if the user is already logged in, and if they are it continues as that user:

if settings.realmUser == nil && app.currentUser()?.state == .loggedIn {
    print("Using same user as when last running the app")
    settings.realmUser = app.currentUser()
}

It also uses face-id to store and retrieve the credentials in the keychain – see the app's LoginView:

...
if let error = self.keychain.addCredentials(Credentials(username: username, password: password)) as? KeychainError {
    print(error.localizedDescription)
}
...
private func getStoredCredentials() {
    let data = keychain.readCredentials()
    if let credentials = data.credentials {
        self.login(username: credentials.username, password: credentials.password)
    }

    if let error = data.error as? KeychainError {
        self.errorMessage = error.localizedDescription
    }
}

I hope this helps!

If you want to followup further, it would be great if you could create a topic on https://developer.mongodb.com/community/forums/c/realm/9 as it will get more eyeballs there – including from the SDK developers. Just tag me (@Andrew_Morgan) and add a link to your new topic to this issue.

@rubengarciam
Copy link
Author

Thanks @am-MongoDB for sharing! After having a look at them I think that both have different data models and that raises some additional questions on my head, like why you are user a custom User object in RChat vs Realm.User in o-fish-ios? The former seems somewhat cleaner in my eyes, even though AppState and Settings serve a similar purpose.

Might be my lack of knowledge in the matter though. Happy to do some further reading if you can point me in the right direction.

I will create the topic in the community forum anyway.

@am-MongoDB
Copy link
Collaborator

Hi @rubengarciam.

Custom user data is a useful feature but it has some limitations. On the Atlas side, it's a collection where each document is linked to a specific user. When a user authenticates in the frontend, the app gets a copy of the document as part of their user token. The frontend copy is read-only, and only gets updated to reflect Atlas when you re-login or after a period of time (30 minutes if I recall).

In O-FISH, the users are registered and setup by an administrator using a web app – so there's no need for the frontend app to modify the user data. That made custom data a good fit.

In RChat, the users register and setup their profile data in the frontend and so the read-only custom data option wouldn't work.

@am-MongoDB am-MongoDB self-assigned this Mar 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants