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
Describe the bug
Destinations which use Authorization and Proxy-Authorization only consider the expiry time of the Authorization token when determining cache expiry.
To Reproduce
Use a destination which has for example OAuth2JWTBearer with a service going through the SAP Cloud Connector via the connectivity service. Configure it with useCache = true.
Make a request with one authenticated user. The framework obtains a Proxy-Authentication token to use with the connectivity service and the application token to use with the service being connected too. Both of these have an expiry time but only the application token is considered when determining the cache expiry. If the application token has a shorter expiry than the proxy token, the cached destination will start failing once the proxy token expires. Once the application token expires, the cache will be discarded and the next request will work again.
Make another request with a different user. The framework reuses the Proxy-Authentication token obtained during the first call, which can now have an arbitrary time-to-live left. A new application token for the other user is fetched. These are stored in the cache together and expires based on the expiry date of the application token. Once the proxy-auth expires, the destination fails until the application token eventually expires and the cache entry gets discarded.
Expected behavior
The cached destination must expire based on the shortest lived token (application or connectivity proxy). Alternatively, the proxy-auth needs to be refreshed on cached destinations when it expires.
Screenshots
We have worked around the issue with the following patch, which also further clarifies the issue. This includes excessive logging and is also not properly protecting for authorization tokens which are not jwt's (decodeJwt throws in that case), but I assume the proper solution to the problem might be different altogether anyway - this is just to clarify the issue.
SAP Cloud SDK version 3.15.0 (also present in higher versions)
Code Examples
See patch above
Log file
With the patch active (including its excessive logging), output looks like this (in this example both the proxy-auth and the application token have a 12h lifetime and the user connections are half a minute apart. The cached destination for User2 would have kept being used and fail the proxy-authentication after it has expired without the patch.
Destination cache xyz:SomeService (User1) proxy-auth expires 2024-10-30T11:16:29.000Z after user-auth 2024-10-30T11:16:27.107Z
Destination cache abc:SomeService (User2) proxy-auth expires 2024-10-30T11:16:29.000Z before user-auth 2024-10-30T11:16:54.761Z
Impact / Priority
Can't use cached destinations including a user JWT and on-premise connectivity in combination.
Affected development phase: Production but can work around
Impact: Impaired but can work around
Timeline: N/A
Additional context
N/A
The text was updated successfully, but these errors were encountered:
Thanks for bringing this to our attention and also sharing your workaround. You're right, the proxy-auth token should be refreshed if it is expired before the cached destination is returned. I'll create a ticket in our backlog.
I cannot promise a timeline as we're currently low on capacity, but we will try to address it soon.
Describe the bug
Destinations which use Authorization and Proxy-Authorization only consider the expiry time of the Authorization token when determining cache expiry.
To Reproduce
Use a destination which has for example
OAuth2JWTBearer
with a service going through the SAP Cloud Connector via the connectivity service. Configure it withuseCache = true
.Make a request with one authenticated user. The framework obtains a Proxy-Authentication token to use with the connectivity service and the application token to use with the service being connected too. Both of these have an expiry time but only the application token is considered when determining the cache expiry. If the application token has a shorter expiry than the proxy token, the cached destination will start failing once the proxy token expires. Once the application token expires, the cache will be discarded and the next request will work again.
Make another request with a different user. The framework reuses the Proxy-Authentication token obtained during the first call, which can now have an arbitrary time-to-live left. A new application token for the other user is fetched. These are stored in the cache together and expires based on the expiry date of the application token. Once the proxy-auth expires, the destination fails until the application token eventually expires and the cache entry gets discarded.
Expected behavior
The cached destination must expire based on the shortest lived token (application or connectivity proxy). Alternatively, the proxy-auth needs to be refreshed on cached destinations when it expires.
Screenshots
We have worked around the issue with the following patch, which also further clarifies the issue. This includes excessive logging and is also not properly protecting for authorization tokens which are not jwt's (
decodeJwt
throws in that case), but I assume the proper solution to the problem might be different altogether anyway - this is just to clarify the issue.Used Versions:
Code Examples
See patch above
Log file
With the patch active (including its excessive logging), output looks like this (in this example both the proxy-auth and the application token have a 12h lifetime and the user connections are half a minute apart. The cached destination for User2 would have kept being used and fail the proxy-authentication after it has expired without the patch.
Impact / Priority
Can't use cached destinations including a user JWT and on-premise connectivity in combination.
Affected development phase: Production but can work around
Impact: Impaired but can work around
Timeline: N/A
Additional context
N/A
The text was updated successfully, but these errors were encountered: