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.
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
fix: check proxy and sap connectivity auth tokens for caching #5554
base: v3-main
Are you sure you want to change the base?
fix: check proxy and sap connectivity auth tokens for caching #5554
Changes from 5 commits
e60f75b
4294f65
963a283
c984423
ad4d5df
529c1ec
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[req/q] I'm not sure if we should cache based on
SAP-Connectivity-Authentication
. This token is basically thesubscriberToken?.userJwt.encoded
, which is passed by the user (would fail the verify jwt step if its expired). We have no control on how this is fetched and refreshed by the user. So basing our caching on this seems wrong.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[pp] I would have preferred the approach to refresh only the proxy token if its expired. Its a CC grant token, whereas for fetching the whole destination again we make two additional calls to the destination service and the destination service itself might do additional exchange calls to the target system.
We're also mixing concerns between destinationCache and clientCredentialTokenCache.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand your concern. I don't have strong opinion on this. Only from a pure technical point of view, users are allowed to set destination cache with
setDestinationCache()
method. And both headers are defined as part of theDestination
/ProxyConfigurationHeaders
interface. Technically, it means we also can't be sure, in the end, how user setsSAP-Connectivity-Authentication
token. Therefore, I would say we should consider both headers when calculating the expiration time.If exp of
SAP-Connectivity-Authentication
token is shorter than theauthTokens
for destination service and got expired, theDestination
object itself is anyway invalid.Thanks for this cool suggestion, and ideally yes, we should try renew the proxy auth token. And I tried out.
We can add a check when
retrieveDestinationFromCache
. But since we store onlyexpires
time in aCacheEntry
, which is calculated based on the firstauthTokens
expiresIn
, it lacks expiration time for proxy authentication (and, if applicable, sap connectivity authentication). We will have to modifyCacheEntry
interface to store this additional information. But I feelCacheEntry
is designed rather in a generic way, and adding information regarding proxy is not appropriate.So by cache design, we anyway need to determine a expiration time, which should invalidate the cache if its entry cannot be used anymore. Judging from a cached
Destination
entry, we have no clue, if the proxy authentication token has expired or not, since it only provides us a time interval and we don't know the start time when retrieving the destination.Based on the above consideration, I would accept, at this moment, the fact that we may make few additional calls to Destination service. Unless in general, beyond the caching concept, we always renew the proxy auth token if it got expired.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you try what happens when we move the below line before we return the destination? I think this will automatically refresh the proxy auth and the other token in case they expired.
const withProxySetting = await da.addProxyConfiguration(destination);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please have a look at #5563.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also this PR is not totally correct as
exp
of the token is actually seconds after epoch, not expires in.