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
Right now neither the SyncManager, Collection, nor the PersistenceAdapter have a way of getting destroyed and cleaned up.
This means that when a user logs in to an application, uses it, and logs out, a malicious attacker could inspect the console and get access to all the cached information. PersistenceAdapters have no way to unregister and clean up after themselves and possibly confidential information remains on the system.
I am requesting a destroy method on the SyncManager and Collection classes to clean up after themselves and call the underlying persistence adapters' unregister method. Then, persistence adapters would implement their specific clean-up logic.
The text was updated successfully, but these errors were encountered:
I just saw this issue after creating #960. My issue is basically the same and I wrote some code to propose a solution. I didn't start yet using SyncManager, so i don't know if Max is going towards same direction or not, but I could do a PR in case my solution could be a nice idea to add.
Right now neither the
SyncManager
,Collection
, nor thePersistenceAdapter
have a way of getting destroyed and cleaned up.This means that when a user logs in to an application, uses it, and logs out, a malicious attacker could inspect the console and get access to all the cached information. PersistenceAdapters have no way to
unregister
and clean up after themselves and possibly confidential information remains on the system.I am requesting a
destroy
method on theSyncManager
andCollection
classes to clean up after themselves and call the underlying persistence adapters'unregister
method. Then, persistence adapters would implement their specific clean-up logic.The text was updated successfully, but these errors were encountered: