-
Notifications
You must be signed in to change notification settings - Fork 234
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
Transactional guarantees for CredentialsManager #473
Comments
This feature request may be related to #437, but I'm not quite sure. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you have not received a response for our team (apologies for the delay) and this is still a blocker, please reply with additional information or just a ping. Thank you for your contribution! 🙇♂️ |
Ping! |
Hi @groue, apologies for the delay. This is not a feature request we want to proceed with. We already provide a stable user ID (the Alternatively, you can also add your own ID via a Rule as a custom claim. |
Thank you very much @Widcket. TIL about the |
Hello,
Describe the problem you'd like to have solved
CredentialsManager is a very handy ready-made tool. However, it makes it difficult to make sure both credentials AND another piece of data are persisted or read from disk with transactional guarantees.
In particular, I would like to store credentials with a stable ID that identifies the user. No token found in
Credentials
is able to fulfill this need.The purpose of this user ID is to help my application strictly isolate users' data, and particularly manage my local cache. In no way a network request authenticated with Alice's access token should be optimized by looking in Bob's cache. In no way the result of this network request should be stored in Bob's cache.
If credentials and user ID are not persisted or read together, with transactional guarantees, it is possible that both pieces of information end up out of sync. And then the above bugs can happen.
CredentialsManager
already performs transactional accesses to credentials, by using NSKeyedArchiver and NSKeyedUnarchiver in order to store and read credentials as a whole. This is very good. We just need one more step:Describe the ideal solution
Please allow CredentialsManager users to provide a userInfo dictionary that would be stored and read at the same time as the credentials:
Alternatives and current work-arounds
Current work-around involves duplicating CredentialsManager in application code, and modify it in order to provide the needed extra transactional guarantees.
The problem with this duplication of code is that when Auth0 is upgraded and CredentialsManager is improved, application code is not.
Thanks for reading!
The text was updated successfully, but these errors were encountered: