CamundaCloudTokenProvider - Allow disabling of file system credentials cache persistence and add tolerance for token expiration #828
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
DisableCredentialsCachePersistence()builder method in clientCamundaCloudClientBuilderto prevent persisting token cache in file system. The goal is to allow users to setup an in-memory only cache for e.g. serverless usage of the client.AccessTokencache. The introduction of aSemaphoreSlimwill protect concurrent accesses to the dictionary and the file system, and prevent concurrent token fetching. The choice ofSemaphoreSlimis done because it is the lock mechanism that fits the best with async/await model. The implementation is optimized to prevent locking when a valid token is in cache.UseAccessTokenDueDateTolerance(TimeSpan tolerance)builder method in clientCamundaCloudClientBuilder. The goal of this option is to allow the user to refresh theAccessTokenslightly before expiration to prevent that, because of network latency, a token considered valid by the client is expired when validated by the authorization server.This change also solves partially issue 637. But the issue rather mentions introducing different implementation of the
IAccessTokenCache. This approach is more impacting for thePersistedAccessTokenCachefor just an in-memory only alternative, as this implementation already have its in-memory cache. To limit the impact, I chose to only improve the existing implementation.closes #415 #642