Redirect Notice
As of April 12th, you must go to Progress SupportLink to create new support cases or to access existing cases. Please, bookmark the SupportLink URL and use the new portal to contact the support team.
How can we help you today?
KCSUser caching between sessions.
5 CommentsSorted by Newest First
Edward,
I made this question just because if you get cached [KCSUser activeUser] as a JSON object and extract '_kmd' attribute you will find a 'emailVerification' attribute with a 'status' attribute inside it.
I figured out that the value for 'status' key is 'confirmed' and the [KCSUser activeUser].emailVerified boolean still returns false between application use.
If it is by design as you said, it's ok, but instead of using [KCSUser refreshFromServer:] (the device must be have internet connection for it) I will just read this attribute of active user.
Thanks!
I made this question just because if you get cached [KCSUser activeUser] as a JSON object and extract '_kmd' attribute you will find a 'emailVerification' attribute with a 'status' attribute inside it.
I figured out that the value for 'status' key is 'confirmed' and the [KCSUser activeUser].emailVerified boolean still returns false between application use.
If it is by design as you said, it's ok, but instead of using [KCSUser refreshFromServer:] (the device must be have internet connection for it) I will just read this attribute of active user.
Thanks!
I have the same problem.
Hey,
This is by design in the library- We only maintain the user id and the auth token on disk between application use, so all the other fields are cleaned up. If you want to get the extra fields on the current user object just invoke [KCSUser refreshFromServer:] after a successfull login.
This is by design in the library- We only maintain the user id and the auth token on disk between application use, so all the other fields are cleaned up. If you want to get the extra fields on the current user object just invoke [KCSUser refreshFromServer:] after a successfull login.
Sorry, I think I didn't explained it well. I thought it was already solved but i realized it is not.
To recreate the bug (if it is a bug):
1) Open Kinvey based iPhone app;
2) Login to one user account (that has emailVerified TRUE);
3) If I read [KCSUser activeUser].emailVerified, it is TRUE.
3) Get out of app (kill app on iPhone).
4) Reopen app;
After this, user is still logged in, [KCSUser activeUser] is cached correctly. All information of user (first name, last name, email, ...) is still there (cached, without need of connection to internet to be accessed), but [KCSUser activeUser].emailVerified is FALSE!
If I invoke -[KCSUser refreshFromServer:] emailVerified becomes TRUE again.
To recreate the bug (if it is a bug):
1) Open Kinvey based iPhone app;
2) Login to one user account (that has emailVerified TRUE);
3) If I read [KCSUser activeUser].emailVerified, it is TRUE.
3) Get out of app (kill app on iPhone).
4) Reopen app;
After this, user is still logged in, [KCSUser activeUser] is cached correctly. All information of user (first name, last name, email, ...) is still there (cached, without need of connection to internet to be accessed), but [KCSUser activeUser].emailVerified is FALSE!
If I invoke -[KCSUser refreshFromServer:] emailVerified becomes TRUE again.
How do you mean? The emailVerified is a field on the user object, and should not move from one user to another. Have you checked with the web console that these are inconsistent?
Fabrício Massula Dutra