function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
manish-kumarmanish-kumar 

Smart store destroy cache on logout.

Hi All,

 

I am new to mobile sdk 2.0, I have develop an application using smart store. The problem is that when I logout from salesforce, all data stored in soups destroys.

 

Is this default behaviour?

 

I need to save soup data for different-differnet users, then how can i achive that with mobile sdk 2.0

 

Regards
Manish Kumar

Kevin HawkinsKevin Hawkins

It is the default behavior that soup data gets removed as the result of a user logging out.  Regardless of whether your app is implemented to support multiple users, we would not recommend—nor will we implement—changes to this behavior.  It's a security risk to leave a user's data in the app after she has relinquished her access to that app.

 

If you'd like to implement multiple users of the same app, the approach would be to implement profile switching that does not log out one user in order to give access to another.  While this is technically possible in the Mobile SDK, a) we haven't implemented any of this functionality, and b) SmartStore is not well set up for this at this time, as data is not compartmentalized across (currently non-existent) profiles.  Currently, you would need to create soups or stores that are user-specific, and your app would need to be configured to know which store to use in that scenario.

 

The short answer is that it's an uphill battle, as there's no existing functionality in place to support that use case.  But it could be done.

chipatoothchipatooth

A legit use case would be to use SmartStore as a NoSQL database for data that isn't sensitive or user specific. For instance application state or caching reference data like geographic locations. This data would not have to be encrypted and can be used across users.

 

Yes I could use other database technologies for this or the filesystem but I like the NoSQL + indexing provided by SmartStore.

 

If you were to implement this I would architect it so that the consuming developer would have to opt out of the security/session aspects instead of opting in. This would prevent a lot of "oooops I thought my customer data was encrypted" kinds of errors. ie by default your stores are encrypted and session based unless you do the following dance ...

 

Then instead of clearing all soups when you logout do all but the unregistered instances.

 

Just a thought. I could definately use this.

Kevin HawkinsKevin Hawkins

True, in a world where you're using SmartStore for app-level caching (as opposed to user data caching), you would want the separation.

 

Thanks for the suggestions!  If and when we get to better data partitioning with SmartStore, these are all good considerations.